What is Time to first Review
Speed of review Time to first Review measures how responsive a your team is in responding to and resolving pull requests.
Why it matters
Speed of review affects a team's ability to deliver software. If review/approval is slow, the context is lost for the author.
...
picking up and reviewing a Pull Request (PR), as measured by the first approval or decline made per PR.
Why Time to first Review matters
Time to first Review 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’ Time to first Review looks like
Inspection rates typically hover at 60 minutes per 500 lines of code (LOC). Whilst it can be tempting to focus on speed at the expense of a quality review, this defeats the purpose of the task at hand.
Similarly, watch out for Pull Requests that are taking a long period of time (several hours or more) relative to their size. This may indicate that your team’s review process may be blocking, and provides an opportunity to jump into the Pull Request to observe whether the number of reviewers on comments on the Pull request are slowing the process down.
How Umano measures
...
Time to first Review
Identify the time taken from when the author submits a pull request PR to when the first approval or first decline is made for that PR during each given interval.
...
Each model looks and specific activities within the tools. Below a list of activities that contribute to Balance of Communication Time to first Review and activities that do not have an impact on this metric.
...
| Tip |
|---|
Code reviews in reasonable quantity, at a slower pace for a limited amount of time results in the most effective code review |
| Tip |
|---|
Shout out for Pull Requests that are deleting lines of code as this usually indicates a good clean-up of the code base, removal of technical debt and improves maintainability of the code base |
| Tip |
|---|
Review fewer than 400 lines of code at a time for effective defect detection |
| Tip |
|---|
Break down larger features into smaller Pull RequestsBreak down larger features into smaller Pull Requests, ideally between 200-400 LOC for fast and effective defect detection |
| Tip |
|---|
Submit Pull Requests on the day the code is ready for review, rather than waiting to submit all requests at the back of the sprint and causing a backlog for your peers to work through |
...
Dias, H., The anatomy of a perfect pull request, 2018, <https://medium.com/@hugooodias/the-anatomy-of-a-perfect-pull-request-567382bb6067 >
Osepchuk, B., Optimal pull request size, 2017, <https://smallbusinessprogramming.com/optimal-pull-request-size/>
Riosa, B. The (written) unwritten guide to pull requests, 2016, <https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests >
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.