The checklist I use before sending a small OSS PR

Small open-source PRs look easy from the outside because the diff is usually small.

The diff is not the work.

The work is getting to the point where a maintainer can review it without having to guess what you changed, why it is safe, or whether you accidentally dragged in unrelated cleanup.

The checklist I keep coming back to is boring:

1. Reproduce the issue before changing code.
2. Find the smallest behavior boundary that explains the bug.
3. Add or adjust the focused test first if the repo makes that practical.
4. Keep the patch narrow, even if nearby code is tempting to clean up.
5. Run the local checks that match the touched area.
6. Re-read the diff like the maintainer has never seen your reasoning.
7. If the PR body needs a paragraph to explain why half the files changed, the patch is probably too wide.

That checklist has mattered across very different fixes: React Router SSR scripts, ast-grep pattern validation, ESLint rule edge cases, JSON schema defaults, Playwright optional chaining, and reporter output in knip.

The pattern is the same even when the libraries are different. A good small PR proves one thing.

It does not try to be a resume. It does not fix the whole subsystem. It does not turn a maintainer issue into a platform for everything you noticed while reading the code.

That restraint is practical. Maintainers are already carrying the whole project in their head. The cleanest contribution is usually the one that removes one sharp edge and gives them enough evidence to trust it.

Disclosure: I used AI assistance to organize this private article draft. The examples should be rechecked against the OSS contribution ledger before publishing.