On this page
Research context
This protocol asks where review time accumulates in a distributed engineering team and which stage contributes most to the delay. The unit is one review cycle, identified by the pull request and the first review request. The study measures the time from ready-for-review to first response, from first response to approval, and from approval to merge. It does not evaluate the quality of the review comments or the correctness of the change.
Set the scope to one repository, one reviewer group, and one time-zone arrangement. Record the review policy, the working hours, and the merge rules at the start. If the policy changes during the window, keep the earlier definition for the full sample or analyze the change as a separate period. A new review requirement can look like a change in reviewer behavior when it is only a change in the rule.
Define the population as every pull request that became ready for review during the window, including requests that were closed without merging. The unit is the review cycle, not the pull request, because a request can be reviewed, changed, and reviewed again. A second review after a substantial change is a new cycle with a link to the first. A comment-only review that does not change the code is part of the same cycle.
Record the author's time zone, the reviewer's time zone, the change size, and the review type. These strata matter because a round-the-clock handoff and an overlapping-hours review carry different delays. Include drafts that were reviewed early, because early feedback is part of the cycle. Test the unit definition on two ordinary pull requests before collection begins.
Define ready-for-review as the time the author removes the draft flag or requests review, not the time the branch was created. Define first response as the first substantive review comment or approval, not an automated check. Define approval as the state that satisfies the branch protection rule. Define merge as the time the change enters the main branch.
Do not count a bot comment as a first response. Do not count a review request sent to a group as a named reviewer response. A review that is paused because the author is offline should be recorded with the pause and the resume time. Each definition should include one positive example and one boundary example so a second reviewer can apply it consistently.
For each cycle, capture the pull request number, the author, the reviewer, the time zones, the ready time, the first response time, the approval time, and the merge time. Add the change size, the number of review rounds, and the number of comments. Record whether the review was synchronous or asynchronous and whether a meeting was held. Keep the timestamp packet with the review sample.
Practical application
Also capture the wait time caused by automated checks and the wait time caused by missing information. These fields help explain a delay that is not the reviewer's fault. If a timestamp comes from a chat message rather than the review system, record the source and the message time. A second reviewer should be able to rebuild the cycle from the record. Keep the timestamp packet with the review sample.
Draw the sample from the review system rather than from a list of slow pull requests. Record the export date, the filters, the row count, and the selection rule. Include cycles from every reviewer and every size band so the result is not dominated by one large change. If the population is ordered by ready time, a fixed interval spreads the sample across the window.
Collect the timestamps as recorded by the system, not as remembered by the team. If a review happened in a meeting, record the meeting time and the participants. Do not reconstruct a missing response from the eventual approval. Note the collection date separately from the review date so the reader can see how much of the record has aged.
A final measure is the share of review cycles that required a synchronous meeting to resolve. Meetings can be useful, but a high share may indicate an unclear written request. Show the meeting count beside the stage times, the attendees, and the outcome of each meeting. The owner can then decide whether to improve the request, the review guidance, or the meeting habit itself.
Report the median and range for each stage: ready to first response, first response to approval, and approval to merge. Show the counts by reviewer time zone and change size. Present the share of cycles that waited more than one business day at each stage. Use the same denominator for every rate and show the number of cycles with incomplete timestamps.
Inspect the longest cycles and describe which stage dominated without naming the reviewer. A cycle that waits mostly for first response points to reviewer capacity or notification, while one that waits after approval points to merge rules or release windows. Compare the result with the time-zone overlap, because a short overlap can concentrate delay. Report the meeting-driven reviews separately.
A useful additional view is the number of review rounds per cycle. A cycle with many rounds may indicate an unclear initial request rather than a slow reviewer. Show the rounds beside the stage times and describe the pattern. That view helps the owner decide whether to improve the request, the review, or the merge path.
Operating controls
The review should also separate time spent waiting for the author from time spent waiting for the reviewer. A request that is returned with questions and then waits for an answer is a different bottleneck from one that sits untouched. Record the handoff direction for each wait. That split prevents the team from optimizing the wrong stage.
The record cannot show whether the reviewer was thinking about the change during the wait or whether the author was unavailable. It can show only the recorded timestamps. A long first-response time is not proof of neglect, and a short one is not proof of a thorough review. The protocol also cannot capture informal review that happened in a call and left no comment.
Review systems can omit comments from deleted accounts, force-pushed commits, and approvals that were later dismissed. A cycle that was reset by a new commit may look longer than it felt. Record those cases and their treatment instead of dropping them silently. If the author and reviewer are the same person, note the independence limitation and analyze that subgroup separately.
A useful comparison is the review time for changes that touch the same files as recent incidents. A hotspot file may attract more scrutiny and legitimately take longer. Show the hotspot status beside the stage times and describe the pattern. That context keeps a slow review from being treated as a performance problem.
Give the result to the engineering lead and the reviewer group and ask them to choose one observable change. The change might be a notification rule, a reviewer rotation, a smaller change size, or a merge window. Record the owner, the effective date, and the measure that will show whether the change worked. Avoid changing the notification and the merge rule at the same time.
Repeat the protocol with the same definitions after the change and compare the same fields. If first response improved but approval did not, the review may be starting faster without finishing. If approval improved but merge did not, the release process may be the real constraint. Close the review when the owner accepts the finding and the next sample is scheduled.
The final view is the reviewer's overall queue, including other repositories and meetings. A reviewer who looks slow on one pull request may be covering three services. Record the concurrent review load and describe the relationship. The owner can then decide whether to rotate reviewers or reduce the queue. Record the next review date with the sample.
Sources
Frequently asked questions
What should happen first?
Begin with a bounded ticket, approved access, explicit acceptance evidence, and a named reviewer.
Who approves production changes?
The client's technical owner keeps final merge and release authority.
Related research
How often do outsourced pull requests arrive without a reproducible test?