Modern QA2026Writing Good PR Descriptions — tiles
Log inJoin
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.