SecurityEngineering/CodeReviewGuidelines

For everybody

• Assume that everyone involved has good intentions.
• Problems can happen if expectations (about priority, timing, approach) are not in line. Communicate up front to avoid these problems. Be explicit as possible.

For reviewers

• Acknowledge that the patch author is trying to contribute something good, even if the patch is not perfect.
• Explicitly divide review comments into "must do" and "nice to do" so that it's clear what the reviewee needs to do to get the patch approved.
• Don't ignore review requests. If you don't have time to do a review, help the reviewee find an alternate reviewer.
• Use r- instead of clearing the review flag so that it's clear the patch has been reviewed to anyone viewing the bug.
• Respond in a reasonable amount of time with either a review or information on when you can do the review. You should not go longer than a week without any communication with the reviewee.

For reviewees

• If you need a review in a specific timeframe, please ping the reviewer and let them know of the urgency/timeline.
• For priority work, just saying r? is not enough, especially if the reviewer has a long request list.
• Don't take negative feedback personally. This includes getting an r-.
• Address all review comments. If you disagree with something, say why, don't ignore it.