Add contribution docs.

Author: csyonghe

community/index.md

@@ -1,15 +1,48 @@
 # Community
 
 Slang is fully open-source and all developments for Slang take place within the public [GitHub repo](https://github.com/shader-slang/slang).
+If you'd like to contribute to the project, we are excited to have your input.
+Please review the following materials to learn more abount our community structure and our process of managing changes.
 
-## Contributing
+## Community Discussions
 
-If you'd like to contribute to the project, we are excited to have your input.
-The following guidelines should be observed by contributors:
+We use the [GitHub discussion page](https://github.com/shader-slang/slang/discussions) for all community announcements and discussions. All community members are welcomed to post questions, ideas, suggestions for new features in the discussion page. We will also use the discussion page to announce or provide update on new feature developments.
+
+## Community Structure
+
+We distinguish in our community between “community”, “committer” and OWNERs in our system inspired by eg. [Chromium](https://chromium.googlesource.com/chromium/src/+/lkgr/docs/code_reviews.md#expectations-of-owners).
+
+#### Community Member
+
+The term community refers to everyone using Slang or participating in the Slang open source project in any form. All community members are welcomed to
+report issues, start discussion threads, or submit pull requests.
+
+#### Committer
+
+A committer is a community member who can review and approve pull requests. This is a status that can be earned by maintaining a track record of submiting and landing code changes to the Slang project. All community members can review code submitted by other community members, but for a pull request to be considered approved and ready for merging, at least one **owner** (more info below) of each file you are touching must provide an approving review. Ideally a committer should choose reviewers who are familiar with the area of code you are touching. If you have doubts, look at the git blame for the file and the OWNERS files.
+
+Submissions to a repository by a change contributor who is not a Slang committer require two committers to approve the submission. If the author of the pull request is already a committer, then only one other committer is needed to review.
+
+If you think you might be ready to be a committer, ask one of the reviewers of your pull request or another committer familiar with your work to see if they will nominate you. They will discuss that in #slang-committers discord — two others in that will need to second the nomination. We will create a policy similar to the terms in https://www.chromium.org/getting-involved/become-a-committer/ for this.
+
+#### Owner
+
+Every file in the Slang repository has a list of owners. An owner of a directory has right to approve pull requests touching the directory. A pull request is considered approved only when at least two owners for each directory changed by the pull request have approved the pull request. If you are a committer and think you’re ready to become an owner of a directory, put up a PR to the relevant OWNERs and get two owners to review it. In face of conflict between owner, owner need to reach consensus amongst themselves.
+
+#### Language Owner
+
+A language owner is the owner of the [`/docs/proposals/`](https://github.com/shader-slang/slang/tree/master/docs/proposals) directory. All new Slang language and core module features (e.g. new language syntax or new function or type in the Slang core module) starts with a design document submitted to this directory. The language and core module design must be approved by two language owners before any implementation pull request for the new language feature can be approved.
+
+## Processes for Code Changes
+
+#### Process for Bug Fixes
+A bug fix starts with an GitHub issue describing the bug. Any community member can submit a pull request coming from your personal fork of Slang containing fixes for the bug. Such pull requests needs to be reviewed and approved by two committers who are owners of the files being changed by the pull request. Once the pull request is approved and passed all CI tests, it can be merged to the main branch. All pull requests are expected to meet
+our bar of code quality.
+
+#### Process for Language Changes
+
+Changes that add or modify syntax, language feature, Slang's core module, or the compilation and reflection API must go through our process for language changes. The full process is [documented here](/community/language-change-process.md).
 
-* Please follow the contributor [Code of Conduct](https://github.com/shader-slang/slang/CODE_OF_CONDUCT.md).
-* Bugs reports and feature requests should go through the GitHub issue tracker
-* Changes should ideally come in as small pull requests on top of `master`, coming from your own personal fork of the project
-* Large features that will involve multiple contributors or a long development time should be discussed in issues, and broken down into smaller pieces that can be implemented and checked in in stages
+## Submitting a Pull Request
 
-[Contribution guide](https://github.com/shader-slang/slang/CONTRIBUTION.md) describes the workflow for contributors in more detail.
+If you are ready to start contributing, please follow our [guide for creating a pull request](https://github.com/shader-slang/slang/CONTRIBUTION.md).

community/language-change-process.md

@@ -0,0 +1,29 @@
+# The Slang Language Change Process
+
+Changes that touch Slang's language and user-facing interfaces, including syntax, core module and public APIs need to follow the language change process described in this document.
+
+File an “Feature Proposal” issue on our github with associated FeatureTracker label to begin including all template fields included. You will need to be a committer, or ask a contributor,community member or greater access to the repo to do this, see the “community” section for how to do so.
+This will be your “Feature tracker’ and you’ll need to keep it updated.
+
+Include in the proposal a link to your design — a link to a PR, google doc, your choice.
+
+Announce the intent to experiment feature to [designated channel on Slang’s GitHub forum] slang-features@slang-lang.org
+Assuming positive community support for your proposal, move your tracking issue’s status to “Implementation” and begin putting up PRs for reviews by relevant code OWNERs.
+
+Reference docs (language ref, library ref) should be updated regularly during this process to allow the community to try your feature out.
+Note that the implementation of a new feature is being made as commits to top-of-tree, albeit marked as experimental (and thus requiring an opt-in by users). The usual process for reviewing and merging pull requests will apply; there is not a separate, lower, quality bar for code changes related to experimental features.
+
+When your feature is stable enough to consider “stable”, announce your “Intention to stabilize” the feature on the issue and on [designated channel on Slang’s GitHub forumslang-features@slang-lang.org and switch the feature tracker to “proposing to stabilize”. If you are not a committer, you will need to ask a committer to make this change for you.
+
+Include in that PRs that (a) mark your feature stable in the code, (b) creates a doc in docs/feature_proposals/ that is the final form of your feature design, and (c) updates the spec.
+
+We encourage sending the intention to stabilize well in advance of wanting to actually have it ship stably — the more time, the more community feedback and ‘banging on the tires’ you can create.
+
+At decision time, the docs/features_proposals/OWNERs will discuss privately (using OWNERs consensus) and share their decision on the email thread. After this, the relevant PRs can land as normal and the feature is stable.
+
+We expect that between 3-7 days will be given for community feedback in typical cases. Some lived experience is needed before we can make a policy about how long review periods need to last.
+
+The total time spent from creation of the tracking issue to when a feature is marked stable may vary with the complexity of a feature, but we expect that it will typically fall in the 1-3 month range. Even if a small feature might be proposed and implemented in a matter of days, it would need to be given sufficient time in the experimental state for community engagement and feedback before being considered for stabilization.
+
+## Feature deprecation and removal
+~= same flow as features — announce to deprecate, plan and timeframe for backcompat, waiting period for community & OWNER feedback, then removal. Will refine when we get to this.