2025 Contributor Experience

The 10x First-Timer Penalty

First-time contributors wait 10.9x longer for review. The onboarding bottleneck is worse than you think.

10.9x

Wait Multiplier

for first-time contributors

Based on 117,413 reviewed PRs | GitHub Archive / BigQuery | October 2025

The Wait Time Gap

In repositories that actually do code review, first-time contributors wait a median of 15.2 hours for their PRs to get attention. Repeat contributors? Just 1.4 hours. That's a 10.9x difference.

First-time Contributors

15.2h

median wait time

Repeat Contributors

1.4h

median wait time

Wait Time Comparison

Repeat Contributors1.4hFirst-Time Contributors15.2h10.9x longer0h16h

Median Wait Time for Code Review (Hours) - Reviewed PRs Only

05101520First-timeRepeat
Contributor TypePRs AnalyzedMedian WaitP90 Wait
First-time contributor38,99315.2h295.4h (12.3 days)
Repeat contributor78,4201.4h94.4h (3.9 days)

"First-time contributors wait 10.9x longer for review—that's 15.2 hours vs 1.4 hours."

Why It Happens

The 10x penalty isn't random—it reflects how review queues naturally prioritize familiar names. Understanding the dynamics helps explain why fixing this requires intentional effort.

Review Queue Priority

Maintainers naturally prioritize PRs from known contributors. Unknown names get pushed to the bottom of the mental queue, even without conscious bias.

Trust Dynamics

Repeat contributors have established trust. Maintainers know their code quality and communication style. First-timers require more careful scrutiny, making reviews feel "heavier."

Context Switching Cost

Reviewing a first-timer's PR often means explaining project conventions, which takes more time than rubber-stamping a trusted contributor's routine change.

No Dedicated Triage

Most projects don't have dedicated first-timer queues or reviewers. New PRs compete in the same pool as established contributors—and lose.

Impact on OSS Community Growth

Contributor Dropout Is Real

  • Studies show contributors who don't get feedback within 48 hours are 3x less likely to submit a second PR.
  • The P90 wait of 12.3 days means 1 in 10 first-timers wait over two weeks for any response.
  • By then, most have moved on—their enthusiasm replaced by frustration or simply other priorities.

Retention Crisis

The biggest factor in contributor retention is the first experience. A 15-hour wait signals "we're not that interested."

Diversity Impact

Contributors with less time to invest—caregivers, multiple job holders, different time zones—are disproportionately affected.

Maintainer Burden

Fewer new contributors becoming regulars means more work falls on existing maintainers, accelerating burnout.

"The P90 wait for new contributors is 12.3 days. Would you stick around?"

How Top Projects Fix It

Projects that prioritize contributor growth have found practical ways to reduce the first-timer penalty. These aren't theoretical—they're battle-tested practices from successful open source projects.

Dedicated First-Timer Labels

Use GitHub labels like "first-time-contributor" and set up notifications or filters specifically for these PRs. Make them impossible to ignore.

Response SLAs for First-Timers

Set explicit targets: "All first-time PRs get a response within 24 hours." Even a simple "Thanks, we'll review this!" dramatically improves retention.

Mentor Pairing Programs

Assign experienced contributors to shepherd first-time PRs. This spreads the load and creates the relationships that convert one-time contributors into regulars.

Automated Welcome Bots

Deploy bots that instantly thank first-time contributors, explain the review process, and set expectations. Immediate acknowledgment prevents the "is anyone listening?" anxiety.

Track and Report the Metric

You can't improve what you don't measure. Add first-timer response time to your project's health dashboard and review it monthly.

🔥 Our Take

A 10x penalty isn't a bug—it's a design choice. And it's the wrong one.

The first-contribution experience sets the tone for everything that follows. A 15-hour wait tells new contributors they're not valued. If your project wants sustainable growth and contributor diversity, you need to treat first-time PRs differently—not as low priority work, but as your highest-leverage investment.

The fix is simple: Label first-time PRs, set response SLAs, and track the metric. The small effort pays dividends in contributor retention and project sustainability.

Context: The Global vs Reviewed Gap

The 10.9x penalty is specific to reviewed PRs—repositories that actually practice code review. When we look at all GitHub PRs (including instant self-merges), the penalty appears smaller because most PRs skip review entirely.

All GitHub PRs (Global)

37.5%(Improved from 53% in 2024)

22h vs 16h

Reviewed PRs Only (Enterprise)

10.9x(The real bottleneck)

15.2h vs 1.4h

The improvement in global stats (53% to 38%) is encouraging, but the 10.9x penalty in reviewed repos shows the onboarding problem is concentrated where it matters most: in teams doing actual code review.

Related Research

Methodology

This analysis is based on 117,413 pull requests that received at least one code review event, sourced from GitHub Archive / BigQuery during October 2025. A "first-time contributor" is defined as someone with no prior merged PRs to that repository. Wait time is measured from PR creation to first review event. The 10.9x multiplier is calculated from median wait times (15.2h / 1.4h). For full methodology, see the complete study.

Track your first-time contributor metrics

CodePulse shows you exactly how long different contributor types wait for review in your repos.