Read-only PR review timing brief for stdlib: a few long-tail review waits

[xpinc17]

Hi stdlib maintainers,

I put together a short read-only PR review timing brief for stdlib-js/stdlib, based only on public GitHub data. Nothing was installed, and nothing was posted or changed in the repo.

This is not meant as a criticism of the project. The overall review flow looks fairly healthy, but I thought the long-tail cases might still be useful to surface.

What stood out

For PRs created between 2026-05-25 and 2026-06-08:

Metric	Observed value
PRs analyzed	406
PRs waiting >48h for first review	6
Approved PRs idle >48h after last approval	0
Total review-wait, cumulative across PRs	68 PR-days
Median first-review wait	2.8h

The median first-review wait is low, and there were no observed approved-but-idle PRs over 48h in this window. The main signal is narrower: a small number of PRs accounted for a noticeable share of the observed review-wait time.

Longest observed first-review waits

These are longest observed waits in this window, not typical PRs:

• #12289 — 147.7h
• #12443 — 134.4h
• #12522 — 90.6h

Why I’m sharing

The pattern here is not broad review slowness. It is more like occasional long-tail review wait in an otherwise active queue.

ApprovalOps is a small tool I’m building to surface aging review items earlier. In this historical window, it would have flagged an estimated 50% of observable review-wait time earlier, about 34.1 cumulative PR-days. That is a retrospective estimate, not a guarantee.

Caveats

• This is based only on public GitHub data.
• It does not know internal maintainer context, reviewer load, branch protection, or project policy.
• Aggregate first-review metrics may use merge or close time as a fallback when no first-review timestamp is visible.
• The examples above only include PRs with observed first-review timestamps.

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