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:
Process: Ship smaller PRs
Culture: Getting engineers to incorporate reviews into their daily routine in an invasive way
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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: