A blocking issue is serious enough to stop pull-request approval until it is resolved. Teams should define these boundaries before reviews begin, because shared rules prevent disagreements and delays. section 3.3.3 section 4.2.3
Classify review concerns according to the team’s agreed threshold:
- Block core functionality that fails to meet the intended behavior described by the pull request. section 3.3.3
- Do not block style preferences, minor formatting discrepancies, documentation nitpicks, optional features, minor refactors, or unrelated improvements when they can be handled separately. section 3.3.3
- Revisit ambiguous cases during retrospectives or team meetings, then add the decision to the team’s guidelines. section 3.3.3 section 3.5
Make the signal explicit
Use a clear comment signal such as “needs change: This is importing the wrong module 'ts/widgets'. It should be importing 'ts/components'.” A team can reserve “needs change,” “needs rework,” or “align” for comments that block by default, while treating “levelup” suggestions as nonblocking. section 6.1.2
Figure 3.3 Blocking vs. nonblocking issues
Compare blocking and nonblocking issue categories when establishing review guidelines. section 3.3.3
