Approval and Blocking Criteria in Code Review

Approval and blocking criteria define which conditions a code change must meet before it can proceed. Clear separation of required fixes from optional suggestions makes reviews safer, more consistent, and less contentious.

Approval and blocking criteria are the explicit standards reviewers use to decide whether a change can proceed or needs revision. They commonly cover correctness, tests, security, compatibility, and adherence to the design or requirements. The criteria should be relevant to the change and understandable to both authors and reviewers.

A blocking issue is one that must be resolved before the reviewer is willing to approve, or before the change can safely be merged. Examples include a reproducible bug, a data-loss risk, a failing required check, or behavior that violates an agreed requirement. Review comments should explain the impact and, when possible, point to a concrete resolution.

Not every review comment is a blocker. Style preferences, optional refactors, and questions for future work should be labeled or phrased so that authors do not mistake them for merge conditions. Teams often use conventions such as severity labels, explicit “blocking” language, or separate follow-up tickets.

Criteria may be enforced by people, automation, or both. Tests and static checks can catch objective conditions, while reviewers assess context, design trade-offs, and risks that tools cannot reliably judge. Passing automated checks does not by itself prove that a change is correct or appropriate.

Approval does not necessarily mean the change is immediately mergeable. Repository policy may still require additional reviews, successful CI, or other gates; conversely, a team may permit merging after required blocking concerns are resolved even if optional suggestions remain open. Agreeing on these distinctions makes reviews more predictable and reduces avoidable delays.

Key points

• Define blocking criteria around meaningful correctness, security, compatibility, and requirement risks.
• Make each blocking comment clear, specific, and actionable.
• Label optional suggestions so they are not mistaken for merge gates.
• Use automation for objective checks and human review for contextual judgment.
• Treat approval and merge readiness as related but distinct decisions.

Interview questions

What are approval and blocking criteria in a code review?

Blocking criteria are the conditions a change must satisfy before it is safe or acceptable to proceed. They usually include issues with correctness, security, data integrity, required behavior, or required CI checks. A blocker should explain the risk and what needs to change, rather than merely state a preference. This keeps review decisions actionable and consistent.

How do you decide whether a review comment should block a change?

I first check whether the comment describes a concrete failure mode, risk, or requirement violation. If it does, I explain why it matters and what change or evidence would resolve it. If it is a preference or improvement that does not affect the safety or required behavior of this change, I mark it as non-blocking and may suggest a follow-up. When severity is unclear, I discuss it with the author rather than silently treating an opinion as a gate.

Which approval criteria should be automated, and which should remain part of human review?

I separate checks that can be encoded as deterministic gates from judgments that require context. CI can enforce tests, formatting, type checks, and other objective policies; reviewers evaluate behavior, design, and operational risk. I would keep the merge policy visible, identify which checks are mandatory, and avoid duplicating or contradicting automated rules in informal comments. Even a green pipeline is evidence, not a guarantee that the change meets its intent.

How would you establish review criteria for a team with inconsistent approval practices?

A healthy review policy makes the merge bar explicit without requiring every reviewer to apply personal preferences as gates. I would define a small set of non-negotiable requirements, clarify how severity is communicated, and allow optional improvements to be handled separately. I would also look for process problems such as inconsistent approvals, flaky required checks, or long-lived unresolved comments. The policy should be revisited when the team’s risk profile or delivery needs change.