Open Source

Code Review in Open Source

Linus Torvalds was known for harsh public reviews on LKML. In 2018 he took a break and reconsidered his communication style. If the creator of Linux understood that tone matters - it really does.

  • Google Code Review Guidelines - a public document that influenced all of OSS
  • Rust Core Team is known for exceptionally polite and constructive reviews
  • Linus Torvalds in 2018: "I need to change some of my behaviour" - CoC adoption in Linux
  • Vue.js contributor guide explicitly describes how to frame review comments

How to Give a Good Code Review

Code review in OSS is a public conversation. Your comments are read not just by the PR author, but by hundreds of developers in the future. Tone matters as much as content.

**Prefix-based review** is a convention popularized by Google and many OSS projects. Prefixes `nit:`, `blocker:`, `suggestion:`, `question:` instantly show the PR author how important the comment is and whether a response is expected.

You spot a potential SQL injection vulnerability in a PR. How should you frame the comment?

How to Receive Feedback

Receiving public criticism is a skill. Especially when you spent hours on an implementation and the reviewer wrote three lines about why it's wrong. The golden rule: **they're critiquing the code, not you**.

**After making changes - say what you did.** Don't go quiet. Write "Done" or "Fixed in a7b3c2d" after each resolved comment. This respects the reviewer's time and signals that re-review is possible. In GitHub you can click "Resolve conversation" - use it.

A reviewer left 15 comments on your PR, most of them nits. You've fixed everything. What next?

Key Ideas

  • Blocker/nit/suggestion/question - prefix system for classifying comments
  • Good review: specific problem + explanation why + example of correct approach
  • Receiving review: they critique the code, not you. Ask questions, don't get defensive
  • After making fixes: explicitly notify the reviewer, ask for re-review
  • Security issues are always blockers, always with a concrete fix example

Related Topics

Code review is part of the broader topic of communication in the OSS community.

  • Next Lesson — Logical continuation

Вопросы для размышления

  • Find a PR in a well-known OSS project (React, Vue, TypeScript) with active review. What communication patterns do you see?
  • How would you respond to the comment: "This whole approach is wrong, you should have done X from the beginning"?

Связанные уроки

  • se-04
Code Review in Open Source

0

1

Sign In