"Dismiss Review": The Underrated GitHub Feature You're Probably Not Using

If you’ve ever hesitated to hit “Request Changes” on a GitHub pull request (PR), you’re not alone. In so may teams I've worked with, it feels like there's a quiet tension around that big red "❌". It feels heavy, negative, maybe even a hit to the author's morale. Like you’ve just pulled the emergency brake on someone else's momentum. But what if I told you that GitHub has a built-in feature that solves this problem — and almost no one uses it? Let me introduce you to: Dismiss Review. Why "Request Changes" Feels Like a Last Resort Here’s what often happens: You're reviewing a PR and notice a few things worth changing. They're important and they do need to be addressed, but they are small, easy fixes. And as a reviewer, you may also be aware that you could be wrong about your requested change - it may already be addressed elsewhere or you could be misunderstanding the scenario. You could leave a comment with “Please fix this,” but without the formal red “Request Changes” option. If you post as a comment though, you are communicating that this is non-blocking, which means you'd be okay with no change. On the other hand, hitting “Request Changes” puts a red "❌" on the PR—and that feels like you're putting up a roadblock. There's a very significant risk that you will be busy later and unable to come back to re-review in a timely fashion. As a reviewer, you worry: Will this discourage the author? Will it delay merging until you can come back and review it again? So what do most people do? They avoid using “Request Changes” at all - unless absolutely necessary — leaving feedback as a "Comment" even when it requests what we believe are important requested changes. But Here’s the Thing… You can dismiss a review. Let me say that again: PR authors with "write" access can dismiss a review once the feedback has been addressed. This is built-in GitHub functionality: simply click the ... menu next to a review and hit “Dismiss Review”: After dismissing, the original feedback stays visible for transparency, but it’s no longer blocking the merge. It’s like saying: “Hey, this was useful feedback and it needed to be addressed, but now that it's resolved, we’re good to go—even if the reviewer doesn't come back to confirm.” In fact, there's even a place for you as the PR author to explain why you are dismissing. And ALL of these are perfect reasons to dismiss: "Changes applied, per feedback. Dismissing." "Changes applied and original reviewer is on PTO. Dismissing." "Per my reply, the concern raised is addressed elsewhere in the code. Dismissing." So Why Aren’t More People Doing This? The short and sad answer seems to be: hardly anyone knows this feature exists. And without knowing that, reviewers are hesitant to be honest. Authors are hesitant to move forward. That’s bad for everyone. Let's Normalize a Better Workflow Here’s what I suggest: As reviewers, feel empowered to “Request Changes” when something actually needs to change—even small things. It's clearer and more actionable for the author. As authors, feel empowered to address the feedback and dismiss the review (with a reason) once you’ve done the work. Especially if the reviewer is senior and busy—it’s not disrespectful, it’s responsible. You can also re-request their review, but that subsequent re-review won't block your merge if others have approved. As reviewers, communicate your intent. I often say: “Feel free to dismiss this review once these are addressed.” This lets the author know I don’t need to come back and re-review—it’s not about red tape, it’s about getting things right. Conversely, if I say "let's talk about this" or "I'm a bit worried about this", I would hope it's a clear signal that allowing time for a re-review is probably expected on my part, rather than dismissing. As teams, normalize trust and ownership. The GitHub workflow is a tool. At the end of the day, it comes down to people acting responsibly, clearly, and with mutual trust. TL;DR “Request Changes” is valuable—but relatively unknown. “Dismiss Review” is the missing puzzle piece that unlocks a healthier review culture. You can give and receive better feedback without slowing down merges. Let’s use the tools GitHub gives us—and trust each other to use them well. WDYT? Are you already using the Dismiss Changes feature? Are you worried about abuse/misuse? Have you run into this conundrum yourself? Lmk in the comments. And thanks for reading!

Apr 13, 2025 - 02:36

