Pull requests mostly stall on who acts next, not on the code

Most advice about review is about the quality of the comments. A study of stalled pull requests published on arXiv on 18 September 2026 suggests the bigger problem is what happens after the comment is left: in most of the cases it examined, the review did not end in a wrong decision. It ended in no decision at all.

The study

Researchers at the University of Saskatchewan collected every pull request that had been marked inactive by a stale bot in 19 popular GitHub repositories, including Apache Beam, Grafana, gRPC, Home Assistant and QGIS. By default, a stale bot labels a pull request as stale after 60 days without activity and closes it after a further seven, so the dataset is, by construction, review that went quiet.

That came to 14,234 stalled pull requests and 164,562 review comments. The team then did three things:

• Classified the pull requests by type with a voting scheme across three open-source LLMs, with a human resolving three-way disagreements.
• Hand-coded random samples of review threads — 1,500 general threads and 1,452 inline threads — to build a taxonomy of why each one stopped. Coders agreed at an average Cohen's kappa of 0.74.
• Followed the people involved afterwards, checking whether contributors submitted again and whether the same reviewers reviewed their next ten pull requests.

What they found

Most stalls were coordination failures. In general review comments, collaboration and availability problems accounted for 76.60% of stalling reasons. The biggest subcategories were no interaction at all (17.80%), an unresponsive author (15.40%), an unresponsive reviewer (14.93%) and missing feedback after a first review (11.93%). Outright disagreement was rare: conflicts of perspective made up 2.60%.

Inline comments stalled differently. On threads attached to specific lines, communication and process issues were still the largest group at 47.31%, but the shape changed. The single biggest cause was an unresolved discussion (18.39%) — people engaged, then never converged on what to do. Close behind was final approval pending (14.39%): the substantive issues looked addressed, and the pull request still sat waiting for someone to say yes. Technical and dependency problems such as failing checks and configuration trouble made up 22.45%.

The authors' summary of the difference is the most useful line in the paper:

general comments tend to reveal stalling through disengagement or unclear ownership, while inline comments often reveal stalling through discussion without closure

Responsibility was usually shared. Mapping each cause to whoever held the next visible action, shared author–reviewer responsibility was the largest group in both channels: 35.07% for general comments and 36.02% for inline. In general comments, reviewer-side causes outweighed author-side ones, 32.86% to 20.27%. The authors are explicit that this is about where the next action sat, not blame.

What came after was thin. Of the 7,042 contributors who had a pull request stall, only 39.56% submitted another one to the same repository. Reviewers re-engaged with the same contributor on a later pull request 20.99% of the time.

The caveats, from the paper itself

The authors are careful about what their data can and cannot carry, and several of their limits matter for anyone reading this outside open source.

• Association, not cause. The retention and re-engagement figures are presented as patterns after a stall, not effects of it. Contributors leave for many reasons, and reviewer assignment shifts with workload and code ownership.
• No comparison group for the type finding. Feature and bug-fix pull requests made up over 77% of the stalled set, but the study did not compare against pull requests that did not stall, so it cannot say those types are more likely to stall.
• Only projects that use stale bots. All 19 repositories are popular, heavily automated open-source projects. The authors say patterns may differ in smaller projects, in industrial repositories and on other platforms.
• Interpretation is involved. Review comments are short and context-dependent, and some fit more than one category. Who "holds the next action" is read from the visible thread, which cannot show private conversations or intent. The type classification relies on LLMs and may still misclassify mixed-purpose pull requests.

The fair reading: a large, carefully coded description of how review stalls in one kind of setting, with no causal claims and a clear warning against reading likelihoods into the type breakdown.

Why this matters if you write specs

Open-source code review and an internal spec review differ in obvious ways. Contributors are often volunteers and strangers; a product team has a manager, a deadline and a calendar. But the two failure shapes in this paper are not about volunteers. They are about the medium, and anyone who has watched a spec's comment threads go quiet will recognise both.

Disengagement and unclear ownership. A spec circulated for async review with no named reviewer per section is the no-interaction category in waiting. Everyone can comment; nobody has to.

Discussion without closure. The inline-comment pattern is the one product teams live with. A reviewer raises a real question, the author replies with a reasonable answer and an offer to change it "if you prefer", and the thread stops there. Nobody declines, nobody accepts, and the spec moves on with the question still open. We have argued before that a thread which goes two rounds without converging is a conversation, not a comment. This paper puts a number on how often that moment is where review actually ends.

Final approval pending is the third one worth stealing. In 14.39% of inline stalls, the substantive issues appeared to be addressed and the pull request was still waiting for a formal yes. It was waiting on a decision that sat with a reviewer or maintainer, and nobody made it — the same failure the spec review meeting post addresses by naming a decider before the meeting starts.

The authors' own recommendations translate almost directly:

1. Label whose move it is. They suggest explicit states — awaiting author, awaiting reviewer, awaiting a decision, blocked by a dependency — instead of a generic "inactive". On a spec, that is a status on each open thread rather than a single document-level "in review".
2. Say whether a comment blocks. A useful review comment, they write, states what change is requested, why, how the author can show it is done, and whether it is blocking or optional.
3. Record an outcome when a discussion turns into a design question. Their examples: accepted with constraints, revision required with a checklist, deferred with a rationale, or closed with an explanation.

On that last point, their phrasing is worth keeping:

This practice transforms open-ended discussion into a bounded plan and reduces the likelihood that uncertainty evolves into silence.

That is also the case for treating a resolved thread as a record rather than clutter: the outcome written into the thread is the decision log entry that would otherwise never be written. The companion post on async spec review covers the comment types and resolution rules that make that work.

What to take from it

Not that reviewers are lazy or authors flaky. The paper goes out of its way to avoid that reading, and its data does not support it.

The narrower point holds up: when review runs asynchronously, the most common way it fails is not a bad comment but an unowned next step. Every open thread should say who acts next and what would close it. A thread that says neither is how a spec ends up approved by default.

FAQ

What was studied? 14,234 stalled pull requests and 164,562 review comments from 19 open-source repositories that use stale bots.

Why did they stall? Mostly coordination: 76.60% of general-comment stalling reasons were collaboration and availability problems.

Did stalls drive people away? Only 39.56% of affected contributors came back, but the authors call this an association, not a cause.

The lesson for spec review? Give every open thread an owner for the next action and a stated way to close it.