Pull Request Process

​

Before Creating a PR

​

Checklist

• Issue has been assigned to you on GitHub
• You’ve read CONTRIBUTING.md
• Code is complete and tested on all platforms
• All tests pass (npm test)
• Code is formatted (npm run prettier)
• No lint errors (npm run lint)
• Type checking passes (npm run typecheck-tsgo)
• Commits are signed with GPG

​

Creating a Pull Request

​

1. Create Branch

# Update main
git checkout main
git pull origin main

# Create feature branch
git checkout -b fix/issue-description

# Example:
git checkout -b fix/report-loading-crash

​

2. Make Changes

​

3. Commit Changes

# Stage changes
git add .

# Commit with clear message
git commit -m "Fix: Prevent crash when loading empty report"

# Push to your fork
git push origin fix/report-loading-crash

​

4. Create PR on GitHub

1. Go to your fork on GitHub
2. Click “Compare & pull request”
3. Fill out every section of the PR template
4. Link the issue: Fixes https://github.com/Expensify/App/issues/12345

​

PR Template Sections

​

Details

### Details
Fixed a crash that occurred when opening a report with no transactions.
The issue was caused by attempting to access `transactions[0]` when the 
array was empty.

Added a check to verify the array has items before accessing the first element.

​

Fixed Issues

### Fixed Issues
$ https://github.com/Expensify/App/issues/12345
REQUIRED: Add tag for Time To Fix badge

​

Tests

### Tests

**Web**
1. Log in to the app
2. Navigate to any report
3. Delete all transactions
4. Close and reopen the report
5. Verify the app doesn't crash
6. Verify empty state is shown

**iOS**
1. Log in to the app
2. Navigate to any report
3. Delete all transactions
4. Close and reopen the report
5. Verify the app doesn't crash
6. Verify empty state is shown

**Android**
(Same as iOS)

**mWeb**
(Same as Web)

​

Screenshots

### Screenshots/Videos

**Web**
![web](https://github.com/user/screenshots/web.png)

**iOS**
![ios](https://github.com/user/screenshots/ios.png)

**Android**
![android](https://github.com/user/screenshots/android.png)

**mWeb**  
![mweb](https://github.com/user/screenshots/mweb.png)

​

Checklist

• I verified the correct issue is linked in the ### Fixed Issues section above
• I signed all commits (see GPG Signing)
• I tested this with iOS, Android, Web, and mWeb
• I ran npm run prettier
• I ran npm run lint with no warnings
• I ran npm run test and all tests pass
• I added screenshots for all platforms

​

During Review

​

Responding to Feedback

# When making requested changes:

1. Make the changes
2. Run prettier, lint, tests
3. Commit and push
4. Comment "Updated" on the PR

​

Daily Updates

# Good update examples:
"Working on the requested type changes, will have ready by EOD"
"Investigating the iOS crash, need more time to debug"
"Changes complete and ready for review"
"Will be unavailable Fri-Mon, resuming Tuesday"

​

Never Force Push

# ❌ Bad: Force push
git push --force

# ✅ Good: Regular push
git push

​

Review Process

​

Who Reviews

1. Contributor+ (C+): Code quality, style, testing
2. Expensify Engineer: Architecture, business logic

​

Review Timeline

• First review: Usually within 2-4 days
• Follow-up reviews: 1-2 days
• Final approval: After all feedback addressed

​

What Reviewers Check

1. Functionality: Does it fix the issue?
2. Code Quality: Follows coding standards?
3. Testing: Tested on all platforms?
4. Performance: No performance regressions?
5. Documentation: Updated if needed?

​

After Merge

​

Deployment Process

​

Timeline

1. Merged: PR merged to main
2. Staging Deploy: 1-2 days
3. Production Deploy: 1-2 weeks
4. Regression Period: 7 days after production
5. Payment: 7+ days after production (if no regressions)

​

Post-Deployment Checklist

1. Propose regression test steps: How to verify the bug doesn’t return
2. Identify offending PR: If this fixed a bug, find what PR caused it
3. Comment on offending PR: Explain what broke
4. Discuss prevention: How to prevent similar bugs

​

Regressions

​

What Are Regressions?

​

Impact on Payment

• 50% penalty for each regression
• Payment delayed until all regressions are fixed
• Applies to both Contributor and Contributor+

​

Avoiding Regressions

1. Test thoroughly on all platforms
2. Write comprehensive tests
3. Consider edge cases
4. Review your own PR before submitting
5. Test with different data scenarios

​

Common PR Mistakes

​

1. Incomplete PR Template

# ❌ Bad
### Tests
Tested on web

# ✅ Good
### Tests

**Web**
1. Log in to app
2. Navigate to settings
3. Click profile
4. Verify name displays correctly

**iOS**
(Same as web)

**Android**
(Same as web)

**mWeb**
(Same as web)

​

2. Missing Screenshots

​

3. Not Running Prettier

# Always run before committing
npm run prettier

​

4. Unsigned Commits

​

5. Force Pushing During Review

​

PR Size Guidelines

​

Keep PRs Focused

• Ideal: 200-400 lines changed
• Maximum: 1000 lines (requires justification)
• One purpose: Fix one issue or add one feature

​

Large PRs

1. Discuss with team first
2. Break into logical commits
3. Provide extra context in description
4. Be patient with review time

​

Draft PRs

1. Create PR as draft
2. Request early feedback
3. Mark "Ready for review" when complete
4. Complete full checklist

​

Best Practices

​

1. Self-Review First

• Check for commented code
• Verify all test steps work
• Ensure screenshots are clear
• Look for obvious improvements

​

2. Provide Context

• Why the change is needed
• What alternative approaches you considered
• Any gotchas or tricky parts
• Impact on other features

​

3. Be Responsive

• Address comments within 1-2 days
• Ask questions if unclear
• Provide updates if delayed

​

4. Learn from Feedback

• Note common suggestions
• Apply learnings to future PRs
• Ask why if you don’t understand

​

Communication

​

Where to Ask Questions

• About the PR: Comment on the PR
• About the issue: Comment on the GitHub issue
• General questions: #expensify-open-source Slack

​

Getting Help

1. Comment on the PR or issue
2. Wait 1-2 business days
3. If no response, ping in Slack
4. Provide context and what you’ve tried

​

Payment

​

Payment Timeline

• Minimum: 7 days after production deploy
• With regressions: After regressions fixed + 7 days
• Maximum: Usually within 14 days of production deploy

​

Payment Issues

1. Verify no regressions exist
2. Complete post-deployment checklist
3. Comment on issue mentioning BugZero team member
4. Be patient - payment is processing

​

Next Steps