What is Review Speed
Review Speed measures how fast a Pull Request (PR) is picked up for first review after submitting it for review.
Why Review Speed matters
Review Speed affects your author’s ability to minimise context switching and supports the team to make frequent deployments into production.
PRs that are taking a long period of review time (several hours or more) relative to their size may indicate that your team’s review process is blocking.
What ‘good’ Review Speed looks like
Review Speed is a measure that's best determined by your team. 'Good' review speed for some times sets the bar at an hour, whilst others within the same day. A short review speed usually indicates a culture of strong team responsiveness, collaboration and continuous delivery, minimising context switching and ensuring team members remained focussed on completing the task at hand.
How Umano measures Review Speed
For each of the PRs that are merged during a particular interval, Umano takes the time difference between when the PR was created and the time when it was merged.
Practices that influence this measure
Number of comments on a PR
Number of tasks on a PR
Size of the PR
Number of issues addressed in a PR
Number of times a PR has been reviewed
Time to first review
What’s included?
Each model looks and specific activities within the tools. Below is a list of activities that contribute to Review Speed and activities that do not have an impact on this metric.
Included | Not included |
All Pull Requests in selected repositories. | If the review is done by the author him/her-self then it is not considered a review. Any additional review undertaken after the first review. |
Tips for improving Review Speed
Code reviews in reasonable quantity, at a slower pace for a limited amount of time results in the most effective code review
Submit Pull Requests on the day the code is ready for review, rather than waiting to submit all requests at the back of the iteration and causing a backlog for your peers to work through
Add titles and descriptions: the more context that authors provide, the faster a reviewer can understand the logic of what has been submitted for review.
Titles should be self-explanatory
Make the description useful by describing WHAT has changed, WHY this PR exists, HOW it is meant to work, and use screenshots where appropriate
Resources
Dias, H., The anatomy of a perfect pull request, 2018, <The anatomy of a perfect pull request >
Osepchuk, B., Optimal pull request size, 2017, <https://smallbusinessprogramming.com/optimal-pull-request-size/>
Riosa, B. The (written) unwritten guide to pull requests, 2016, <The (written) unwritten guide to pull requests - Work Life by Atlassian >
Dias, H., The anatomy of a perfect pull request, 2018, <https://opensource.com/article/18/6/anatomy-perfect-pull-request>
Hewa, G., How Big is Your Pull Request?, 2017, <https://hackernoon.com/how-big-is-your-pr-32c4d67ad76c>
Yu, Y., Wang, H., Filkov, V., Devanbu, P. and Vasilescu, B., 2015, May. Wait for it: Determinants of pull request evaluation latency on GitHub. In Mining software repositories (MSR), 2015 IEEE/ACM 12th working conference on (pp. 367-371). IEEE.