After Your First Open Source Contribution

Leonid Bugaev
|
(Updated August 31, 2026)
|
7 min read
beginners contributing pull-request open-source

The first PR merged. This page is the next hour, and whether you stay for issue two.

It is not how to fork, clone, or open a pull request. That is the first pull request guide. It is not a PR-description template. It is not the week-1 map — that is how to contribute to open source. You already did that work. The question now is stay or leave.

Say thanks once

One short comment on the merged PR: thanks, and you will look for another issue if you mean it. Then stop.

Do not write a paragraph. Do not ping anyone in chat. Do not open a new issue that is just a thank-you. Maintainers read the merge. They do not need a ceremony.

If they already replied on the merge, skip yours. Reciprocity is not a second thread.

Update the fork, delete the branch

The branch you shipped is done. Sync your fork to upstream default, then delete the feature branch — locally and on GitHub.

The Git commands live in the first pull request guide (after it merges, and keep the fork current). This page will not re-teach fetch or merge. The hygiene is the point: a stale feature branch is how you open issue two from the wrong base.

If GitHub offers Delete branch on the merged PR, use it. Start issue two from a fresh branch off the updated default.

Issue two is cheaper in the same repo

You already paid the setup tax.

You know the test command. You know who actually reviews. You have notes from CONTRIBUTING.md and the code of conduct. The clone and remotes exist. CI already ran your first patch, so you know what red looks like here.

That is why issue two on this repo is cheaper than a first issue on a random other repo. Hunting again is fine when you should leave. It is a waste when the room still works.

How to pick the ticket is still how to pick an issue that will get merged: specified, unclaimed, a recent maintainer reply. Do not re-learn Git. Do not re-write a PR description.

Slightly harder leaf, not core

Issue two is one step up from issue one. Not a rewrite.

A slightly harder leaf: another test in a package you already touched, a small fix next to the first one, docs the issue asked for in a file you now understand. Same area, slightly more judgment.

It is not core. Do not take the parser, the runtime, the plugin API, or a refactor because you merged once. One merge is not tenure.

It is not a drive-by style PR. Do not restyle a file you did not need. Do not open a formatter-only diff. Do not hunt a README typo in a repo you have never run. That is the same spam as a first-timer dump, with a merged PR as cover.

If the only labeled tickets left are core or architecture, you are done with this repo for now. Leave. Do not invent work.

When to leave

Stay is the default when the repo still reviews. Leave is the right call in three cases.

Silence after merge. The PR landed and nobody engaged — no review you can learn from, no next issue, and the remaining labeled tickets sit for months. One quiet merge can still be a good merge. A quiet project after you shipped is a signal they will not staff issue two either. Walk.

Hostile review. The patch landed (or closed) with personal comments, sarcasm, or a pile-on. Argue the patch, not the person — and if they will not, you do not owe them a second issue. The code of conduct is the bar for how people talk. You do not have to stay in a thread that ignored it.

You cannot boot the project again. Issue one was a docs tweak you could preview. Issue two needs the test suite, a compiler, a simulator. If you cannot run it this week, do not claim it. Leave this repo until you can, or pick a leaf you can actually boot.

Leaving cleanly: no ghost I-will-take-this on three issues, no half-open draft, no complaint on the merged PR. Sync, delete the branch, stop.

Do not farm twenty identical typos

A merged docs PR on a project you read is real. Twenty README nits across random repos is not a contribution history. It is a pattern maintainers already close.

Do not spray the same typo fix at every labeled repo you can find. Do not grind easy docs for a green square. That is how you get ignored, and it is how first-timer labels get burned.

Stay for issue two here, or leave and hunt one new issue on a live hub. Those are the two honest moves. Farming is a third move that helps nobody.

One merge is not a portfolio

A merged pull request is public work. You can point at the issue, the constraint, the review, and what you would do next. That is a start.

It is not a portfolio. One docs PR does not get you hired. A graph of drive-by typos does not either. If the reason you are here is a job search, read how to build a developer portfolio through open source after you have a merge — then stay on the same project long enough that the second and third PRs show up. This page will not write that article.

Next issue

If you are staying, pick the next ticket on this repo the same way you picked the first: specified, unclaimed, sized to an evening.

If you are leaving, hunt on a live hub, not a gist:

FAQ

Do I have to say thanks after a merge?

Once, if nobody already did. One line on the PR. Not a new issue, not a chat ping, not a blog post. Then delete the branch.

Should issue two be a different repository?

Usually no. Same repo is cheaper: CI, reviewers, CONTRIBUTING, the clone. Switch repos when you should leave — silence, hostility, or you cannot boot — not because a new name feels like progress.

When is leaving the right call?

Silence after merge on a project that does not staff reviews, a hostile thread, or a next ticket you cannot boot. Leave cleanly: no leftover claims. Hunt the next issue on a hub.

Can I farm identical docs typos across random repos?

No. One asked-for docs change is a real first merge. Twenty of the same nit on repos you do not run is spam. Stay for a harder leaf here, or pick one new issue somewhere else.

Is one merged pull request a portfolio?

No. It is a start. Talk about the issue and the review. Then ship issue two on the same project. The portfolio version is how to build a developer portfolio through open source.

Back to all articles Find projects that need your help