Build fluency in the everyday language of respectful, effective code review.
0 / 5 completed
1 / 5
During a code review, a reviewer flags a stylistic preference but doesn't want to block the PR. What label should they use?
A nit (nitpick) marks a minor, optional suggestion that shouldn't block merging, distinguishing it from a required change. Prefixing comments with "nit:" signals to the author they can safely ignore or address it at their discretion. This convention keeps reviews from feeling overly strict on trivial points.
2 / 5
At standup, a dev mentions their PR is still in progress but wants early feedback on direction. What should they mark it as?
Marking a PR as draft or WIP (work in progress) signals it isn't ready for a final approval pass but welcomes early directional feedback. Reviewers then know to comment on approach rather than nitpick polish. This avoids wasted detailed review before the design settles.
3 / 5
In a design review, a reviewer asks a clarifying question rather than demanding a change. What is this comment style called?
A non-blocking question invites the author to explain reasoning without implying the PR can't merge as-is. This is common etiquette for reviewers who are curious or uncertain rather than opposed. It keeps review conversations collaborative rather than adversarial.
4 / 5
An incident report shows a PR merged with an unresolved concern because the reviewer approved too quickly. What practice would have prevented this?
A rubber stamp approval happens when a reviewer approves without genuinely evaluating the change, letting real concerns slip through. Using "request changes" for unresolved issues, rather than approving with caveats in a comment, keeps the merge gate meaningful. This distinction matters for review quality.
5 / 5
During a PR review, the author pushes new commits addressing feedback and wants the reviewer to look again. What should they do?
Re-requesting review notifies the original reviewer that new commits are ready for another pass, keeping the approval status accurate. Silently pushing more changes after approval can leave stale sign-off on outdated code. This is standard etiquette for iterative review cycles.