Philippines staffing research ·

Mean time to review in outsourced programming teams

A measurement study for separating review delay from implementation time in distributed software delivery.

Review delay and coding time are different operational signals. A pull request can be technically complete while waiting for a reviewer, so combining both intervals hides where work is actually stalled.

DORA treats software delivery performance as a system outcome rather than an individual productivity score. GitHub records review requests, comments, approvals, and merge events, which gives teams a reproducible event trail for measuring review flow.

A useful baseline records the median and upper-quartile time from review request to first substantive review. Draft time, weekends, automated bot comments, and author self-reviews should be classified consistently before comparisons are made.

The evidence should also distinguish queue delay from review duration. Queue delay ends when a qualified reviewer begins; review duration covers the period until approval or a clear request for changes.

The strongest interpretation is comparative, not universal. Track the same repository and ticket classes over time, then examine whether reviewer coverage, pull-request size, or unclear ownership explains changes.

Research takeaway: measure the review system and its queues, not developer presence, and retain merge authority with the company technical owner.

Sources

  1. DORA research program
  2. GitHub pull request review documentation

Related Research

FAQ

What should happen first?

Begin with a bounded ticket, approved access, and a named reviewer.

Who approves production changes?

The company’s technical owner keeps final merge and release authority.