Reduce the Time PRs Remain Open

Why Is It Important?

PRs staying open for an extended period of time is problematic for many reasons. These include:

• Increasing the likelihood of merge conflicts with other PRs. One or more additional PRs may be created that also change one or more of the files in the original PR, leading to potentially hard-to-resolve merge conflicts.
• That the underlying code being changed becomes outdated. A subsequent and smaller PR may be merged that removes the need for part or all of the PR.
• That a PR is forgotten. The PR may become buried in a list of other PRs such that the available reviewers forget that it’s there.
• Contributors become discouraged from contributing to the project. If a PR takes a long time to be reviewed, contributors may give up on the project, potentially moving to one that is more responsive.
• The change is no longer aligned with the project’s roadmap. As with any project, the vision and direction change over time. If a PR remains open too long, the greater the likelihood that the change that it introduces no longer aligns with the current roadmap.

What KPI Should You Track?

The core KPI to track is PR Open Time.

What Are The Underlying Metrics?

To help in tracking PR Open Time, there are three key metrics to use. These are:

• The number of Pull Requests created. Aim to keep this as small as possible for the reasons listed above.
• The average PR size. Keep this as small as possible so that it’s as quick and simple as possible to review and close them. 
• The reviewer to contributor ratio. Make this as equal as possible so that there are enough resources to keep closing PRs in a timely manner.

How Do You Reduce the Time PRs Remain Open?

There are a large number of ways to reduce the time that PRs remain open. Some of the best are:

• Have a CONTRIBUTING.md file. Use this document to provide clear guidance on how to submit a Pull Request. As GitHub recommends, these can include community and behavioral expectations, steps for creating a good pull request, and links to external documentation.
• Encourage contributors to create PRs that are as small as possible. Smaller PRs are easier to review, which reduces the likelihood of them being avoided.
• Have a PR review SLA. By having a clear SLA – communicating it – you set clear expectations to both the reviewer and contributor about what is expected.
• Increase the reviewer to contributor ratio. The higher the ratio is, the greater the likelihood that a PR can and will be reviewed quickly. One way of doing this is to encourage all developers to review PRs. Don’t reserve reviews only for seniors.‍
• Use CI/CD tooling. Platforms such as GitHub include apps that can automate aspects of PRs and add requirements such as having at least one or more reviewers and test suites to pass before a PR can be merged. Make use of this functionality.