This URL is five merged pull requests as a hiring signal: a small, reviewable set you can open on a call. Not fifty typos. Not a contribution-graph screenshot.
It is not how to write the PDF bullets. That is open source on your resume. It is not name, bio, and pins. That is how to build a developer portfolio through open source. If you do not have merge one yet, start at career switcher: your first open source PR or how to contribute to open source.
Five is a round number, not a law. Two deep PRs on one repo can beat five nits. The point is a set a stranger can click, not a count in a bio.
What the signal actually is
A hiring manager who bothers to open GitHub is looking for:
- A merged PR
- A review thread you answered
- A change you can narrate: issue, constraint, diff, what review asked
They are not looking for:
- Green squares
- “47 repositories”
- Forks you never pushed
- Open PRs that never landed
- Identical
fix typoacross random READMEs
Volume without review is noise. Five similar README nits still look like one skill. Five asked-for changes — tests, a named bug, a docs hole, a small feature the issue specified — look like a loop you can repeat.
Do not invent a study that “five PRs get you hired.” This page is a practical target, not a placement guarantee.
Build the set on purpose
Stay on one or two repos. Issue two on the same project is cheaper and reads as ownership. After your first contribution. Do not hop names for the count.
Raise the ceiling slightly. PR 1 can be the labeled starter. PR 2–3 should still be specified, but not the same typo shape. A test, a repro fixture, a small code path you already touched. Not core rewrites.
Keep each diff on the issue. Drive-by refactors pad the Files tab and stall review. You want merges, not heroic open PRs.
Drop work that will not merge. If the queue is dead, close and leave. An ignored PR is not item three.
A sequence, not a sprint
- Merge one. Stay for review. You now have a thread.
- Same repo, issue two. Slightly harder leaf. Same CI.
- Same repo or one more project in the same language. Do not collect ecosystems for the resume.
- One PR that is not cosmetic: a test or a behavior the issue named.
- Stop counting. Write the bullets and pins. Hunt only if you still cannot explain four of them.
Hunt on live hubs, not a gist of famous employers’ logos:
Picking: how to find good first issues, how to pick an issue that will get merged. Mechanics: first pull request guide.
Hacktoberfest is not a five-PR vending machine. Hacktoberfest 2026 is not a counting contest.
After you have the five
Then — only then — the other pages:
- Document: open source on your resume — one bullet per merge you can defend, one section
- Presence: portfolio through open source — pin the repos, README that names the change
Do not screenshot the five into the PDF. Link the PRs you will actually click in an interview.
Related
- Career switcher: your first open source PR — merge one, in the stack you already write
- How to build a developer portfolio through open source — pins and README, not this plan
- Open source on your resume — the document
- After your first open source contribution — stay for issue two
- How to find good first issues — live hubs
FAQ
Is five a magic number? No. It is a small set you can walk through. Two strong merges beat five nits. Do not farm the count.
Do they all need to be application code? No. A named docs hole, a test, a real triage PR all count if you can defend them. Unasked typos do not.
Should they be famous repos? No. Repos that merge. Famous and silent is a trap. Use Help Wanted hubs.
Can open PRs count? No. Merged, or clearly accepted. Same rule as the resume page.
Does this replace a job? No. It is a public signal. Screening still wants more than GitHub.
The job is: a small set of reviewed merges you can narrate, built on one or two repos, then the resume and pins. That is the whole page.