First Commit to Pull Request: Measure Work Before Review Starts

Code review metrics usually start when a pull request opens. Development starts earlier. The gap between the first commit and the PR open time shows how long work remains outside the review queue.

GitQuick tracks First Commit to Open as a trend alongside review and delivery metrics. This August 23, 2026 product screenshot is illustrative and does not contain the October showcase figures below.

That gap matters because a fast first review can coexist with a slow path to visibility. A team may answer visible PRs quickly while changes spend days on branches before reviewers, continuous integration, and other stakeholders can see them.

What first commit to PR open measures

First commit to open is the elapsed wall-clock time from the earliest commit recorded for a pull request to the time that pull request was created.

GitQuick calculates the per-PR duration as:

PR created time - first commit time

The metric does not measure focused coding time. It includes nights, weekends, interruptions, local validation, branch cleanup, and any other delay between the two timestamps. Rebased, cherry-picked, generated, or imported history can also make an old commit appear in a new PR.

For that reason, use the duration as a workflow visibility measure. Do not present it as developer productivity.

GitQuick reports a mean in first_commit_metrics and also computes a median, p90, sample size, and spread for the stage. The median describes the typical eligible PR. P90 shows the slow tail. The mean is useful for the Development Cycle Delay signal, but a few very old commits can move it sharply.

Why PR latency starts too late

Time to first review answers how quickly a visible PR receives a review. It says nothing about work that has not become a PR yet.

GitHub describes pull requests as a place to discuss and review work before it becomes part of a project. Its draft pull request workflow separates visibility from review readiness. A draft can exist before the author is ready to request formal review.

Google's engineering practices make a related case for small, self-contained changes: they reduce blocking because an author can send one portion for review while continuing with another.

Neither practice means every branch must become a PR immediately. Early drafts can create notification noise, expose unstable interfaces, or add review work before a direction is settled. The useful question is whether the delay is intentional and understood.

A current public snapshot

GitQuick's public Showcase listed 21 organizations when this article was drafted on October 25, 2026. The table uses the latest available run for three organizations. Each row is an organization-wide average across public PRs created in its stated window.

These numbers are not performance rankings. The organizations have different repositories, contribution models, automation, histories, and eligibility patterns. The public payload exposes the mean and sample size for this metric, not the underlying distribution or the reasons for each delay.

Kubernetes crossed GitQuick's default 24-hour signal threshold in this snapshot. That observation identifies a place to investigate. It does not prove that developers waited too long, that reviews were harmed, or that a policy change would improve delivery.

How the Development Cycle Delay signal works

GitQuick's shipped Development Cycle Delay signal reads the average first-commit-to-open duration. The default configuration triggers above 24 hours and marks values above 72 hours as critical. A sample below 10 reduces confidence.

Those defaults are triage settings, not universal engineering standards. A release repository, generated-code repository, and product repository can have legitimate differences. The signal is most useful when it leads to a drill-down by repository, team, PR size, and branch pattern.

The stronger analysis uses four checks:

1. Confirm the sample. Report the eligible PR count and watch for changes in coverage.
2. Read the distribution. Pair the mean with median and p90. A high mean with a modest median points to a small slow tail.
3. Segment the work. Compare repositories and branches before changing an organization-wide process.
4. Inspect examples. Review the longest-duration PRs for imported history, generated changes, release work, or genuinely hidden development.

Do not subtract stage medians or add them into a synthetic cycle time. Each stage can have a different eligible cohort.

What to change when the delay is real

If the drill-down shows avoidable incubation, start with a narrow experiment.

Open draft PRs earlier for work that benefits from design feedback or continuous integration. Keep drafts clearly labeled and avoid requesting reviewers until the author needs them. Split independent changes into smaller PRs. For dependent work, a stacked PR workflow can surface incremental layers without waiting for the entire feature.

Then compare like with like. Track first-commit-to-open median and p90 for the same repositories and branch scope before and after the experiment. Also watch PR size, time to first review, and review coverage. A shorter pre-PR gap is not an improvement if it only creates larger queues of ignored drafts.

GitQuick places First Commit to Open in Trend and surfaces Development Cycle Delay when the average crosses configured thresholds. The product helps teams locate a timing change. Repository metadata alone cannot explain why it happened.

Takeaway

Review responsiveness begins only after work becomes visible. First commit to PR open measures the missing interval before that point.

Use it as a workflow signal. Pair it with sample size, median, p90, repository context, and specific PR inspection. The goal is not to minimize every branch lifetime. It is to find work that stayed hidden longer than the team intended.

For the stages after a PR opens, read Your Cycle Time Is One Number. Your PR Pipeline Has Four Stages.. For change-over-time analysis, see Did Your Code Review Process Actually Improve?.

Explore the Kubernetes public Showcase, compare all public organizations, or try GitQuick on your organization.

Disclaimer: This analysis uses public GitHub metadata. Showcase snapshots cover the organization-wide windows shown above and were fetched on October 25, 2026. First-commit averages are means and can be influenced by outliers, rebases, cherry-picks, generated code, and imported history. Public metadata cannot measure focused coding time, developer productivity, code quality, intent, or causality. GitQuick is not affiliated with or endorsed by any organization mentioned.