Stop losing review requests: fixing the PR review inbox

Somewhere in your GitHub notifications is a review request from four days ago. The author pinged once in Slack, felt annoying, and stopped. The PR is rotting; the branch is drifting toward conflicts. Nobody decided this; it’s just what happens when review requests travel through a channel built for everything.

Why the default funnel fails

The notification stream is unranked and unbounded: a review request, the one item where a teammate is blocked on you, gets the same row as a bot comment. Email filters help until they file the request neatly into a folder nobody opens. And the morning sweep (“mark all as read”) is where review requests go to die. The structural problem: requests for your attention live mixed with information that merely mentions you.

Make a view that answers “who waits on me?”

GitHub’s own search can build a serviceable inbox; most developers just never wire it up. Bookmark these:

• is:open is:pr review-requested:@me archived:false: everything explicitly waiting on your review, across all repos.
• is:open is:pr reviewed-by:@me -review-requested:@me: PRs you reviewed that may have replied to you (re-review limbo, the second-biggest leak).
• is:open is:pr author:@me review:changes_requested: your own PRs blocked on your response; authors leak too.

The discipline is checking the views on a schedule, which is the next fix.

An SLA plus review blocks beats heroics

Google’s review-speed guidance is blunt: respond within one business day at the slowest, because slow review taxes the whole team’s velocity and morale. The workable pattern isn’t interrupting deep work for every request; it’s two or three scheduled review blocks a day (start of day, post-lunch) plus the SLA as a backstop. Predictability is the actual product: an author who knows the longest possible wait can plan; one staring at silence pings, escalates, or gives up.

The first response doesn’t need to be the full review: “looked at the description, I’m the right reviewer, full pass by 3pm” unblocks more than it sounds like it should.

Drain the queue by unblock value, not arrival order

When the block starts, don’t review oldest-first. Triage by what unblocks the most: PRs with no reviewer yet beat PRs with two; a teammate’s release-blocker beats a refactor; a re-review (author already responded) usually costs minutes and clears a thread someone is anxiously refreshing. Five minutes of queue triage routinely saves a teammate’s afternoon.

Tooling: this is a solved-shape problem

Everything above is workflow, and it works with bookmarks and a calendar. The tooling version is having the funnel built in, which is how we approached it in Pyor (our product, free for individuals): a pull-request dashboard for everything that matters to you (authored, assigned, awaiting your review), a comments inbox that gathers every thread and reply across repos into one feed, and a team view that ranks open PRs by how much you can unblock, surfacing the ones with no reviewer first. The queue stops being something you remember to check and becomes something you look at once and act on. For what to do when the PR you open is enormous, see reviewing large PRs.