What is Time to
...
First Review
Time to first Review merge measures how responsive your team is picking up and reviewing fast a Pull Request (PR) , as measured by the first approval or decline made per PRwas merged after creating it.
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.A short time to merge indicates a culture of strong team responsiveness, collaboration and continuous delivery. PRs are opened and merged within a day reflect more mature practices. This is made possible by the author’s well constructed title (self-explanatory), description (
How Umano measures Time to
...
First Review
Identify the time taken from when the author submits a PR to when the first approval or first decline is made for that PR during each given intervalFor 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 PRReviewers are assigned in the 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 a list of activities that contribute to Time to first First Review 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 Time to
...
First Review
| Tip |
|---|
Code reviews in reasonable quantity, at a slower pace for a limited amount of time results in the most effective code review |
| Tip |
Break 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 |
...
| Tip |
|---|
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, <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.