feat: add a contribtion guide, code of conduct and some build instructions

.github/CONTRIBUTING.md

@@ -0,0 +1,50 @@
+# Contributing Guidelines
+
+The following is a set of guidelines for contributing to the Bytecode Alliance. We really appreciate that you are considering contributing!
+
+#### Table Of Contents
+
+[Getting Started](#getting-started)
+
+[Contributing](#contributing)
+
+[Code Guidelines](#code-guidelines)
+
+[Code of Conduct](ORG_CODE_OF_CONDUCT.md)
+
+## Getting Started
+
+Follow our [README](../README.md) to clone the repository and start the local development version of the website.
+
+<!-- ### Project Structure (OPTIONAL) -->
+
+## Contributing
+
+### Report a Bug
+
+To report a bug, open an issue on GitHub with the label `bug` using the available bug report issue template. Please ensure the bug has not already been reported. **If the bug is a potential security vulnerability, please report using our security policy.**
+
+### Suggest a Feature or Enhancement
+
+To suggest a feature or enhancement, please create an issue on GitHub with the label `feature` or `enhancement` using the available feature request issue template. Please ensure the feature or enhancement has not already been suggested.
+
+### Open a Pull Request
+
+* Fork the repo, create a branch, implement your changes, add any relevant tests, submit a PR when your changes are **tested** and ready for review.
+
+Note: if you'd like to implement a new feature, please consider creating a feature request issue first to start a discussion about the feature.
+
+## Code Guidelines
+
+<!-- ### Go Guidelines Here Linter-->
+
+### Git Guidelines
+
+* Keep a clean, concise and meaningful git commit history on your branch (within reason), rebasing locally and squashing before submitting a PR.
+* If possible and/or relevant, use the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) format when writing a commit message, so that changelogs can be automatically generated
+* Follow the guidelines of writing a good commit message as described here <https://chris.beams.io/posts/git-commit/> and summarised in the next few points:
+  * In the subject line, use the present tense ("Add feature" not "Added feature").
+  * In the subject line, use the imperative mood ("Move cursor to..." not "Moves cursor to...").
+  * Limit the subject line to 72 characters or less.
+  * Reference issues and pull requests liberally after the subject line.
+  * Add more detailed description in the body of the git message (`git commit -a` to give you more space and time in your text editor to write a good message instead of `git commit -am`).

.github/ORG_CODE_OF_CONDUCT.md

@@ -0,0 +1,143 @@
+# Bytecode Alliance Organizational Code of Conduct (OCoC)
+
+*Note*: this Code of Conduct pertains to organizations' behavior. Please also see the [Individual Code of Conduct](CODE_OF_CONDUCT.md).
+
+## Preamble
+
+The Bytecode Alliance (BA) welcomes involvement from organizations,
+including commercial organizations.  This document is an
+*organizational* code of conduct, intended particularly to provide
+guidance to commercial organizations.  It is distinct from the
+[Individual Code of Conduct (ICoC)](CODE_OF_CONDUCT.md), and does not
+replace the ICoC. This OCoC applies to any group of people acting in
+concert as a BA member or as a participant in BA activities, whether
+or not that group is formally incorporated in some jurisdiction.
+
+The code of conduct described below is not a set of rigid rules, and
+we did not write it to encompass every conceivable scenario that might
+arise.  For example, it is theoretically possible there would be times
+when asserting patents is in the best interest of the BA community as
+a whole.  In such instances, consult with the BA, strive for
+consensus, and interpret these rules with an intent that is generous
+to the community the BA serves.
+
+While we may revise these guidelines from time to time based on
+real-world experience, overall they are based on a simple principle:
+
+*Bytecode Alliance members should observe the distinction between
+public community functions and private functions — especially
+commercial ones — and should ensure that the latter support, or at
+least do not harm, the former.*
+
+## Guidelines
+
+* **Do not cause confusion about Wasm standards or interoperability.**
+
+  Having an interoperable WebAssembly core is a high priority for
+  the BA, and members should strive to preserve that core.  It is fine
+  to develop additional non-standard features or APIs, but they
+  should always be clearly distinguished from the core interoperable
+  Wasm.
+
+  Treat the WebAssembly name and any BA-associated names with
+  respect, and follow BA trademark and branding guidelines.  If you
+  distribute a customized version of software originally produced by
+  the BA, or if you build a product or service using BA-derived
+  software, use names that clearly distinguish your work from the
+  original.  (You should still provide proper attribution to the
+  original, of course, wherever such attribution would normally be
+  given.)
+
+  Further, do not use the WebAssembly name or BA-associated names in
+  other public namespaces in ways that could cause confusion, e.g.,
+  in company names, names of commercial service offerings, domain
+  names, publicly-visible social media accounts or online service
+  accounts, etc.  It may sometimes be reasonable, however, to
+  register such a name in a new namespace and then immediately donate
+  control of that account to the BA, because that would help the project
+  maintain its identity.
+
+  For further guidance, see the BA Trademark and Branding Policy
+  [TODO: create policy, then insert link].
+
+* **Do not restrict contributors.** If your company requires
+  employees or contractors to sign non-compete agreements, those
+  agreements must not prevent people from participating in the BA or
+  contributing to related projects.
+
+  This does not mean that all non-compete agreements are incompatible
+  with this code of conduct.  For example, a company may restrict an
+  employee's ability to solicit the company's customers.  However, an
+  agreement must not block any form of technical or social
+  participation in BA activities, including but not limited to the
+  implementation of particular features.
+
+  The accumulation of experience and expertise in individual persons,
+  who are ultimately free to direct their energy and attention as
+  they decide, is one of the most important drivers of progress in
+  open source projects.  A company that limits this freedom may hinder
+  the success of the BA's efforts.
+
+* **Do not use patents as offensive weapons.** If any BA participant
+  prevents the adoption or development of BA technologies by
+  asserting its patents, that undermines the purpose of the
+  coalition.  The collaboration fostered by the BA cannot include
+  members who act to undermine its work.
+
+* **Practice responsible disclosure** for security vulnerabilities.
+  Use designated, non-public reporting channels to disclose technical
+  vulnerabilities, and give the project a reasonable period to
+  respond, remediate, and patch.  [TODO: optionally include the
+  security vulnerability reporting URL here.]
+
+  Vulnerability reporters may patch their company's own offerings, as
+  long as that patching does not significantly delay the reporting of
+  the vulnerability.  Vulnerability information should never be used
+  for unilateral commercial advantage.  Vendors may legitimately
+  compete on the speed and reliability with which they deploy
+  security fixes, but withholding vulnerability information damages
+  everyone in the long run by risking harm to the BA project's
+  reputation and to the security of all users.
+
+* **Respect the letter and spirit of open source practice.** While
+  there is not space to list here all possible aspects of standard
+  open source practice, some examples will help show what we mean:
+
+    * Abide by all applicable open source license terms.  Do not engage
+      in copyright violation or misattribution of any kind.
+
+    * Do not claim others' ideas or designs as your own.
+
+    * When others engage in publicly visible work (e.g., an upcoming
+      demo that is coordinated in a public issue tracker), do not
+      unilaterally announce early releases or early demonstrations of
+      that work ahead of their schedule in order to secure private
+      advantage (such as marketplace advantage) for yourself.
+
+  The BA reserves the right to determine what constitutes good open
+  source practices and to take action as it deems appropriate to
+  encourage, and if necessary enforce, such practices.
+
+## Enforcement
+
+Instances of organizational behavior in violation of the OCoC may
+be reported by contacting the Bytecode Alliance CoC team at
+[[email protected]](mailto:[email protected]). The
+CoC team will review and investigate all complaints, and will respond
+in a way that it deems appropriate to the circumstances. The CoC team
+is obligated to maintain confidentiality with regard to the reporter of
+an incident. Further details of specific enforcement policies may be
+posted separately.
+
+When the BA deems an organization in violation of this OCoC, the BA
+will, at its sole discretion, determine what action to take.  The BA
+will decide what type, degree, and duration of corrective action is
+needed, if any, before a violating organization can be considered for
+membership (if it was not already a member) or can have its membership
+reinstated (if it was a member and the BA canceled its membership due
+to the violation).
+
+In practice, the BA's first approach will be to start a conversation,
+with punitive enforcement used only as a last resort.  Violations
+often turn out to be unintentional and swiftly correctable with all
+parties acting in good faith.

Dockerfile

@@ -0,0 +1,9 @@
+FROM ruby:3
+
+COPY ./ /blog/
+WORKDIR /blog/
+RUN gem install jekyll && bundle install
+
+EXPOSE 4000
+
+CMD ["bundle", "exec",  "jekyll serve -H 0.0.0.0"]

README.md

@@ -0,0 +1,60 @@
+# Bytecode Alliance Website
+
+This repository contains the source code for the [Bytecode Alliance website](https://bytecodealliance.org/).
+The Bytecode Alliance is a nonprofit organization dedicated to creating secure software foundations for the
+future of the WebAssembly ecosystem and beyond.
+
+## Website Overview
+
+The Bytecode Alliance website serves as:
+
+- **A hub for WebAssembly technologies:** Learn about WebAssembly and its growing ecosystem.
+- **Information on the Bytecode Alliance mission:** Explore the mission, goals, and initiatives of the Bytecode Alliance.
+- **A resource for contributors and users:** Access documentation, project updates, and community events.
+
+## Build Locally and Development Environment
+
+We use `jekyll` as a static page generator. If you would like to run a version of the Website locally follow these
+instructions.
+
+1. **Install Ruby and Dependencies**: Install [Jekyll Installation Guide](https://jekyllrb.com/docs/installation/). Follow the instructions on the
+                official website.
+2. **Install Project Dependencies**: `bundle install`
+3. **Run**: `bundle exec jekyll serve`
+
+### Use Docker
+By using Docker Containers you don't have to install any Ruby Environment on your local machine. Do run the Blog
+locally using Docker issue the following steps:
+
+1. Build the Image
+```bash
+docker build -t my/bablog .
+```
+2. Run the Development Server
+```bash
+docker run -v ./:/blog/ -p 4000:4000 -t my/bablog
+```
+
+## Contribution Guide
+
+We welcome contributions to improve the website! To get started:
+
+1. **Fork this repository**: Create your own copy of the repository.
+2. **Clone the repository**: Use `git clone` to copy it to your local machine.
+3. **Set up your environment**: Follow the setup instructions in our [CONTRIBUTION GUIDE](.github/CONTRIBUTING.md).
+4. **Submit a pull request**: Push your changes and open a pull request to the `gh-pages` branch.
+
+Please ensure all contributions adhere to our [Code of Conduct](.github/ORG_CODE_OF_CONDUCT.md).
+
+## License
+
+This repository is licensed under the [Apache 2.0 License](LICENSE).
+By contributing to this repository, you agree to license your contributions under the same license.
+
+## Getting Help
+
+If you encounter any issues or have questions, please open an issue in this repository or reach out via the contact information on the [website](https://bytecodealliance.org/).
+
+## Acknowledgments
+
+The Bytecode Alliance is grateful to its contributors and the community for their support and collaboration. Together, we are building a stronger, more secure WebAssembly ecosystem.