A reviewer writes: "nit: variable name `x` could be more descriptive". What does "nit" mean?
"nit" (short for nitpick) signals that the comment is non-blocking and low-priority. Using "nit:" is a professional convention that saves time: the author knows immediately that this is optional feedback. Without "nit:", authors sometimes treat every comment as equally blocking, which slows down reviews and creates unnecessary friction.
2 / 5
Which code review comment is most professional and actionable?
Professional review comments: describe the specific issue (inline parsing in a 60-line function), suggest a concrete alternative (extract to parseUserInput()), explain the benefit (easier to test in isolation), and signal blocking status (non-blocking). "Wrong", "don't like", and "rewrite this" are emotion-based or too vague to act on. Good review comments give the author everything they need to make a decision without coming back to ask clarifying questions.
3 / 5
A reviewer writes "LGTM" on your PR. What does this mean?
LGTM = "Looks Good To Me" — the standard approval phrase in code review. It signals the reviewer has reviewed the changes and approves them without further changes. In GitHub/GitLab, LGTM in a comment may or may not correspond to a formal "Approve" review action — some teams require both.
4 / 5
You disagree with a reviewer's suggestion. Which response is most professional?
Disagreeing professionally: acknowledge the suggestion, explain your reasoning with a specific technical argument, invite further discussion, and explicitly defer if the reviewer is the maintainer. This approach keeps the conversation technical rather than personal, and gives the reviewer enough information to either accept your reasoning or explain why their suggestion is important. Ignoring comments is a red flag for maintainers.
5 / 5
When should a reviewer use "Request changes" vs "Comment" in a GitHub review?
"Request changes" is a formal blocking action — the PR cannot be merged (in most configurations) until the reviewer approves. Use it only for genuine blockers: bugs, security issues, breaking changes, or violations of documented project standards. Using "Request changes" for stylistic preferences or non-blocking suggestions is a power misuse that slows delivery and damages contributor relationships. Use "Comment" for everything that is non-blocking.