Who Owns the Next Move on a Pull Request?

I'll leave comments on a teammate's pull request, request a change or two, and from that point it stops feeling like mine. It's their move now. Except they don't always know that, because nothing actually told them, and more than once I've ended up pinging someone on Slack to ask if they'd seen what I left them days earlier.

They hadn't. The review had been sitting there, fully addressed in my head, completely invisible in theirs.

That's not a one-off, either — I checked. Across the PRs I've reviewed rather than authored over the last six months or so, the median wait after I leave something is around fifteen hours before anyone touches the PR again, and a real chunk of them run past three days. Why pull requests sit for days between reviews has the full breakdown; the short version is that whose move it is and whether they know it are two different things.

Pull request ownership changes hands based on what just happened. GitHub doesn't show that anywhere the way it shows "assigned to Arpad" on a ticket, and neither its UI nor most people's mental model of a review queue tracks the handoff clearly enough to answer, at any given moment, whose move it actually is.

Open, review requested, approved

GitHub gives you a handful of headline states for a pull request: open, then whatever the review sidebar says — requested, approved, changes requested. Put those next to the question that actually matters, who has to do something next, and most of them don't answer it.

"Open" covers a PR waiting on the author to push a fix, a PR waiting on a reviewer who hasn't looked yet, a PR that's fully approved with nothing left but a merge button, and a PR everyone has quietly forgotten about. Same word, four different situations.

"Review requested" freezes at the moment the request was made. It doesn't update when the reviewer answers with a plain comment instead of a formal review, or when the author pushes three commits addressing half the feedback and leaving the rest. It can sit there long after the actual next move has already changed hands twice.

"Approved" misleads people the most. It usually means the reviewer is done — until a new commit lands after the approval, and then whether that approval still counts depends on branch protection settings most repos never configured on purpose. GitHub will keep showing the green check either way.

GitHub is tracking events here — a review submitted, a comment posted, a check finishing. Reading who owns the next move means holding several of those in your head at once, which is more than most tools, including GitHub's own UI, actually attempt.

A model that actually answers it

I've seen this framed well once, on r/ExperiencedDevs, in a thread about figuring out who's actually blocking a given pull request: the blocking person is the reviewer whenever the PR is new or new changes just landed, and it flips to the author the moment a build fails or changes get requested. Nobody handed that person a framework. It's just what a PR does, described from watching it happen.

Roughly, the handoffs look like this:

• A PR opens. The ball sits with whoever's assigned to review it — or with nobody, if no one was assigned, which is its own failure mode and one no dashboard can rescue you from.
• A reviewer requests changes, or leaves a comment that's clearly blocking. The ball moves to the author.
• The author pushes a fix. That push is what actually kicks off CI, not the review comment itself — and if CI comes back red, the ball sits with whoever owns green builds on that repo, usually the author, until it's green again.
• Once CI is green, the reviewer looks again and approves. The ball is back with the author, to merge.
• A new commit lands after that approval anyway — a rebase, a last small tweak. Whether the ball just moved back to the reviewer depends on that same branch protection setting from above, and most of the time nobody checks. This is also where I'll admit the model doesn't actually resolve anything — it just tells you which unresolved thing you're looking at.

A row that just says a PR is "open" or has "3 comments" tells you what happened, not what to do about it.

Where that model stops helping

None of this makes anyone act. Naming whose move it is doesn't make an overloaded reviewer less overloaded, and it doesn't make a team that's quietly deprioritized review start treating it as urgent again. A fair amount of what looks like slow reviews is really nobody having the bandwidth for them, and a clearer queue doesn't manufacture bandwidth out of nothing. If three senior engineers are the only people qualified to review a category of change, telling them more precisely that it's their move doesn't make there be more of them.

We still get the occasional Slack ping on my team — sometimes about something new, sometimes about a PR that's been sitting long enough that someone finally noticed. Most of the time I've already seen it, because it showed up on my own list the moment it needed me. The person doing the pinging has no way to know that; their picture of who's on top of what doesn't have anywhere to look it up, so pinging is the only move they have. That was me too, for a long time, before I had anywhere for that state to actually live.

If you want to see this model applied instead of just described: PR Flow's queue sorts every open PR into needs you, waiting on someone else, or done, from signals like who was asked to review, whether a requested change got a reply, whether CI is green, whether it's approved.

It reads all of that from your provider, so it inherits the provider's blind spots too. If your repo doesn't require re-approval after a new commit, PR Flow won't second-guess a stale approval any more than GitHub does. The board view just puts the lanes in front of you as columns instead of a list. It doesn't chase anyone, and it doesn't make a review happen faster.

I don't know that there's a way to get rid of the Slack ping entirely, and I'm not sure I'd want to — someone deciding a review matters enough to go chase it is a reasonable thing to happen. What I'd rather was different is smaller: whether the person doing the chasing already knew, or was finding out for the first time that something had been sitting.