5 exercises — real PR comments carry very different social signals depending on word choice and framing. Misreading the tone of a review comment can cause unnecessary conflict or missed feedback.
Critical — "fundamentally wrong", "this won't work" → must fix before merge
Constructive/Neutral — "nit:", "consider:", "could you clarify?" → suggestion or question, often non-blocking
Humorous/Ironic — sarcasm, jokes, memes → pointing out absurdity, usually non-blocking
0 / 5 completed
1 / 5
Read this GitHub PR comment. What tone is the reviewer using?
"This is exactly what I was hoping to see! Great refactor — clean separation of concerns, easy to follow, and the tests are solid. LGTM 🚀"
This is a supportive and enthusiastic comment. Key signals: "exactly what I was hoping to see" (strong approval), explicit praise of specific qualities (clean, easy to follow, solid tests), "LGTM" (Looks Good To Me — the standard approval phrase), and the rocket emoji 🚀 (widely used in tech to express excitement). Learning to read this tone matters: enthusiastic LGTM = merge it now. A dry "LGTM" with no context often signals lukewarm approval — the reviewer is signing off but not excited. On GitHub, tone is a social signal — how you write review comments affects your reputation as a teammate.
2 / 5
Read this GitHub PR comment. What tone is the reviewer using?
"This approach is fundamentally wrong. REST polling every 500ms will hammer the database under load. Did you actually read the architecture docs before starting this?"
This is critical and direct — and edging into harsh. Key signals: "fundamentally wrong" (strong absolute negative judgement), a concrete technical argument (polling every 500ms = DB hammer), and "Did you actually read..." — the word "actually" here is confrontational, questioning competence. In open-source culture this would be considered a CoC (Code of Conduct) violation. In many professional teams it would also be unacceptable. The technical content may be completely valid — REST polling every 500ms really could cause problems — but the delivery is a problem. Compare to: "Heads up: polling every 500ms could cause DB bottlenecks under load — is there a requirement here that prevents us from using webhooks instead?" — same concern, professional tone.
3 / 5
Read this GitHub PR comment. What tone is the reviewer using?
"nit: consider renaming handleData() to processIncomingEvents() — more descriptive and consistent with the naming convention in the rest of the module."
This is neutral and constructive. Key signals: "nit:" is the most important word here — it is short for "nitpick" and is a code review convention that explicitly signals "this is a minor suggestion, not a blocker." The reviewer is not demanding a change — they are offering an improvement. The justification is calm and professional: "more descriptive", "consistent with convention". Other constructive comment openers in code review: "suggestion:", "optional:", "consider:", "minor:", "non-blocking:". These signal that the PR is approvable as-is. Learning to distinguish blocking vs non-blocking review comments is essential for working efficiently on a team.
4 / 5
Read this GitHub PR comment. What tone is the reviewer using?
"So we're shipping a 'performance improvement' that adds 14 new npm dependencies and a Redis instance for a contact form that gets 3 submissions a week. Bold strategy. 😂"
Humorous and ironic — specifically sarcastic. Key signals: the scare quotes around "performance improvement" (indicating scepticism about the label), the absurd contrast presented (14 dependencies + Redis for 3 form submissions/week), "Bold strategy" (a well-known internet sarcasm phrase — "bold strategy, Cotton"), and the 😂 emoji confirming the tone is playful, not aggressive. This type of comment uses humour to highlight over-engineering — building a complex solution for a trivial problem. It is common in open-source and startup teams. Important nuance: sarcasm can land poorly in text without the emoji and context — what is funny between close colleagues may seem passive-aggressive to a new team member. Read the room.
5 / 5
Read this GitHub PR comment. What tone is the reviewer using?
"Could you walk me through the reasoning for the async approach here? I want to understand the trade-offs before I approve — specifically around error propagation."
This is neutral and constructive — specifically a clarification request. Key signals: "Could you walk me through..." (polite, collaborative phrasing), "I want to understand the trade-offs" (intellectual curiosity, not accusation), "before I approve" (the reviewer is close to approving — they just need context). This is one of the most important review comment types to master: the blocking question that is not a criticism. The reviewer is not saying the async approach is wrong — they are asking the author to justify the choice. The correct response is a calm explanation, not a defence. You will see this pattern constantly in senior engineer reviews: they ask clarifying questions rather than making declarations. It builds shared understanding and knowledge transfer.