How to Triage a Growing Pull Request Review Queue

I usually check backend changes first. I look at PR titles to guess which change would be more valuable to get through review. It is a guess. A title gives me very little to go on.

If a peer asks me directly for a review, that can move their PR ahead of the backend work. I assume they need me to unblock them. I do not necessarily know whether they have stopped working or just want to get that change finished.

That is the order I fall back on. Someone else looking at the same queue could choose differently, and the titles would give us very little basis for settling it.

Check whether there is work you can do

Before comparing priorities, check what each PR needs from you. A question on a change you already reviewed may only need a reply. A PR you have never opened is a different commitment; you still have to understand the change before you can judge it.

Open the conversation before deciding that every returned PR needs another full review. The author might have explained why your concern does not apply. You may owe them a decision with no new code to inspect. What happened after your last review determines what to open next.

Also remove work you cannot move yet from the immediate review list. If the author still needs to resolve a conflict before the requested review can proceed, make that handoff explicit. Keep it somewhere you can return to; repeatedly opening it does not resolve the conflict.

For a PR whose status is unclear, I would write down the next action before reserving time for the diff. Sometimes that means asking the author what they are waiting for.

A starting order, with room to interrupt it

I would use this as a starting order for a growing review queue:

1. Work that came back to you. Check whether a reply or a focused re-review can finish a handoff already in progress.
2. A change blocking someone else's next step. Establish what they cannot do until your review is finished.
3. A time-sensitive change, or one needing your particular judgement. Check the deadline and whether another reviewer could do it.
4. A handoff that has gone quiet. Find out whether the work is still wanted and whose move it is.
5. Other ready changes. Choose a review that fits the time you can actually give it.

Returned work gets the first check because a reply or a focused fix might finish an existing handoff. If it needs a long review, a confirmed blocker can go ahead of it. Treat the order as a proposal for your team. A release fix with an agreed deadline can go straight to the top. A reply that needs a careful architectural discussion may have to wait for a longer review window.

For a direct request, ask one small follow-up when the priority is unclear: what is waiting on this review? The answer might be another PR, a release, or the author's ability to continue. It might also be that they would like it finished today. Those are different reasons to interrupt your current work.

Keep the reason beside the item if you maintain a shared list. “Needed before the next layer can land” gives another reviewer enough information to question the order. “High priority” leaves them guessing again.

Give age a specific meaning

A PR opened weeks ago can have come back to you this morning. Another might have been waiting for your first response since last Thursday. Sorting both by their opening date obscures the handoff you are responsible for.

For the work you owe, use the time since it became actionable for you. Keep the original age available when checking whether a change has spent too long moving around the team.

When the other priorities look equal, I choose the newer PR first. That is my tie-breaker. It does leave a question about the older work: if new changes keep arriving, when will I get to it?

For a queue using that order, I would check the oldest waiting handoffs at the start of each review session. If the same PR is still there, choose a review window or ask whether the author still wants it reviewed. The stale-PR guide covers those cases separately.

Queue position does not decide review depth

Choosing a small fix next can be sensible when you have a short gap. Be explicit that you are using that gap for a quick review. Otherwise an author with a complex change cannot tell whether you have reserved time for it or keep passing over it.

A small diff may need careful scrutiny. A change to permissions or stored data can deserve a longer review than its line count suggests. Decide the scope of the review after reading what the change affects.

If the backlog keeps growing, take the list of waiting work to whoever decides how reviewer time is allocated. The queue order cannot create review capacity or make a thousand-line PR reviewable. That needs a decision about splitting the change or assigning another reviewer.

Keep the queue out of individual performance reviews. A PR waiting for specialist review can sit behind several routine changes, even when its author has done everything asked of them.

Seeing the reason in the queue

In PR Flow, Urgency is the default ordering. Quick wins puts smaller changes first. You can switch between them in Filters, and the choice applies to the queue and board together.

The reason chip explains what needs you and what pushed a PR up the list. Open it when the order surprises you; check the reason against the conversation before deciding to follow it. The review queue and pull request dashboard pages show that part of the product.

A queue cannot know that a colleague has stopped their other work unless that dependency is made visible. You still need to ask when the reason for urgency is missing.

I am comfortable moving a peer's direct request ahead of my usual backend-first order. I am less sure what to do when the same person always asks directly and another colleague quietly waits. I would want to check that before treating the pings as our team's agreed priorities.