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.