From ec4a60a96528051f7c29b1fa69dc99f77c08dd47 Mon Sep 17 00:00:00 2001 From: Martin Turon Date: Mon, 12 Dec 2022 08:51:27 -0800 Subject: [PATCH] Initial revision. --- CODE_OF_CONDUCT.md | 83 ++++++++++++++ CONTRIBUTING.md | 270 +++++++++++++++++++++++++++++++++++++++++++++ README.md | 4 + 3 files changed, 357 insertions(+) create mode 100644 CODE_OF_CONDUCT.md create mode 100644 CONTRIBUTING.md create mode 100644 README.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..371df3b --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,83 @@ +# Project CHIP Open Source Code of Conduct + +This Project CHIP Open Source Code of Conduct applies to all those contributing +to, participating in, or maintaining the Project CHIP open source project, +including Zigbee Alliance members and non-members. + +## Our Pledge + +In the interest of fostering an open and welcoming environment, we as +contributors and maintainers pledge to make participation in our project and our +community a harassment-free experience for everyone, regardless of age, body +size, disability, ethnicity, sex characteristics, gender identity and +expression, level of experience, education, socio-economic status, nationality, +personal appearance, race, religion, or sexual identity and orientation. + +## Our Standards + +Examples of behavior that contributes to creating a positive environment +include: + +- Using welcoming and inclusive language +- Being respectful of differing viewpoints and experiences +- Gracefully accepting constructive criticism +- Focusing on what is best for the community +- Showing empathy towards other community members + +Examples of unacceptable behavior by participants include: + +- The use of violent threats, abusive, discriminatory, or derogatory language +- The use of sexualized language or imagery and unwelcome sexual attention or + advances +- Trolling, insulting/derogatory comments, and personal or political attacks +- Public or private harassment +- Publishing others' private information, such as a physical or electronic + address, without explicit permission +- Posting of violent content +- Engaging in unwanted physical contact +- Other conduct which could reasonably be considered inappropriate in a + professional setting +- Advocating for or encouraging any of the above behaviors + +## Our Responsibilities + +Project maintainers are expected to take appropriate and fair corrective action +in response to any instances of unacceptable behavior. Project maintainers have +the right and responsibility to remove, edit, or reject comments, commits, code, +wiki edits, issues, and other contributions that are not aligned to this Code of +Conduct, or to ban temporarily or permanently any contributor for other +behaviors that they deem inappropriate, threatening, offensive, or harmful. + +## Scope + +This Code of Conduct applies within all project spaces, and it also applies when +an individual is representing the project or its community in public spaces. +Examples of representing a project or community include using an official +project e-mail address, posting via an official social media account, or acting +as an appointed representative at an online or offline event. Representation of +a project may be further defined and clarified by project maintainers. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported by contacting the Project CHIP open source team at [INSERT EMAIL +ADDRESS]. All complaints will be reviewed and investigated and will result in a +response that is deemed necessary and appropriate to the circumstances. The +Project CHIP open source team should maintain confidentiality with regard to the +reporter of an incident. Further details of specific enforcement policies may be +posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good +faith may face temporary or permanent repercussions as determined by Project +CHIP open source leadership. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], +version 1.4, available at +https://www.contributor-covenant.org/version/1/4/code-of-conduct.html + +[homepage]: https://www.contributor-covenant.org + +For answers to common questions about this code of conduct, see +https://www.contributor-covenant.org/faq diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..a71219f --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,270 @@ +# Contributing to Matter (formerly Project CHIP) + +Want to contribute? Great! First, read this page (including the small print at +the end). By submitting a pull request, you represent that you have the right to +license your contribution to the Connectivity Standards Alliance and the +community, and agree by submitting the patch that your contributions are +licensed under the [Apache 2.0 license](./LICENSE). Before submitting the pull +request, please make sure you have tested your changes and that they follow the +project guidelines for contributing code. + +# Contributing as an Open Source Contributor + +As an open source contributor you can report bugs and request features in the +[Issue Tracker](https://github.com/project-chip/connectedhomeip/issues), as well +as contribute bug fixes and features that do not impact Matter specification as +a pull request. For example: ports of Matter to add APIs to alternative +programming languages (e.g. Java, JS), hardware ports, or an optimized +implementation of existing functionality. For features that impact the +specification, please join Matter work group within the Connectivity Standards +Alliance. The requirements to become an open source contributor of the +[Matter Repository](https://github.com/project-chip/connectedhomeip) are: + +- Agree to the [Code of Conduct](./CODE_OF_CONDUCT.md) +- Agree to the [License](./LICENSE) +- Have signed the + [Matter Working Group CLA](https://gist.github.com/clapre/65aa9fc63981da765039e0bb7e8701be) + +# Contributing as a Connectivity Standards Alliance Matter Working Group Member + +As a participant of the Connectivity Standards Alliance Matter Working Group, +you can attend Working Group meetings, propose changes to the Matter +specification, and contribute code for approved updates to the specification. +The requirements to become a member of the +[Matter Repository](https://github.com/project-chip/connectedhomeip) are: + +- Must be a [Participant member](http://www.zigbeealliance.org/join) or higher + of the Connectivity Standards Alliance +- Must be a Matter Working Group member +- Have signed the Alliance Matter Working Group CLA +- Have approval from your company's official approver + +# Bugs + +If you find a bug in the source code, you can help us by +[submitting a GitHub Issue](https://github.com/project-chip/connectedhomeip/issues/new). +The best bug reports provide a detailed description of the issue and +step-by-step instructions for predictably reproducing the issue. Even better, +you can +[submit a Pull Request](https://github.com/project-chip/connectedhomeip/blob/master/CONTRIBUTING.md#submitting-a-pull-request) +with a fix. + +# New Features + +You can request a new feature by +[submitting a GitHub Issue](https://github.com/project-chip/connectedhomeip/issues/new). +If you would like to implement a new feature, please consider the scope of the +new feature: + +- _Large feature_: first + [submit a GitHub Issue](https://github.com/project-chip/connectedhomeip/issues/new) + and communicate your proposal so that the community can review and provide + feedback. Getting early feedback will help ensure your implementation work + is accepted by the community. This will also allow us to better coordinate + our efforts and minimize duplicated effort. +- _Small feature_: can be implemented and directly + [submitted as a Pull Request](https://github.com/project-chip/connectedhomeip/blob/master/CONTRIBUTING.md#submitting-a-pull-request). + +# Contributing Code + +Matter follows the "Fork-and-Pull" model for accepting contributions. + +### Initial Setup + +Setup your GitHub fork and continuous-integration services: + +1. Fork the [Matter repository](https://github.com/project-chip/connectedhomeip) + by clicking "Fork" on the web UI. + +2. All contributions must pass all checks and reviews to be accepted. + +Setup your local development environment: + +```bash +# Clone your fork +git clone git@github.com:/connectedhomeip.git + +# Configure upstream alias +git remote add upstream git@github.com:project-chip/connectedhomeip.git +``` + +### Submitting a Pull Request + +#### Branch + +For each new feature, create a working branch: + +```bash +# Create a working branch for your new feature +git branch --track origin/master + +# Checkout the branch +git checkout +``` + +#### Create Commits + +```bash +# Add each modified file you'd like to include in the commit +git add + +# Create a commit +git commit +``` + +This will open up a text editor where you can craft your commit message. + +#### Upstream Sync and Clean Up + +Prior to submitting your pull request, you might want to do a few things to +clean up your branch and make it as simple as possible for the original +repository's maintainer to test, accept, and merge your work. + +If any commits have been made to the upstream master branch, you should rebase +your development branch so that merging it will be a simple fast-forward that +won't require any conflict resolution work. + +```bash +# Fetch upstream master and merge with your repository's master branch +git checkout master +git pull upstream master + +# If there were any new commits, rebase your development branch +git checkout +git rebase master +``` + +Now, it may be desirable to squash some of your smaller commits down into a +small number of larger more cohesive commits. You can do this with an +interactive rebase: + +```bash +# Rebase all commits on your development branch +git checkout +git rebase -i master +``` + +This will open up a text editor where you can specify which commits to squash. + +#### Push and Test + +```bash +# Checkout your branch +git checkout + +# Push to your GitHub fork: +git push origin +``` + +This will trigger the continuous-integration checks. You can view the results in +the respective services. Note that the integration checks will report failures +on occasion. + +### Review Requirements + +#### Documentation Best Practices + +Matter uses Doxygen to markup (or markdown) all C, C++, Objective C, Objective +C++, Perl, Python, and Java code. Read our +[Doxygen Best Practices, Conventions, and Style](https://github.com/project-chip/connectedhomeip/blob/master/docs/style/DOXYGEN.adoc) + +#### Submit Pull Request + +Once you've validated the CI results, go to the page for your fork on GitHub, +select your development branch, and click the pull request button. If you need +to make any adjustments to your pull request, just push the updates to GitHub. +Your pull request will automatically track the changes on your development +branch and update. + +#### Merge Requirements + +- Github Workflows pass +- Builds pass +- Tests pass +- Linting passes +- Code style passes + +When can I merge? After these have been satisfied, a reviewer will merge the PR +into master + +#### Documentation + +Documentation undergoes the same review process as code See the +[Documentation Style Guide](https://github.com/project-chip/connectedhomeip/blob/master/docs/STYLE_GUIDE.md) +for more information on how to author and format documentation for contribution. + +## Merge Processes + +Merges require at least 3 approvals from unique require-reviewers lists, and all +CI tests passing. + +### Shorter Reviews + +Development Lead & Vice Leads can merge a change with fewer then the required +approvals have been submitted. + +A separate "fast track" label will be created that will only require a single +checkbox to be set, this label shall only be set by the Development Lead, and/or +Vice Lead (unless they’re both unavailable, in which case a replacement can be +temporarily appointed) + +"Day" here means "business day" (i.e. PRs on friday do not get fast-tracked +faster). + +### Fast track types + +### Trivial changes + +Small changes or changes that do not affect the main functionality of the code +can be fast tracked immediately. Examples: + +- Adding/removing documentation (.md files) +- Adding tests (may include small reorganization/method adding/changes to + enable testability): + - certification tests + - stability tests + - integration tests + - functional tests + - Test scripts + - Additional tests following a pattern (e.g. YAML tests) +- Adding/updating/fixing tooling to aid in development +- Re-running code generation +- Code readability refactors: + - renaming enum/classes/structure members + - moving constant header location + - Obviously trivial build rule changes (e.g. adding missing files to build + rules) + - Changing comments + - Adding/removing includes (include what you need and only what you need + rules) +- Pulling new third-party repo files +- Platform vendors/maintainers adding platform features/logic/bug fixes to + their own platforms +- Most changes to existing docker files (pulling new versions, reorganizing) +- Most changes to new dockerfile version in workflows + +#### Fast track changes + +Larger functionality changes are allowed to be fast tracked with these +requirements/restrictions: + +- Require at least 1 day to have passed since the creation of the PR +- Require at least 1 checkmark from someone familiar with the code or problem + space + - This requirement shall be dropped after a PR is 3 days old with stale or + no feedback. +- Code is sufficiently covered by automated tests (or impossible to + automatically test with a very solid reason for this - e.g. changes to BLE + parameters cannot be automatically tested, but should have been manually + verified) + +Fast tracking these changes will involve resolving any obviously 'resolved' +comments (judgment call here: were they replied to or addressed) and merging the +change. + +Any "request for changes" marker will always be respected unless obviously +resolved (i.e. author marked "requesting changes because of X and X was done in +the PR") + +- This requirement shall be dropped after a PR is 3 days old with stale or no + feedback. diff --git a/README.md b/README.md new file mode 100644 index 0000000..8f2625f --- /dev/null +++ b/README.md @@ -0,0 +1,4 @@ +# matter-rs: The Rust Implementaion of Matter + +![experimental](https://img.shields.io/badge/status-Experimental-red) [![license](https://img.shields.io/badge/license-Apache2-green.svg)](https://raw.githubusercontent.com/project-chip/matter-rs/main/LICENSE) +