DEV Community

Eric Meadows
Eric Meadows

Posted on

Large gap between opening a PR and submitted reviews...

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)

Top comments (3)

theaccordance profile image
Joe Mainwaring

I'm pulling this information from my engineering analytics platform CodeClimate Velocity.

What you're describing is known as "Review Speed"


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.


Top performing engineering organizations achieve a Review Speed of 24 hours or faster.

theaccordance profile image
Joe Mainwaring • Edited

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:

  • Process: Ship smaller PRs
  • Culture: Getting engineers to incorporate reviews into their daily routine in an invasive way
harish_vaidyanathan_83e54 profile image
Harish Vaidyanathan

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!