Pull Request Guidelines¶
PRs are the primary mechanism for knowledge sharing, risk reduction, and maintaining consistency.
Size¶
Keep PRs small and focused. A PR should do one thing.
Large PRs are harder to review, harder to revert, and harder to understand.
Writing a Good PR¶
- Describe why the change is being made, not just what changed
- Link to the relevant ticket or issue
- Note anything the reviewer should pay particular attention to
- Include screenshots or examples for UI or data changes
Reviewing a PR¶
Review intent before implementation — understand what the PR is trying to achieve before diving into the code.
Focus on: - Correctness — does it do what it claims? - Readability — will someone understand this in six months? - Security — are there any obvious vulnerabilities? - Testability — is the change tested appropriately? - Consistency — does it follow existing patterns?
Checklist for Reviewers¶
- [ ] Validate code style is consistent
- [ ] Tests exist and are meaningful
- [ ] Data quality is considered (for data changes)
- [ ] No hardcoded secrets or credentials
- [ ] Documentation updated where needed