A code review policy defines who may approve pull requests and how many approvals are required before integration. Start with those two decisions, then expand the rules only when the team needs more complexity. section 3.3.4
Choose the policy as a team, balancing review quality, knowledge sharing, permissions, and delivery speed.
- Basic: allow team members who read or write code to approve, and require a single approval. section 3.3.4
- Improved: use granular permissions when needed—for example, allowing a group to view while limiting which groups may approve particular pull requests. section 3.3.4
- Advanced: require two approvers to support knowledge transfer and maintainability, while examining whether emergencies or absences create unacceptable delays. section 3.4.1
When enforcement defeats the policy
A team requires one approval per pull request, but authors ask for instant approvals in chat. Whoever sees the request approves without checking the code, and a QA engineer approves nearly everything. The policy exists, yet the workaround produces ineffective reviews, resentment, and stress. Treat enforcement and review quality as part of the policy’s practical design. section 7.1.1
Review the policy collaboratively after trying it. Record the decision and its rationale in the team’s working agreement, announce changes, and refine the rule when circumstances expose a bottleneck. section 3.4.1 section 3.5
