Contribute-to-hire: writing a PR that gets merged

Status: Outline — full guide coming soon. Get notified when it ships →

What this covers

• The "small surface area" rule and why a 30-line PR ships and a 300-line PR rots
• The PR description structure: what / why / how / screenshots / test plan
• How to write tests that match the existing test style (and why this is half the merge decision)
• Handling maintainer review feedback without ego or pushback spirals

Why this matters for Indian devs going remote

A merged PR in a real OSS repo is the highest-signal artifact you can put on a resume — it's verified, public, and the diff is the proof. But "PR opened" and "PR merged" are completely different signals. The discipline of writing for merge (not for showing off) is what turns the contribute-to-hire path into actual offers.

Outline

The small surface area rule

TODO — diff size budget by repo, why incidental refactors get rejected, the "fix one thing" rule.

The PR description structure

TODO — what, why, how, screenshots/repro, test plan. Why "fixes #123" alone isn't enough.

Test discipline

TODO — match existing patterns, mirror naming, run the full suite locally, don't introduce a new testing approach.

Handling review feedback

TODO — separating taste from blocker, the "you're right, fixed" reply, when to push back.

Common mistakes to avoid

• Bundling 4 unrelated fixes in one PR — maintainers will ask you to split, then forget
• Ignoring the repo's CONTRIBUTING.md style (commit format, branch name, signoff)
• Arguing with review comments instead of fixing them

Templates / examples

TODO — a PR description template (markdown), a self-review checklist before opening, and 3 examples of small merged PRs.

Related guides

• Contribute-to-hire: picking a winnable issue (verify rules + -linked:pr)
• Working with OSS maintainers without getting ghosted

---

Have a question about this? DM me on LinkedIn or drop your email to get the full guide as soon as it's published.