Module pull_request_metrics 

Pull Request and Code Review Metrics

Code review is usually the single largest wait-time contributor inside the cycle-time breakdown, and it is also the stage most directly under a team’s own control to improve. This module covers two of that stage’s core metrics: time to first review, the dominant wait-time lever, and reviewer load concentration, a way to surface an otherwise-invisible bottleneck and bus-factor risk in who does the reviewing.

Formula

Time to first review        = t(first substantive comment or approval) - t(opened)
Reviewer load concentration = max(reviews per reviewer) / mean(reviews per reviewer)

Why it matters

Most delay in the review stage comes from a pull request waiting to be looked at, not from the review conversation taking long once it starts — which is why time to first review, instrumented automatically from the version control platform, “typically produces the largest single improvement to overall cycle time available to a team.” Separately, reviewer load is commonly concentrated on a small number of people without anyone measuring it directly: an enterprise example in the book found “a handful of principal engineers were completing over 40% of all code reviews across a two-hundred-person organization.” That concentration is both a bottleneck, since those engineers’ availability caps the whole team’s review throughput, and a burnout risk.

Example

use software_engineering::pull_request_metrics::{
    time_to_first_review, reviewer_load_concentration_ratio,
};

// A pull request opened at hour 0 gets its first review comment at hour 5.
assert_eq!(time_to_first_review(0.0, 5.0), 5.0);

// Five reviewers complete 40, 10, 10, 10, and 10 reviews in a quarter:
// one reviewer is doing 2.5x the average review load.
let reviews = [40.0, 10.0, 10.0, 10.0, 10.0];
let ratio = reviewer_load_concentration_ratio(&reviews).unwrap();
assert!((ratio - 2.5).abs() < 1e-9);

Pitfalls

• Optimizing time to first review without a paired quality guardrail invites rubber-stamp approval that defeats review’s purpose; a fast approval with no real scrutiny is worse than a slower, genuine one.
• Reviewer load concentration is a diagnostic system signal for spotting bottleneck and bus-factor risk — never an individual performance scorecard. The book is explicit that review-related counts are “more often a system or communication signal than a personal one,” and warns directly against “the evaluative drift” of treating them as a judgement on any one reviewer or author. Use a high ratio to prompt rotation and knowledge-sharing, not to rank or evaluate the individuals involved.
• Ignoring reviewer load concentration leaves it invisible until it surfaces as a bottleneck (the concentrated reviewers’ availability caps throughput) or a burnout event.

Sources

• Chapter 2.9, Pull request and code review metrics.

Topic doc: software-engineering-metrics/locales/en-001/chapters/02-09-pull-request-and-code-review-metrics.md

Functions

reviewer_load_concentration_ratio

Reviewer load concentration ratio: the busiest reviewer’s review count divided by the mean review count across all reviewers.

time_to_first_review

Time to first review: the interval from a pull request being opened to a reviewer’s first substantive comment or approval.