...
Time to Merge measures how long your team takes to create, review and merge a Pull Request (PR) to master a single branch.
Why
...
Time to Merge matters
Code reviews are an important part of the software development lifecycle because they provide the ability for code written by team members to be peer reviewed and assured for quality before the code is merged from to a single branch into master. Reviewing pull requests can also be one of the most time consuming activities of a team’s software development process.
Making smaller pull requests is the best way to speed up time spent reviewing your peer’s work. By applying the discipline to break down pull requests into smaller, manageable batches of code, it’s much quicker for reviewers to understand the context and reason with the logic and detect defects that need remediation.
...
We measure Time to Merge because code reviews can often get blocked, impacting how fast you can ship your product to your customers (additional insight that can be gleaned from viewing your team’s Cycle Time).
Optimising Time to Merge will improve the time it takes your team to deliver value to your customers, as well as improving the quality of the value you deliver. When done well, the code commits and their attched messages within a Pull request tell a story to people examining code at a later date, improveing maintainability and serviceability of the code base.
What ‘good’ Time to Merge looks like
Small pull requests are easier to review, making it more likely for code to be thoroughly reviewed before approval. It helps to speed up the review, reduces risk of introducing bugs into the codebase, helps not block other developments and speeds up the product development process.
...
Large pull requests tend to be glazed over and rubber stamped, limiting the effectiveness of defect detection.
How Umano measures
...
Time to Merge
Umano measures Time to Merge by observing for each Pull Request merged during the given interval, the time from when the Pull Request was created to the time when it was merged into master.
Practices that influence
...
Time to Merge
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 time a PR has reviewed (approvals)
Time to first review
...
Included | Not included |
|---|---|
All Pull Requests in selected repositories | x |
Tips for improving
...
Time to Merge
| 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 detectionAim for one succinct commit |
| Tip |
|---|
Describe your changes well in each commit |
| Tip |
|---|
Reviewers should ensure the commit history is excellent, that good changes are made quickly, that the code review is performed and that they understand what is being changed, from the perspective of someone examining code in the future. |
| Tip |
|---|
Encourage a culture where all team members can share in the responsibility of being a reviewer |
| Tip |
|---|
Ensure there is a balance between flow and ensuring the quality of your team’s PRs |
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.
...