Overview
Pull requests (PRs) are the primary way to contribute code to the Money monorepo. This guide will help you create high-quality PRs that are easy to review and likely to be merged.Before Creating a PR
Test your changes
- Test functionality manually in the browser
- Verify edge cases and error handling
- Check for console errors or warnings
- Test on different screen sizes (if UI changes)
Review your own code
- Read through your changes as if reviewing someone else’s code
- Remove debug code, console.logs, and commented code
- Ensure code follows the Code Style
- Check that all changes are intentional
Creating the Pull Request
1. Push Your Branch
2. Open PR on GitHub
- Go to the repository on GitHub
- Click “Pull requests” → “New pull request”
- Select your fork and branch
- Click “Create pull request”
3. Write a Descriptive Title
Follow the commit message convention:4. Fill Out the Description
Provide a comprehensive description:PR Description Template
Use this template for your PR description:PR Best Practices
Keep PRs Focused
✅ Good PR:- Addresses one feature or bug
- Changes 50-300 lines of code
- Easy to review in 10-15 minutes
- Single, clear purpose
- Multiple unrelated changes
- Changes 1000+ lines of code
- Mixes features, refactoring, and bug fixes
- Hard to understand scope
Make Atomic Commits
Add Screenshots for UI Changes
Always include screenshots for:- New UI components
- Layout changes
- Style updates
- Visual bug fixes
Link Related Issues
Connect your PR to issues:Request Reviews
Explicitly request reviews from:- Code owners (automatic)
- Relevant team members
- Subject matter experts
Responding to Feedback
Be Responsive
- Respond to comments promptly
- Ask clarifying questions if needed
- Be open to suggestions and changes
- Engage in constructive discussion
Making Changes
Resolving Conversations
- ✅ Mark conversations as resolved after addressing
- ✅ Leave a comment explaining your changes
- ✅ If you disagree, explain your reasoning respectfully
- ❌ Don’t resolve conversations without addressing them
Example Response
After Your PR is Approved
Squash commits (if needed)
If you have many small commits, consider squashing:Or use GitHub’s “Squash and merge” option.
Wait for merge
A maintainer will merge your PR. Don’t merge your own PRs unless you’re a maintainer.
Common PR Issues
Merge Conflicts
If your PR has conflicts:Failing CI Checks
If automated checks fail:- Read the error messages carefully
- Fix the issues locally
- Run checks locally before pushing:
- Push fixes and wait for checks to re-run
Stale PRs
If your PR becomes stale:- Rebase on latest main
- Address any outstanding feedback
- Ping reviewers if needed
- Consider if the PR is still relevant
PR Review Process
What Reviewers Look For
- Correctness: Does the code work as intended?
- Code quality: Is it well-written and maintainable?
- Style: Does it follow project conventions?
- Tests: Are changes properly tested?
- Documentation: Is documentation updated?
- Performance: Are there performance implications?
- Security: Are there security concerns?
Review Timeframe
- Small PRs: 1-2 days
- Medium PRs: 2-3 days
- Large PRs: 3-5 days
Getting Faster Reviews
To get your PR reviewed quickly:- ✅ Keep PRs small and focused
- ✅ Write clear descriptions
- ✅ Respond to feedback promptly
- ✅ Ensure all checks pass
- ✅ Add screenshots for UI changes
- ✅ Make reviewer’s job easy
Draft PRs
Use draft PRs for:- Work in progress
- Getting early feedback
- Demonstrating an approach
- Long-running features
PR Size Guidelines
| Size | Lines Changed | Review Time | Recommendation |
|---|---|---|---|
| XS | < 10 | < 5 min | Perfect |
| S | 10-50 | 5-15 min | Great |
| M | 50-200 | 15-30 min | Good |
| L | 200-500 | 30-60 min | Consider splitting |
| XL | > 500 | > 1 hour | Definitely split |
Example Good PRs
Example 1: Bug Fix
Example 2: New Feature
Next Steps
Contributing Guidelines
General contribution guidelines
Code Style
Follow the code style guide
Development Setup
Set up your environment
Testing
Test your changes