We've noticed interesting trends...Tuesdays have the most code reviews. Wednesdays have the most PRs created. If we are supposed to get code reviewed fast, why is there such a large gap? (Note that not everyone is opening PRs right when they start work on a new task)
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (3)
I'm pulling this information from my engineering analytics platform CodeClimate Velocity.
What you're describing is known as "Review Speed"
Definition
The time between when a pull request is opened and when a specific reviewer submits their first review.
Why it matters
If you’re practicing some form of CI/CD, you’ll want to make sure that work is consistently moving through the software development process. If work consistently gets stuck in the review process it could be a sign that work is being pushed in large, difficult-to-review increments. Or that your reviewers aren’t well positioned to quickly get to pull requests pending review.
How to use it
When this number is high, it may indicate that reviews are not a high-priority item for reviewers, because of either process bottlenecks or bandwidth issues. Use this as an opportunity to re-evaluate how reviews get assigned and to whom.
Benchmarks
Top performing engineering organizations achieve a Review Speed of 24 hours or faster.
For some additional context, my org has a Review Speed of 25.1 hours. And as far as improving the review speed at your own org, my best recommendation is to evaluate your processes and culture, the solution will likely be a blend of both. Example:
If I have to take a guess it is probably the sprint 'deadline' that might be causing this i.e. get the reviews done on Wednesday, make sure the fixes are completed by Thursday so the code gets into production before the sprint is done.
Might be interesting to track metrics on PR size in this case because that would tend to be larger given that the window seems to be ~1 week of coding time.
Would love to hear what you uncover!