All contributions to dotnet/runtime repo are made via pull requests (PRs) from forks of the repo rather than through direct commits or PRs from branches in the dotnet/runtime repo. The pull requests are reviewed and merged by the repository maintainers after a review and approval from at least one area maintainer.
To merge pull requests, you must have write permissions in the repository. If you are a member of the .NET team or have an official partnership you can request access here.
- Do not mix unrelated changes in one pull request. For example, a code style change should never be mixed with a bug fix.
- All changes should follow the existing code style. You can read more about different code styles at docs/coding-guidelines.
- Use Draft pull requests for changes you are still working on but want early CI loop feedback. When you think your changes are ready for review, change the status of your pull request.
- Avoid rebasing your changes. If you are asked to make changes during the review process do them as a new commit.
- To resolve merge conflicts, use "merge" instead of "rebase".
Every pull request will have automatically a single area-* label assigned. The label not only indicates the code segment which the change touches but also the owner. We maintain a list of areas owners for all dotnet/runtime labels. They are responsible for landing pull requests in their area in a timely manner and for helping contributors with their submitted pull request. You can ask them for assistance if you need help with landing your changes.
If during the code review process a merge conflict occurs the area owner is responsible for its resolution. Pull requests should not be on hold due to the author's unwillingness to resolve code conflicts. GitHub makes this easier by allowing simple conflict resolution using the conflict-editor.
When submitting a PR to the dotnet/runtime repository, various builds will run validating many areas to ensure we keep developer productivity and product quality high. For a high level overview of the build process and the different pipelines that might run against your PR, please check pipelines overview.
Anyone with write access can merge a pull request manually when the following conditions have been met:
- The PR has been approved by at least one reviewer and any other objections are addressed.
- You can request another review from the original reviewer.
- The PR successfully builds and passes all tests in the Continuous Integration (CI) system. In case of failures, refer to the analyzing build failures doc.
Typically, PRs are merged as one commit (squash merges). It creates a simpler history than a Merge Commit. "Special circumstances" are rare, and typically mean that there are a series of cleanly separated changes that will be too hard to understand if squashed together, or for some reason we want to preserve the ability to disect them.
If for whatever reason you would like to move your pull request back to an in-progress status to avoid merging it in the current form, you can turn the PR into a draft PR by selecting the option under the reviewers section. Alternatively, you can do that by adding [WIP] prefix to the pull request title.
From time to time we will review older PR's (> 1 month) and check them for relevance. If we find the PR is inactive or no longer applies, we will close it. As the PR owner, you can simply reopen it if you feel your closed PR needs our attention.