This page is the resume document. One bullet per merged pull request you can defend in an interview. It is not your GitHub profile. Pins, bio, and a README that names the change live on how to build a developer portfolio through open source. This page will not write that article.

A contribution-graph screenshot is not a resume section. “Contributed to 40 repositories” is not a bullet.

Pick one place

Put the work in one of three spots. Not all three.

Experience — if you did the work as a job, a contract, or a long stretch of ownership on one project. Treat it like any other shipped work: project or employer, your role, then bullets. Do not invent a company. Nights-and-weekends on a public repo is not a job title.

Projects — if you have one or two merges you can walk through, and they are not already under a job. One merge can live as a Projects line. Name the project, one bullet, optional PR link. That is enough.

A short Open Source section — if you have several merges on different projects and they do not fit Experience. Three to five bullets. Same formula as below. Still the document, not a dump of GitHub.

Do not triple-list the same PR. If it is under Experience, it is not also in Projects and not also in Open Source.

The bullet formula

Verb + what shipped + where. The where is a project name, not “various OSS” and not “the open source community.”

A link to the merged PR is optional. Include it if the URL is stable and you will click it in an interview. Skip it if the repo went private, or if the PR is a one-line typo you cannot defend.

Only list merged (or clearly accepted) work. An open PR is not a resume line. A closed-unmerged PR is not a resume line. A draft you never finished is not a resume line.

You must be able to talk about it: the issue, the constraint, what you changed, what review asked for. If you cannot, it does not belong on the document.

Volume is not a skill

Do not write “contributed to 40 repositories.” Do not paste a contribution-graph screenshot. Do not list every fix typo that merged.

Five similar typos still look like one skill. One asked-for test on a project you ran looks like a skill. Repo count is not the signal. The bullet is.

If you only have one merge, one Projects line is honest. Wait for issue two on the same project before you invent a heading.

How a hiring manager reads a GitHub profile is a different article. A plan built around five merged PRs is too. This page is the document: bullets only.

Good vs bad bullets

Generic. No famous names. Yours should name your project.

Bad

Contributed to various open source projects
40+ repositories, 200+ contributions
Passionate about open source
Fixed typos in documentation (×12)
Open source contributor (see GitHub)

Good

Added a table-driven test for the CSV parser in project-name (merged PR)
Documented the restore command in project-name after the README example failed to install
Fixed a nil-pointer on empty input in project-name’s CLI; stayed through review

The good lines name a verb, a shippable change, and a project. The bad lines name a feeling or a count.

Get the work, then write the line

You cannot bullet what you have not merged. Hunt labeled issues on a live hub, not a gist of famous names:

How to pick the ticket: how to find good first issues. How to open the PR: first pull request guide. After it lands, stay or leave: after your first open source contribution.

Those hubs are for getting the work. They are not a resume template.

How to build a developer portfolio through open source — GitHub presence: pins, bio, README. Not this document
After your first open source contribution — stay for issue two, or leave
How to find good first issues — labeled work on live hubs
First pull request guide — fork, clone, branch, open the PR

FAQ

Should I put my GitHub profile on the resume?

A URL, yes — one line in contact. The profile itself is how to build a developer portfolio through open source. Do not screenshot the graph into the PDF.

Where do open source bullets go?

One place: Experience if it was a job, Projects if you have one or two merges, or a short Open Source section if you have several. Do not list the same PR three times.

Can I list open pull requests?

No. Merged, or clearly accepted. If you cannot open the PR and walk the review, it is not a bullet.

Is “contributed to 40 repos” a good line?

No. It is a count. Five similar typos still look like one skill. One merge you can defend is the line.

I only have one merge. Do I need an Open Source section?

No. One Projects line is enough. Ship issue two on the same project before you invent a heading.