Code Review Process
Who Reviews
- Any Member with Write access: Can review and comment on pull requests
- Organization Owners: At least one of the 6 owners must approve before merge
- Self-review: Authors should read the PR before requesting review
Reviewer Responsibilities
What to check:
- Correctness: Does the code do what it claims?
- Quality: Is it readable, maintainable, and well-structured?
- Standards: Does it follow team conventions?
- Edge cases: Are errors and edge cases handled?
- Security: Are there any security concerns?
- Performance: Any obvious performance issues?
Review etiquette:
- Be kind and constructive
- Ask questions rather than make demands
- Explain the "why" behind suggestions
- Approve if changes are good enough (don't be a perfectionist)
- Respond within 1 business day if able
Requesting Changes
Use GitHub review features:
- Comment: Questions or suggestions
- Request Changes: Issues that must be addressed
- Approve: Ready to merge
Writing feedback:
- Be specific: "This function could be simplified" -> "Consider using Array.filter() here to reduce complexity"
- Acknowledge good work: "Nice error handling here"
- Distinguish requirements from suggestions: "Must: handle null case" vs "Nit: consider renaming this variable"
Addressing Review Feedback
Author responsibilities:
- Read all feedback carefully
- Ask questions if feedback is unclear
- Make requested changes or discuss alternatives
- Respond to all comments (even if just "Fixed" or "Done")
- Request re-review after significant changes
Handling disagreements:
- Discuss in PR comments or Slack/Teams
- Default to reviewer's suggestion unless there is strong reasoning otherwise
- Escalate to an Organization Owner if needed
- Remember: both parties want good code