The social layer — how not to lose your PR.
Every guide teaches you to fork, branch, commit, and open a pull request. Almost none teach the part that decides whether your PR actually lands: open source is a social system with unwritten rules, and the contributors who lose — sniped mid-PR, ignored, quietly resented — lose on the social layer, not the technical one.
The race you didn’t know you were in
Here’s a true story. A developer picks a fresh issue from his feed, starts working, gets most of the way there, steps away for a day — and comes back to find someone else’s PR already submitted underneath him. It happens again on the next issue.
Nobody told him he was in a race, so nobody told him races have rules: he never commented on the issue, never asked to be assigned, and never pushed anything visible. To everyone else watching that issue, it was unclaimed.
Fresh, well-scoped issues on established repos are contested by default — the same freshness that makes an issue winnable means other people are seeing it too, often within hours. You don’t get to opt out of the race. You only get to decide whether anyone knows you’re running.
Never opened a PR at all? Do the mechanics first at first-contributions — ten minutes, zero stakes, a real merged PR at the end. Then come back: this page is everything that tutorial deliberately skips.
Stake your claim — a decision tree, not a reflex
Before you write a line of code, spend five minutes on the issue page. What you find there decides which of three moves is correct — and one of them is “say nothing and just start.”
Read CONTRIBUTING.md, the PR template, and the issue's own state — assignee, open PRs, the thread.
- The repo states a process
Follow it exactly, in their format — a bot command, or the comment they ask for.
stake:/take - No process, but contested
One substantive comment: your approach in a sentence, plus when you expect a PR.
stake: approach + ETA - No process, low contention
Don't perform a ritual nobody asked for. Just start — then make the work visible.
stake: draft PR, early
A draft PR is the strongest stake there is — GitHub-native, zero spam, and backed by visible work instead of a promise.
If you do comment, comment like this
The ask-first advice everyone repeats only works when there’s something behind the ask. If you comment, you’re committing.
Planning to fix this by moving the cache check above the auth guard — should have a PR up tomorrow. Flag me if that’s the wrong direction.
can I work on this?
built inclaim preview audits the repo’s contribution docs before you commit to anything, and claim record records the claim and flags any assignment expectation the audit found — but it’s claim start that speaks on the issue, and it runs the tree above for you: it follows a stated process, posts one substantive stake when there’s no process but the issue is contested, and stays quiet when nobody else is circling. It shows you the exact comment first, so don’t stop at record and assume anyone can see you. Then right before you push, submit re-checks for competing open PRs — because a race check done at claim time goes stale over hours of work.
Pace beats intensity
Contested issues reward the contributor who ships the smallest honest version fastest. Scope down: the PR that fixes the reported bug beats the PR that fixes the bug, refactors the module, and renames three files — both in the race and in review.
Then hold a visible cadence. A claim you’ve gone quiet on doesn’t read as “in progress” — it reads as abandoned, and the rest of the world acts accordingly.
- ▹Every 2–3 days — while you hold a claim: push a commit, or leave a one-line progress note on the issue or draft PR.
- ▹Can’t continue? Say so — “stepping back from this one, it’s free” costs you nothing and buys real goodwill — the maintainer can reopen it for someone else instead of watching it rot.
- ▹Don’t hoard — one or two active claims at a time. Every claim you hold and don’t move blocks a person who would have.
built in
There’s a mirror rule on the other side of the table: don’t pile new work onto a maintainer who already owes you a response. Terminalhire’s merge agent enforces this on itself — it refuses to open another PR in a repo while one of its own still awaits a reply, because opening a fourth PR while owing a response is exactly the behavior that gets a contributor pattern-matched as a spammer.
The invisible ledger
Maintainers keep an account of you. Not a literal one — a running sense, built from every interaction, of whether your name on a PR means “this will be worth my time.” Review attention is the scarcest resource in open source.
- ▹Deposits — a small, focused diff. Conventions followed without being told. Tests that pass. A PR body whose first two lines answer what and why. A graceful response to “no.”
- ▹Withdrawals — a 40-file surprise PR. “Fixed it” with no explanation. Arguing with review feedback before understanding it.
- ▹The most expensive withdrawal — a plausible-looking PR that falls apart under review — it spends the maintainer’s time and returns nothing.
built in
The contribute feed sets a hard bar before showing you an issue — established repos, unassigned, merit-merged — and the claim flow race-checks for existing PRs the moment you claim, then makes you acknowledge any competitors it finds before proceeding. You should never unknowingly walk into an issue where showing up starts you in the red.
When you lose the race
Sooner or later someone else’s PR lands first. This is the moment nobody writes about, and it’s the cheapest reputation win available in open source — because almost everyone handles it badly, by ghosting or by sulking in the thread.
- ✓Read the winning PR before you react — sometimes it’s better than yours. Sometimes it isn’t — and yours covers cases theirs misses.
- ✓If theirs is solid, close yours generously — “#131 got there first and the approach is clean — closing mine. Nice handling of the timeout case.” Ten seconds, remembered far longer than the PR would have been.
- ✓If yours covers real ground theirs doesn’t — don’t relitigate — offer the delta. Review their PR and note the gap, or land the missing edge cases as a follow-up. “Compatible” beats “competing” in every triage decision.
- ✓Salvage the work — the losing branch is research: you know the codebase now, and you’re the best-qualified reviewer of the winning PR. The person who beat you today reviews your PR next month.
built inclaim status and the submit confirmation both list the open PRs racing your issue, flagging the ones that appeared since you last checked — so you learn about a competitor while there’s still time to scope around them, not after you’ve pushed.
When the maintainer goes quiet
Silence is the default state of open source, and misreading it burns more newcomers than rejection does.
- Week oneDo nothing.
Volunteer maintainers batch their OSS time — weekends, evenings, sometimes monthly. No response in five days is not a signal.
- After a week or twoOne bump, with value attached.
Rebase onto the latest main, confirm CI is green, then a single line: “Rebased and green — anything you’d like changed?” A bump that does work is a nudge; “any update?” is a cost.
- After another few weeksMove on, gracefully.
Leave the PR open, take your next issue elsewhere, and let it be. Some PRs merge six months later out of nowhere. What never works: bumping daily, opening a duplicate issue for attention, or tagging maintainers in other threads.
Silence on a policy question is not the same as silence on a PR. If you asked “is AI-assisted work acceptable here?” or “would you take a breaking change to this API?” and got no answer, the answer is no until someone says yes. Working ahead as if silence were permission spends trust you never had.
Terminalhire’s merge agent is built on exactly this standard: its policy gate cannot open on a repo unless it can point at the actual text that grants permission. “Couldn’t find a policy” blocks — it never authorizes.
Working with AI in the open
Maintainers are drowning in AI-generated submissions, and the backlash is structural — curl shut down its long-running bug bounty program in January 2026 because AI slop made it uneconomic to run. The lesson is not to hide your tooling. It’s the opposite.
- ▹Check the repo’s AI policy before you claim — if AI-assisted contributions are prohibited, that repo is off-limits for AI-assisted work. Routing around a policy — laundering authorship, “writing it as if you wrote it” — is the one move here that torches your reputation permanently rather than costing you a PR.
- ▹If it’s allowed or unaddressed: disclose, plainly — one matter-of-fact line in the PR body, in the repo’s own format if they have one. Disclosure reads as good faith precisely because the slop-senders never bother.
- ▹Vouch for every line — what makes a PR slop isn’t that a model wrote it — it’s that a human submitted it unverified. If you can’t explain a diff or didn’t run the tests, it isn’t ready to carry your name.
built in
On a repo whose policy prohibits AI contributions, claim hard-stops the AI-assisted path — it proceeds only after you explicitly acknowledge the policy and commit to handwritten work, and it will never help you route around the ban. And submit appends an AI-assistance disclosure to every PR it opens — there is no opt-out.
Where to start
If you’ve never contributed, make your first PR in the sandbox today. If you’re ready for real issues, terminalhire contribute shows you fresh ones matched to your stack where a merge genuinely counts — and the claim lifecycle automates most of what this page just taught you.
The social layer stops being intimidating the moment you know the rules. Now you do.
curl -fsSL terminalhire.com/install.sh | bashProof of Work
One email a week: merged-PR receipts, winnable OSS issues, and what actually counts as proof.