"Dismiss Review": The Underrated GitHub Feature You're *Probably* Not Using

If you’ve ever hesitated to hit “Request Changes” on a GitHub pull request (PR), you’re not alone.

In so may teams I've worked with, it feels like there's a quiet tension around that big red "❌". It feels heavy, negative, maybe even a hit to the author's morale. Like you’ve just pulled the emergency brake on someone else's momentum.

But what if I told you that GitHub has a built-in feature that solves this problem — and almost no one uses it?

Let me introduce you to: Dismiss Review.

Why "Request Changes" Feels Like a Last Resort

Here’s what often happens:

You're reviewing a PR and notice a few things worth changing. They're important and they do need to be addressed, but they are small, easy fixes. And as a reviewer, you may also be aware that you could be wrong about your requested change - it may already be addressed elsewhere or you could be misunderstanding the scenario.
You could leave a comment with “Please fix this,” but without the formal red “Request Changes” option. If you post as a comment though, you are communicating that this is non-blocking, which means you'd be okay with no change.
On the other hand, hitting “Request Changes” puts a red "❌" on the PR—and that feels like you're putting up a roadblock. There's a very significant risk that you will be busy later and unable to come back to re-review in a timely fashion.
As a reviewer, you worry: Will this discourage the author? Will it delay merging until you can come back and review it again?

So what do most people do?

They avoid using “Request Changes” at all - unless absolutely necessary — leaving feedback as a "Comment" even when it requests what we believe are important requested changes.

But Here’s the Thing…

You can dismiss a review.

Let me say that again: PR authors with "write" access can dismiss a review once the feedback has been addressed.

This is built-in GitHub functionality: simply click the ... menu next to a review and hit “Dismiss Review”:

After dismissing, the original feedback stays visible for transparency, but it’s no longer blocking the merge.

It’s like saying:

“Hey, this was useful feedback and it needed to be addressed, but now that it's resolved, we’re good to go—even if the reviewer doesn't come back to confirm.”

In fact, there's even a place for you as the PR author to explain why you are dismissing. And ALL of these are perfect reasons to dismiss:

"Changes applied, per feedback. Dismissing."
"Changes applied and original reviewer is on PTO. Dismissing."
"Per my reply, the concern raised is addressed elsewhere in the code. Dismissing."

So Why Aren’t More People Doing This?

The short and sad answer seems to be: hardly anyone knows this feature exists.

And without knowing that, reviewers are hesitant to be honest. Authors are hesitant to move forward.

That’s bad for everyone.

Let's Normalize a Better Workflow

Here’s what I suggest:

As reviewers, feel empowered to “Request Changes” when something actually needs to change—even small things.

It's clearer and more actionable for the author.
As authors, feel empowered to address the feedback and dismiss the review (with a reason) once you’ve done the work.

Especially if the reviewer is senior and busy—it’s not disrespectful, it’s responsible. You can also re-request their review, but that subsequent re-review won't block your merge if others have approved.
As reviewers, communicate your intent.

I often say: “Feel free to dismiss this review once these are addressed.”

This lets the author know I don’t need to come back and re-review—it’s not about red tape, it’s about getting things right.
Conversely, if I say "let's talk about this" or "I'm a bit worried about this", I would hope it's a clear signal that allowing time for a re-review is probably expected on my part, rather than dismissing.
As teams, normalize trust and ownership.

The GitHub workflow is a tool. At the end of the day, it comes down to people acting responsibly, clearly, and with mutual trust.

TL;DR

“Request Changes” is valuable—but relatively unknown.
“Dismiss Review” is the missing puzzle piece that unlocks a healthier review culture.
You can give and receive better feedback without slowing down merges.
Let’s use the tools GitHub gives us—and trust each other to use them well.

WDYT?

Are you already using the Dismiss Changes feature?
Are you worried about abuse/misuse?
Have you run into this conundrum yourself?

Lmk in the comments. And thanks for reading!