---
# System prepended metadata

title: Requesting Changes

---

### Requesting Changes on a PR-- Removing the Stigma (and clarifying when to do so)

First things first: writing a PR and having someone request changes does not make you a bad human/developer/anything. It's a natural part of the review process. The UI around it is big and scary, but there's no real reason to feel upset by it. All code review is important and should be considered carefully; requesting changes is just a mark of more importance that teams often don't use much for fear of offending someone. Let's agree to not overuse it, that it doesn't mean you're calling someone "bad", and to use it for the best of the team.

Requesting changes indicates that someone feels that code should probably not be sent to production. Some of the reasons it should be used are because there's a bug in the code or it could otherwise break something. One good rule of thumb is that, if you request changes, plan to have a synchronous conversation with the developer about the path forward. As the requester, you should be available to approve the PR once the changes are made. If you must request changes right before leaving for time off, please look for another developer who can take over the code review to make sure it reaches production in a timely manner. Otherwise, please ask the team if it would be okay if the PR was held until you returned from your time off.

Generally it is a best practice to let developers dismiss their own comments instead of the PR author doing so. Especially if there’s any possibility for controversy, the person who marks a comment as resolved should be the person who made the comment after they review if the way in which it was addressed satisfies their concern.