19 / 57 · 17 Git & Version Control · Pull Request Workflows← prev⊞ allnext →☰ Read as one page
3.2Writing Good PR Descriptions
A PR description should answer three questions: what changed, why it changed, and how to verify it.
The Template
## What
Added retry logic to flaky payment API tests and split the checkout
suite into two shards for parallel execution.
## Why
Payment tests were failing 15% of the time due to third-party API
timeouts. The checkout suite was the bottleneck in our pipeline (12 min).
## How to verify
- Run `npm run test:payment` -- should see retry on timeout, 0% flake rate
- Check pipeline -- checkout stage should complete in ~6 min (down from 12)
## Test evidence
- 10 consecutive green runs on this branch: [link to CI]
- Flake rate before: 15% | after: <1%
## Related
- Fixes #234 (flaky payment tests)
- Part of Epic: Pipeline Speed (#100)
What Makes This Template Effective
- "What" tells the reviewer what to focus on. Without it, they must reverse-engineer your intent from the diff.
- "Why" explains the motivation. "Reduce flake rate from 15% to <1%" is much more compelling than "fix tests."
- "How to verify" gives the reviewer concrete steps. They do not have to guess how to validate the change.
- "Test evidence" shows that you have already validated the change. This builds trust and speeds up approval.
- "Related" links to issues, epics, and discussions for context.