Stop Chasing Pull Request Reviews in Slack

A while back, I pushed a follow-up commit on a pull request that had already been reviewed. The only change was the label on a single select dropdown option. It took two minutes to write and verify. Three working days later, the PR was still sitting there waiting for someone to look at it again.

I finally sent a private Slack message to the reviewer asking if they could take another look. They opened the link, glanced at the diff, and approved it almost immediately. The actual check took thirty seconds. The seventy-two hours of waiting happened because the notification got lost among everything else, and nobody looked until I sent a direct message.

I've done the same thing dozens of times. You push fixes addressing review comments and switch over to your next ticket. You don't ping on Slack because you assume GitHub sent an email and you don't want to interrupt anyone's morning. Then a few days pass, you realize the PR hasn't moved at all, and you end up writing the DM anyway.

Chasing people is the part developers hate

Ask engineers what frustrates them about code review, and the conversation usually turns to chasing people.

People on r/ExperiencedDevs describe repeatedly having to chase reviews across standups and Slack channels just to get someone to open a branch. Similar complaints show up in engineering management discussions, where developers having to hunt down reviewers comes up as a recurring source of friction. When you are the author, spending part of your morning asking around to see who has ten minutes to unblock you is just embarrassing.

The reviewer side feels just as bad. You are trying to get through a block of focused implementation work, and someone pings you about a PR you already know you need to get to. Or you get pinged while deep in an unfamiliar bug. It feels like someone asking you to drop your work to do theirs.

It also scrambles whatever order people were reviewing in. When reviews only happen after someone asks in chat, attention goes to whoever asks most often, or whoever is least hesitant about interrupting a teammate. People who quietly wait their turn or try to respect other people's calendar end up waiting the longest.

What happens to the PR channel

A common workaround is to set up a dedicated #dev-prs or #eng-reviews channel and have a bot post every new pull request there.

I've been on a few teams that tried this. It works for a while, then the channel gets noisy enough that people start muting it. At that point you're basically back where you started. When a channel gets dozens of automated messages every day with previews and CI check links, people stop reading through them.

Asynchronous standups run into the same thing. On teams running a daily "slackup," developers paste their list of open PRs into the thread. In practice, people rarely read that list unless someone gets explicitly @-tagged. A broadcast list feels more like status reporting for management than a request for a teammate, so people rarely treat it as something they need to act on.

Then you're right back to private DMs, because a direct message is much harder to ignore.

Why it keeps falling back to DMs

The main reason this keeps happening is that GitHub doesn't really have a concept of turns.

Who owns the next move on a pull request looked at this earlier: ownership moves between author and reviewer as new commits, comments, and CI runs land. But on GitHub, the headline state stays "Review requested" whether you're waiting on an author to address feedback or the author pushed five commits waiting on you. Notification emails easily get buried under check runs.

So authors ping on Slack because there's no way to know if someone is actively working through their queue or just never saw the update. And as Why pull requests sit for days between reviews pointed out, a surprising amount of the delay happens in that quiet gap between actions.

How teams try to work around it

Before reaching for dedicated tooling, teams usually try to patch this with process.

A dedicated review window can help. Some teams reserve the first part of the morning for reviews, which at least keeps interruptions out of the afternoon. The problem is that it doesn't help much when a change needs a specific domain owner who is busy with something else.

Teams also try status labels like needs-rereview or waiting-on-author. That can work for a while, but it relies on manual upkeep: people have to remember to update labels every time they push a commit or post a comment, and the tags can easily fall out of date.

Individual engineers often assemble their own systems from existing tools. One engineer I talked with tracks reviews through a saved GitHub filter for his team's open PRs alongside a Slack bot feed for Gerrit activity. Another relies on their email inbox, keeping open reviews as unread threads or browser tabs until they are handled. Those personal workflows work well for the people who maintain them, but they still depend on each person remembering to check their own setup.

What I wanted instead was a clean view of whose turn it is. If someone addressed my comments, I want that PR in my list with a marker that new commits landed. If CI broke on the author's branch while they were fixing things, I don't want to see it yet—it should stay on their list until it passes.

That's basically what PR Flow's queue does: it organizes pull requests into lanes based on who needs to act next. You don't have to announce on Slack that you pushed a fix, because the handoff state updates itself.

The boundary

A clearer queue makes ownership visible, but it doesn't change what people care about.

If a team evaluates developers only on how many tickets they close and treats reviewing code as an uncounted favor, pull requests are still going to sit. Seeing that a PR is waiting on you doesn't create extra hours in an overloaded senior's calendar, and it won't make a teammate care about unblocking someone else if the team culture ignores it.

I'm also not convinced any tool completely stops people from pinging each other. When someone has a release going out in an hour or a demo this afternoon, they aren't going to look at a board and wait patiently. They are going to open Slack. A visible queue helps with the work that people simply forgot about, but it won't change the instinct to jump the queue when someone is under pressure.