A reviewer evaluates proposed code changes for potential defects, clarity, context, and alignment with applicable criteria. The role combines technical judgment with empathetic, productive engagement with the author. section 2.4.1
A reviewer’s working contract includes:
- Look for potential defects and make sure the changed code can be understood. section 2.4.1
- Conduct a diligent review, leave feedback when appropriate, and engage the original author empathetically and productively. section 2.4.1
- Use relevant subject-matter expertise or historical context to clarify misunderstandings and missing scenarios. section 2.4.1
- Recognize that approval controls progress and that the reviewer is responsible for what passes through the review. section 2.4.1
- Leave ego, job titles, internal disputes, and personality traits out of the judgment; focus on the code presented in the pull request. section 2.4.1
Questions for a focused review
Ask whether the pull request addresses one logical piece of behavior, explains why the change was made, matches its stated context, fulfills available acceptance criteria, flows logically, and contains parts that require repeated rereading. section 2.4.1
Figure 2.7 An example of a vague comment left on a code review
Compare a vague review comment with the clearer, constructive alternative to see how reviewer influence affects author feedback. section 2.4.1
Figure 2.8 An example of clear and constructive feedback
Use the constructive-feedback example to connect technical judgment with productive author engagement. section 2.4.1
