Pull request process

Pull request approval process

1. If you open a PR that isn’t finished, don’t tag a reviewer. Add the PR/work-in-progress / PR/needs-rebase / PR/blocked labels if applicable.
2. Once it is ready for review, tag a reviewer and remove any unnecessary labels.
3. If the PR should be looked at by QA before it is approved (for instance, new features and fixes which have some complexity to them), add the PR/needs-QA-attention label.
4. If the reviewer requests changes, the reviewer should change the status to Changes requested.
5. Once you start addressing PR feedback, remove the reviewer. Add the PR/work-in-progress / PR/needs-rebase / PR/blocked labels if applicable.
6. Repeat steps 2-5 as many times as necessary.
7. Once the reviewer is happy with the PR, the reviewer should change the status to Approved.
8. Once QA has looked at a PR, they will remove the PR/needs-QA-attention label.
9. The release team will only merge PRs that have status Approved.

Pull request label meanings

• PR/work-in-progress: A PR is incomplete due to bugs or missing features.
• PR/needs-rebase: A PR needs a rebase before it can be merged cleanly.
• PR/blocked: A PR is incomplete and blocked until some other PR/issue is resolved.
• PR/needs-QA-attention: A PR requires special attention from QA and is ready for QA to look at. This label usually prevents the need to tag QA as reviewers, since QA uses it to filter out PRs that need testing from them early on in the approval process.

Landing pull requests

The release team will scan Approved pull requests and land them on the branches they need to be, they will follow this process:

1. If there is no milestone on the PR and the associated issue, assign the milestone that corresponds to master. You can figure out which milestone that is on the release channels page. Also make sure the issue has the same milestone. All milestones for version releases are considered frozen except for the one that corresponds to the master branch.
2. Merge the pull request to master.
3. git cherry-pick <sha> -m 1 for the merge to each branch above master until you reach the one that is currently tagged in the pull request.

As an example, if a pull request has milestone 0.17.x and master is 0.19.x. Then the pull request will first be merged to master, then the 0.18.x branch, then the 0.17.x branch. Note that in this case there is no 0.19.x branch since that branch corresponds to master.

Direct commits with tagging auditors is generally discouraged unless updating versions on package.json or doing documentation updates. The reason it is discouraged is because it puts the branch at risk of failing tests that hurts the whole team process.