Across several hundred pull requests, the ones I reject or send back for changes tend to share recurring patterns. The most common is mixing unrelated refactoring with feature work in the same diff, which makes it genuinely difficult to tell which changes are functionally meaningful and which are just code being moved. When a reviewer is looking for a bug, they have to read every line of the diff; when the diff mixes refactoring with feature work, the reviewer has to read every line twice — once to figure out whether it's functional and once to figure out whether the functional change is correct. Separating refactoring into its own commits lets the reviewer focus on each category with the right level of attention.

Close behind that is missing test coverage for the critical path — the core behavior the change is meant to introduce. A PR that adds a feature without tests is asking the reviewer to verify the feature works by reading the code, which is much less reliable than running tests and impossible to repeat after future changes. Tests aren't just about catching bugs at merge; they're about preventing regressions over the life of the code. A feature without tests will eventually break, and when it does, the fix will be harder because there are no tests to define what "correct" looks like.

On the other side, the PRs I approve quickly share their own recurring traits: a clear written description, before-and-after screenshots when the change touches UI, tests covering the critical path specifically, and separate, clearly labeled commits distinguishing refactoring from feature work. Distilled down, a genuinely good PR description answers three questions: what does this change do, why did it need to change, and how did the author verify it works. Almost everything else in a description is, in practice, just noise around those three answers.