Pull Requests That Get Reviewed Quickly

Slow reviews are usually a symptom of hard-to-review pull requests. You can make yours easy to say yes to.

1. Keep it small

Aim for changes a reviewer can understand in 15-20 minutes, often under a few hundred lines. Split big work into steps that each make sense on their own: refactor first, then the feature.

2. Write a description that answers the obvious questions

## What
Adds coupon codes to checkout (percentage and fixed-amount).

## Why
Marketing needs coupons for the Diwali campaign (#512).

## How
- New `coupons` table and `applyCoupon()` in the pricing service
- Validation: expiry date, minimum order value, one use per customer

## Testing
- Unit tests for pricing edge cases
- Manually tested in staging: screenshots below

## Notes for reviewers
The migration is backward compatible; the column is nullable.

3. Review it yourself first

• Read the diff on GitHub as if you were the reviewer.
• Remove debug logs, commented-out code and unrelated formatting changes.
• Leave comments on tricky spots to explain your reasoning before anyone asks.

4. Make it easy to verify

• Screenshots or a short video for UI changes.
• Green CI before requesting review.
• Clear steps to test locally, or a preview deployment link.

5. Handle feedback well

• Reply to every comment, even with "Done" or a short explanation.
• Push fixes as new commits during review so changes are easy to re-check; squash on merge if your team prefers.
• Move long debates to a quick call, then summarise the decision in the PR.

For reviewers: respond within a working day, label comments as blocking or "nit", and approve when it's good enough, not perfect.