What happens to newcomers' PRs in php-src — a year of data View as Markdown

Hi all,

#24613 https://github.com/php/php-src/pull/24613 (the duplicate-PR
policy) got me wondering what actually happens to PRs
from people coming to php-src for the first time. I looked at a year of
newcomers' work, and the data seemed interesting enough to share.

Scope: every PR opened between 24 Oct 2025 and 24 Oct 2026 whose author
opened
their very first php-src PR within that window. That's 831 PRs from 219
people,
about a quarter of all PRs in the period.

Key observations:

• Of 831 PRs, 418 were accepted, 157 closed without a merge, and the rest
  have
  no outcome yet.

• More newcomers keep arriving: first-time contributors grew from 1–5 a week
  early on to 5–12 by autumn, 219 over the year. PR volume followed, from
  2–5 a
  week to 30–70.

• Of the 157 closed, a reason was stated in the discussion for 124. The
  biggest
  groups: the change isn't wanted (38), the author closed it themselves
  (34),
  duplicates (31). Most "no"s are about fit or process (out of scope, needs
  an
  RFC, wrong target branch), not code quality. PRs called outright wrong in
  the
  code are rare.

• Newcomers write tests more often than the repo overall — 68% vs 52%.

• PRs with AI-written descriptions (113, about 14%) are accepted noticeably
  less
  often: around 20% vs 55%.

• 143 of 219 newcomers opened exactly 1 PR, 76 more than one, but 47 of
  them did
  it in a single day. 362 of 831 PRs were opened by people who fired off a
  pile
  at once.

• The top 10 authors opened 487 of 831 PRs (59%) and are accepted at 67%,
  while
  the other 209 authors sit at 27% (344 PRs).

• One author opened 232 PRs with 84% acceptance — that's 28% of all
  newcomer PRs
  and 46% of the accepted ones; without him overall acceptance drops from
  50%
  to 37%.

• Acceptance depends a lot on which PR it is for the author: the first PR
  29%,
  but after a first accepted one 66%. It's the first success that matters,
  not
  just continuing.

• 125 PRs are inactive (closed after silence, or open and idle for 50+
  days).

• Reaction speed tracks resolution: a first maintainer response within a
  day →
  median close ~20h, versus ~32 days when it takes over a week (Spearman
  0.53).

Full write-up, charts and method:
https://artukrainskiy.github.io/posts/newcomer-prs-in-php-src/
Raw per-PR data:
https://docs.google.com/spreadsheets/d/185nNwTnj-E6FNjAYLzPZ7ly4QJzEP9iHoUbPgHrrnR4/edit?usp=sharing

If there's interest, I'm happy to dig deeper so the numbers are solid
enough to
draw conclusions from. I can also share the classification prompts and the
scripts if that's useful.

One idea I'd like to put up for consideration, and I'd like to know if it'd
be
welcome. A bot that, when a PR opens, checks the mechanical things — no
tests, a
weak or empty description, no benchmarks in a PR aimed at optimization, the
wrong
target branch, an obvious duplicate — and leaves the author a note right
away. It
wouldn't judge whether a change is wanted, and it wouldn't add review time.
Part
of this can be done "for free" without an LLM, and by my rough estimate
even a
first-pass LLM review could be cheap enough.

An instant note there could spare maintainers the trivial round-trips and
let
contributors fix things before anyone even looks. My study suggests a fast
response leads to a faster close, and with the number of newcomers trending
up
this would help offload maintainers, at least on first-pass reviews and
trivial
checks. Larger projects already do this.

Is it worth prototyping?

--
Best regards,
Artem Ukrainskiy