From c94565a78ddb1751818b063dc78a9ea3a8645e85 Mon Sep 17 00:00:00 2001 From: Timo Stark Date: Thu, 8 May 2025 11:07:15 +0200 Subject: [PATCH 1/3] feat: add contribution / build guides This adds some basic Contribution Guides to the Repository as well as some guidance on how to build the blog locally for development and contribution Signed-off-by: Timo Stark --- .github/CODE_OF_CONDUCT.md | 0 .github/CONTRIBUTING.md | 0 .github/ORG_CODE_OF_CONDUCT.md | 143 +++++++++++++++++++++++++++++++++ Dockerfile | 9 +++ README.md | 60 ++++++++++++++ 5 files changed, 212 insertions(+) create mode 100644 .github/CODE_OF_CONDUCT.md create mode 100644 .github/CONTRIBUTING.md create mode 100644 .github/ORG_CODE_OF_CONDUCT.md create mode 100644 Dockerfile create mode 100644 README.md diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..e69de29 diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md new file mode 100644 index 0000000..e69de29 diff --git a/.github/ORG_CODE_OF_CONDUCT.md b/.github/ORG_CODE_OF_CONDUCT.md new file mode 100644 index 0000000..c719797 --- /dev/null +++ b/.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 +[report@bytecodealliance.org](mailto:report@bytecodealliance.org). 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. \ No newline at end of file diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 0000000..65992b9 --- /dev/null +++ b/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"] diff --git a/README.md b/README.md new file mode 100644 index 0000000..2502883 --- /dev/null +++ b/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 [`/.github/CONTRIBUTING.md`](.github/CONTRIBUTING.md). +4. **Submit a pull request**: Push your changes and open a pull request to the `main` 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. From 931beeead096482213911b43172125bf2387fb4d Mon Sep 17 00:00:00 2001 From: Timo Stark Date: Thu, 8 May 2025 11:07:15 +0200 Subject: [PATCH 2/3] feat: add contribution / build guides This adds some basic Contribution Guides to the Repository as well as some guidance on how to build the blog locally for development and contribution Signed-off-by: Timo Stark --- .github/CONTRIBUTING.md | 50 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index e69de29..4cd38e7 100644 --- a/.github/CONTRIBUTING.md +++ b/.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. + + + +## 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 + + + +### 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 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`). From b94244d8e79b494c45ca4168f7dccbdbb35f964a Mon Sep 17 00:00:00 2001 From: Timo Stark Date: Thu, 8 May 2025 11:07:15 +0200 Subject: [PATCH 3/3] feat: add contribution / build guides This adds some basic Contribution Guides to the Repository as well as some guidance on how to build the blog locally for development and contribution Signed-off-by: Timo Stark --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 2502883..4a7ca05 100644 --- a/README.md +++ b/README.md @@ -41,8 +41,8 @@ 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 [`/.github/CONTRIBUTING.md`](.github/CONTRIBUTING.md). -4. **Submit a pull request**: Push your changes and open a pull request to the `main` branch. +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).