How long does it take to make a first open source contribution?

First contribution: 4-8 hours end-to-end (find a project, set up the dev env, find a good first issue, submit a PR, respond to review). Most of the time is the dev env setup — the actual PR is usually small (a typo fix, a test case, a doc improvement). A first substantive contribution (a real feature) is 1-2 weeks of part-time work.

Blog · First contribution

How to contribute to open source for the first time

Q: What's a good first issue?

Look for the 'good first issue' label, the 'beginner-friendly' label, or the 'help wanted' label. A good first issue is: (1) small (under 50 lines of change), (2) well-described (the maintainer has explained what they want), (3) tests are clear or unnecessary, (4) doesn't require deep context. Avoid issues marked 'complex' or 'research'.

Q: What if my first PR is rejected?

It's not the end of the world. Most maintainers will give you specific feedback. Read the feedback carefully, respond to each point, push the changes, and ask for re-review. If the maintainer closes the PR after you push the changes, that's OK — your work is in the commit history, you've learned the workflow, and you can try a different project. A closed PR is not a failure; it's a learning moment.

The first-contribution playbook. Find a project, set up the dev environment, find a good first issue, submit a PR, respond to review. The path from zero to a real commit history.

Published July 13, 2026 · ~5 min read

The time budget

4-8 hours end-to-end for a first contribution. Most of that is the dev environment setup — the actual PR is usually small. A first substantive contribution (a real feature) is 1-2 weeks of part-time work.

The 5-step path

1. Find a project

Pick a project you already use. You'll know the use case, you'll know what good looks like, and the maintainer will be grateful. If you don't have one, the GitHub good first issue topic search and the OpenHatch directory are good starting points.

2. Set up the dev environment

Follow the README's "How to develop" section. If there isn't one, open an issue asking for one — that's a valid first contribution. Most first contributions die here, not at the PR review stage. If you can get the project to build and the tests to pass locally, you've passed the hardest part.

3. Find a good first issue

Look for the good first issue, beginner-friendly, or help wanted label. A good first issue is: (1) small (under 50 lines), (2) well-described, (3) tests are clear or unnecessary, (4) doesn't require deep context. Avoid issues marked complex or research for your first contribution.

4. Submit a PR

Open a PR with a clear title ("Fix typo in README: 'recieve' → 'receive'") and a description that says: (1) what you changed, (2) why, (3) how to test, (4) any related issues. Link the issue: "Closes #1234". Follow the project's PR template if there is one. The PR is the artifact; the description is what gets the maintainer's attention.

5. Respond to review

Most maintainers will give you specific feedback. Read the feedback carefully, respond to each point, push the changes, and ask for re-review. If the maintainer is slow to respond (3+ days), a polite "Just checking in on this PR" comment is appropriate. If the maintainer closes the PR after you push the changes, that's OK — your work is in the commit history, you've learned the workflow, and you can try a different project.

Frequently asked questions

How long does it take to make a first contribution?

4-8 hours end-to-end. Most of that is dev env setup.

What's a good first issue?

Small, well-described, no deep context required. Look for good-first-issue, beginner-friendly, or help-wanted labels.

What if my first PR is rejected?

Read the feedback, push the changes, ask for re-review. A closed PR is not a failure — it's a learning moment.