Review Guidelines

Best practices and conduct standards for code review in merge requests.

Review Conduct

Review the MR completely before submitting feedback
- Take time to understand the full context of changes
- Consider the overall design and approach, not just individual lines
- Look for patterns across the codebase
If you cannot finish within a day, submit partial reviews
- It's better to provide some feedback early than to delay indefinitely
- Mark your review as partial in the comment
- Specify what areas you've reviewed and what remains
- Example: "Partial review: Reviewed backend changes, frontend still pending"

All feedback should be constructive and focused on improving the code
- Frame suggestions positively: "Consider X because Y" instead of "This is wrong"
- Explain the reasoning behind your feedback
- Provide specific examples or alternatives when suggesting changes
- Acknowledge good practices and clever solutions
Focus on substantive issues
- Prioritize feedback on architecture, logic, security, and maintainability
- Don't nitpick minor style issues that could be caught by automated tools
- Consider the impact of your suggested changes
Be respectful and collaborative
- Remember that code review is a learning opportunity for both author and reviewer
- Assume good intent from the author
- Use questions to understand reasoning: "Can you explain why X was chosen over Y?"
- Recognize that there may be multiple valid approaches

Comment on parts that could be improved or need clarification
- Highlight areas where the code is unclear or could be better documented
- Ask questions if the implementation approach isn't clear
- Suggest where additional comments might help future maintainers
Provide actionable feedback
- Be specific about what needs to change
- Include code examples when helpful
- Link to relevant documentation or guidelines

Fast reviews (within 1-2 days) are very helpful to maintain productive workflow
- Quick feedback keeps the author's context fresh
- Reduces context-switching costs for the team
- Prevents blocking other dependent work
Balance speed with thoroughness
- Don't rush to the point of missing important issues
- Use partial reviews when you can't complete a full review quickly
- Communicate expected review timeline if you need more time

Focus your review based on the MR's review guide
- Authors should provide specific areas to focus on
- Respect the author's guidance on what to prioritize
- Flag if critical areas are missing from the review guide
Choose 3-7 most important guidelines per review (from code review guidelines)
- Document which guidelines you checked
- Don't check for what could be automatically verified by linters
- Focus on high-impact areas specific to this MR

When submitting a partial review:

When you disagree with the implementation: