The "Labeling" Technique
One of the biggest sources of anxiety for PR authors is not knowing whether a comment is a "must fix before merge" or a "nice to have if you feel like it." When every comment looks equally urgent, authors either block themselves trying to address everything, or they guess wrong and merge something they shouldn't have.
The solution is Conventional Comments — a lightweight convention where every comment is prefixed with a label that communicates its severity and intent. This removes ambiguity entirely.
BLOCKER
A serious issue that must be resolved before the PR can merge. This includes bugs, security vulnerabilities, spec violations, or anything that would cause incorrect behavior in production.
[BLOCKER] This SQL query concatenates user input directly into the query string.
This is a SQL injection vulnerability. We need to use parameterized queries here.
# Bad:
query = f"SELECT * FROM users WHERE name = '{user_input}'"
# Good:
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (user_input,))
SUGGESTION
A meaningful improvement that the reviewer recommends, but which is not strictly required for correctness. The author should engage with it — either implement it or explain why they chose differently.
[SUGGESTION] This function is doing three things: parsing, validating, and persisting.
Splitting it into three smaller functions would make each easier to test independently.
NITPICK (NIT)
A minor stylistic or cosmetic preference. The author can fix it or ignore it — it should never block a merge. Reviewers should use this label sparingly; if you have more than two or three nits on a PR, ask yourself whether a linter should be catching these instead.
[NIT] Typo in the comment: "calcluate" → "calculate".
QUESTION
A request for clarification. Not a request for change — yet. The answer might reveal that no change is needed, or it might surface a blocker.
[QUESTION] Is this 5-second timeout intentional, or is it a leftover default?
I want to make sure it aligns with the SLA we agreed on with the client.
PRAISE
Explicitly positive feedback. Do not skip this. If you see a clever solution, an elegant abstraction, or a well-written test, say so. Praise reinforces good patterns and makes the review feel like a two-way conversation rather than an inspection.
[PRAISE] This retry logic with exponential backoff is clean and handles the
edge cases really well. I'm going to borrow this pattern for the other service.
If asked "How do you handle disagreements during code review?", a strong answer references the labeling system: "I try to make the severity of my feedback explicit. If it's a blocker, I explain why it's a blocker. If it's a preference, I label it as a nit so the author knows they have discretion. If we still disagree after discussion, we escalate to the team or tech lead rather than letting the PR stall indefinitely."