Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

What is it

Speed of review measures how responsive a 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.

What ‘good’ 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 this

Identify the time from when the author submits a pull request to when the first approval or first decline during each given interval.

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

  • Reviewers are assigned in the PR

What’s included?

Each model looks and specific activities within the tools. Below a list of activities that contribute to Balance of Communication 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.

Tips for improving Time to first Review

Code reviews in reasonable quantity, at a slower pace for a limited amount of time results in the most effective code review

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

Review fewer than 400 lines of code at a time for effective defect detection

Break down larger features into smaller Pull Requests

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

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

  1. Dias, H., The anatomy of a perfect pull request, 2018, <https://medium.com/@hugooodias/the-anatomy-of-a-perfect-pull-request-567382bb6067 >

  2. Osepchuk, B., Optimal pull request size, 2017, <https://smallbusinessprogramming.com/optimal-pull-request-size/>

  3. Riosa, B. The (written) unwritten guide to pull requests, 2016, <https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests

  4. Dias, H., The anatomy of a perfect pull request, 2018, <https://opensource.com/article/18/6/anatomy-perfect-pull-request

  5. Hewa, G., How Big is Your Pull Request?, 2017, <https://hackernoon.com/how-big-is-your-pr-32c4d67ad76c

  6. 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.

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.