The anatomy of a pull request that gets merged

I've had pull requests merged quickly and I've had pull requests die quietly for months. Comparing them taught me the anatomy of the ones that merge. None of it is talent. All of it is respect for the maintainer's time.

The anatomy

One thing per PR. The PR that fixes one bug merges. The PR that fixes one bug, refactors two files, and updates a dependency reviews at triple length and dies in "I'll get to it." Small scope is kindness with a measurable return.

A description that answers three questions: what's the problem, what's the fix, how did you verify it. Copy the maintainer into your thinking, not just your diff.

Tests on the behaviour. Not coverage theater — a test that fails before your fix and passes after. It proves the bug existed, the fix works, and it won't return. That's a complete story.

Their style, not yours. Read the codebase's conventions first. A perfect patch in a foreign style creates work; a decent patch in their style removes it.

Issue linkage. "Fixes #123" closes the loop automatically — review starts with full context instead of archaeology.

The uncomfortable truth

Most unmerged PRs fail on communication, not code. The diff is the half of the conversation you have with the computer. The description is the half you have with a tired human.