Measure Code Review Turnaround Without Hiding Wait Time

Is the handoff ready?

Use these checks before access expands or the first ticket begins.

Define the clock before collecting a single timestamp

A review target without a clock definition produces arguments. Decide whether the clock starts at pull request open, at ready for review, or at the first reviewer request. Decide whether it stops at the first review, at approval, or at merge.

Decide which hours count. Business hours in the company time zone, business hours in the programmer time zone, and elapsed clock time give three different answers for the same event. Pick one and print it beside the number.

Write the rule for weekends, holidays, and long review threads. A Philippines-based programmer working a shifted schedule should not be penalised by a clock that only counts one office's daylight.

State the time zone used for every timestamp in the export. Two offices reading the same pull request can disagree about the day it was opened, and the disagreement usually appears in the first review of the numbers rather than in the data.

Scope the first measurement to one repository

The ticket names the repository, the date range, the clock rule, the event fields, the export method, and the reviewer. Ask for a script that can be rerun for the next period rather than a one off report.

Start with one repository and one quarter. A cross organisation dashboard built first tends to encode inconsistent definitions from teams that never agreed on the clock.

Record the data source version and the query. When the platform changes an event name, the reviewer needs to know which extraction produced the old numbers.

Build the dataset from pull request events

Use the event stream: opened, ready for review, review submitted, changes requested, approved, merged, closed. Each event has an actor and a timestamp, which is what makes attribution possible.

Deduplicate bot reviews, draft periods, and force pushes carefully. A bot that comments within seconds should not make the team look fast, and a draft that sat for a week should not count as reviewer queue.

Record the pull request size band, the number of files, and whether the change touched a protected area. Size explains more variance than individual speed, and a target that ignores size rewards tiny changes.

Keep the raw event rows in the evidence folder, with personal fields removed. A summary table cannot answer the question a reviewer will ask next month about one unusual pull request.

• Opened, ready, first review, approval, merge timestamps.
• Actor role for each event: author, reviewer, bot.
• Draft and force push intervals excluded by rule.
• Change size band and protected area flag.

Attribute the wait to the owner who caused it

Time in author hands is not reviewer latency. Time waiting for a dependency, a test environment, or a product decision is not reviewer latency either. Split the interval and label each part.

The useful output is a small table: pull request, wait in author hands, wait for first reviewer, wait for re-review, wait for merge approval, and the dominant cause. The dominant cause is what a manager can repair.

Do not sum overlapping intervals. A pull request can be waiting for a reviewer and for a product answer at the same time, and adding both inflates the total.

Check the evidence for gaming and gaps

A target invites behaviour. Watch for tiny pull requests opened to reset a clock, approvals without comments, and reviews split into many small events. None of these improve the code, and all of them improve the number.

Check for missing events and time zone conversion errors. A naive date truncation can move a review across a day boundary and change the median.

Pair the latency number with a quality signal such as defects found after merge or review comments that led to a change. Speed without review depth is not a result.

Handle large changes, re-reviews, and holidays

Report large pull requests separately. A thousand line change reviewed in two days is a different achievement from a ten line change reviewed in two days, and a single median hides both.

Count re-reviews as a separate interval. A pull request that returns three times is a signal about the brief or the change size, not just about reviewer speed.

Exclude declared holidays from business hour calculations or publish the effect. Silent exclusion looks like manipulation when someone recomputes the number later.

• Change above the declared size threshold.
• Second and third review rounds.
• Declared holiday inside the interval.
• Reviewer unavailable with a named backup.

Publish measures with denominators and a repair action

Measure pull requests with a first review inside the target divided by all eligible pull requests, and median business hours to first review by size band. Add the count of pull requests with no reviewer assigned.

Review monthly and change one thing at a time: reviewer rotation, a smaller change size, a scheduled review window, or a clearer template. Re-measure after the change rather than declaring success from a single month.

Keep the target advisory. A hard target applied to individuals distorts behaviour, and review latency is mostly a queue design problem.

Close with a reproducible query and a short readout

The handoff holds the clock definition, the extraction revision, the event table, the exclusion list, the size bands, and the readout with denominators. It also names the owner of the next measurement.

Accept the work when a reviewer can rerun the extraction on the same range and reach the same counts, including the exclusions.

Include the query text and the range parameters in the readout so the next analyst does not rebuild the extraction from a screenshot.

Frequently asked questions

Sources

1. GitHub pull request reviews

   First-party description of review states, approvals, and requested changes.

2. Google Technical Writing

   Guidance for clearer change descriptions and review notes.

3. OpenSSF Scorecard

   Checks that include review and branch protection practices.

4. NIST Secure Software Development Framework

   Review and change management practices that frame the control.