Read-only PR review timing brief for aiohttp: long-tail review waits

[xpinc17]

Hi aiohttp maintainers,

I put together a small read-only PR review timing brief for aio-libs/aiohttp using public GitHub data only. Nothing was installed, and nothing was posted to the repo.

This is not meant as criticism. The median first-review wait in this window looks fast, which suggests many PRs are moving quickly. The useful signal is the long tail: a subset of PRs waited multiple days for first review, and a few approved PRs stayed unmerged for more than 48 hours.

---

PR Review Bottleneck Brief

Window: PRs created 2026-04-09 → 2026-06-08
Source: Public GitHub data, read-only
PRs analyzed: 493
Signal: Sufficient, long-tail focused

Snapshot

Metric	Value
PRs waited >48h for first review	61
Total first-review wait	314.6 cumulative PR-days
Median first-review wait	0.7h
Approved PRs idle >48h before merge	5

What stood out

• Many PRs appear to get attention quickly.
• 61 of 493 analyzed PRs waited more than 48h for a first review.
• The longest observed waits were measured in days, not hours.
• 5 approved PRs remained unmerged for more than 48h, suggesting merge-ready work can still fall out of view.

Longest observed first-review waits

These are longest observed waits in the window, not typical PRs.

• #12392 fix(resolver): handle None result.service from getnameinfo() — 14.9 days
• #12672 Improve HTTPS-on-HTTP parser error — 9.2 days
• #12415 fix(docs): widen field-list labels so Parameters: isn't a column — 7.5 days

Why I’m sharing

I’m building ApprovalOps, which is designed to surface aging review items earlier before they disappear from the active queue. In this historical window, the estimate suggests it could have flagged about 30% of observable review-wait time earlier. That is a retrospective estimate, not a guarantee.

Caveats

• This is a historical public-data estimate, not a live production measurement.
• Public GitHub data may not reflect internal reviewer load, branch policy, or private context.
• Aggregate wait metrics may use merge or close time as a fallback when first-review timestamps are unavailable; the representative examples above only include PRs with observed first-review timestamps.

If this is useful, I’d be happy to share the methodology or run the same read-only brief for a narrower or different timeframe.