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.
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:
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.