"Request changes" should be used sparingly in code reviews

The cost of using "Request changes"

When you click "Request changes", you're saying the code is fundamentally broken and can't ship as-is. This comes with hidden costs beyond the immediate feedback.

Most suggestions don't need to halt development entirely. Minor refactoring ideas, style preferences, or optimization suggestions can be addressed in follow-up work without stopping the current PR.

Once you request changes, you become responsible for approving the PR later. This creates a bottleneck where the author has to wait for you specifically to review again, even if other team members think the changes are sufficient.

Frequent blocking creates a culture of fear around submitting code. When developers expect their PRs to be blocked regularly, they become hesitant to experiment, take on challenging tasks, or submit incremental improvements. This slows down team velocity and discourages iterative development.

The human impact

"Request changes" carries psychological weight that's often overlooked. It says "this is not acceptable" rather than "here's a suggestion for improvement." This distinction matters, especially for junior developers or newcomers who might already feel uncertain about their contributions.

When you treat variable naming suggestions with the same urgency as critical performance bugs, you send mixed signals about priorities. Authors lose their ability to distinguish what truly needs immediate attention.

Over time, frequent blocking creates a defensive mindset. Developers start optimizing for avoiding criticism rather than learning and growth. They second-guess valid approaches and become paralyzed by fear of rejection.

When to block vs. when to approve

Use "Request changes" for genuine deal-breakers: performance regressions, security vulnerabilities, critical anti-patterns, or completely missing business requirements. These are situations where the code absolutely cannot ship as-is.

For everything else—style preferences, micro-optimizations, suggestions for future refactoring—use "Comment" instead. This communicates that the PR needs updates without the harsh finality of a block.

If the PR is ready to ship but you have non-blocking feedback, approve it and add your suggestions as comments for future consideration. This keeps the code moving while preserving your insights.

When frequent blocking indicates process issues

If you find yourself using "Request changes" constantly, this might indicate a problem with your development process rather than code quality.

When major issues only surface during review, it usually means communication broke down earlier. Developers might be working in isolation too long, technical design discussions aren't happening upfront, or requirements weren't clear from the start.

In healthy development workflows, blocking issues should be rare at review time. They should have been caught during design, pair programming, or earlier collaboration. Code review becomes about final polish and knowledge sharing, not major course corrections.

For teams that want to track non-blocking suggestions, consider setting up a separate process for follow-up items. This maintains quality without sacrificing velocity.

Conclusion

Reserve "Request changes" for genuine blockers that must be fixed before shipping. Everything else can be handled more gracefully, leading to better developer experience and team collaboration.

This is especially important in open source projects. New contributors who spend their weekend implementing a feature and then receive a blocking review over minor style issues can feel discouraged. The red "request changes" label feels like public rejection. Since these contributors aren't obligated to stay, an unwelcoming review process can drive them away.

Keep reviews constructive, focus on what truly matters, and remember that fostering a positive culture often matters more than enforcing every minor preference.