Reduce the Time PRs are Waiting for Review
Pull Requests are an excellent way of proposing a set of changes to a codebase. They’re easy to create alongside the main development branch, can readily be reviewed by contributors on the project, and feedback helps improve the quality of the proposed changes. However, the time to review them needs to be reduced as much as is practically possible.
Why Is It Important?
If PRs are left for too long before they are reviewed, they can suffer from a number of well-known issues, including:
- Merge conflicts from subsequent PRs that cover some of the same code.
- The PR may be forgotten about, or abandoned by the original contributor.
- The change no longer falls within the project’s roadmap.
- The changes may become outdated because they have been superseded by subsequent changes.
What KPI Should You Track?
The core KPI to track is Wait Time to 1st Review. This is the time between the PR being marked as ready for review and it receiving its first review from another contributor.
What Are The Underlying Metrics?
To help in reducing PR review waiting time, there are two key metrics to use. These are:
- The PR size. The larger the PR’s size, more than likely, though not always, the higher its complexity will be. Given that, it is more likely that it will be avoided by the available contributors. This can be for a number of reasons. Reviewers may not feel that they are sufficiently skilled to review it. Reviewers may find other PRs easier to review and focus on them instead. It may take time to communicate with other developers and stakeholders when questions arise.
- The reviewer to contributor ratio. The greater the number of reviewers to contributors, the sooner PRs can be reviewed and the more quickly reviews can be completed. Ensure, wherever possible, that the ratio is as high as possible.
- Reviewer distribution. Ensure that number of code reviews is fairly distributed by the whole team.
How Do You Reduce the Time PRs are Waiting for Review?
There are three key ways to reduce PR review wait time. These are:
- Keep PRs as small and focused as possible. The smaller and more focused a PR the lower its complexity. This reduces the time taken to review it and increases the likelihood that a reviewer will feel competent to review it.
- Properly Organise PRs. Most source code management platforms allow for PRs to be organized in a variety of ways, including by milestone, project, and priority. These clearly set out how important a PR is and when it needs to be actioned. In addition, PRs can be labeled, making it even easier for a reviewer to know if it is something that they should take on, such as new or junior reviewers.
- Make rapid reviews a priority. When rapid reviews are a priority within a team or organization, the likelihood of them being reviewed increases. This stands in stark contrast to organizations where creating PRs is the priority. In those organizations, reviews can often be neglected, even becoming an afterthought.
- Define code review guidelines. Ensure there are sheet cheats on how to code review within your organization to accelerate the review process.
