Your first contribution
Contributing to open source is a small, mechanical process wrapped in a lot of unspoken etiquette. The mechanics take an afternoon to learn. The etiquette is what stops most people, so it is written down here too.
The shape of it
- 01
Find an issue that is genuinely free
Open, unassigned, no pull request already attached, and nobody saying they are on it in the comments. This is the part Tracer does for you.
- 02
Say you are taking it
A short comment on the issue. Not a request for permission, just a note so two people do not build the same thing. If a maintainer does not reply in a few days, that is usually fine to proceed on.
- 03
Fork, branch, change
Your own copy of the repository, a branch named after the change, and the smallest edit that solves the issue. Read the project's CONTRIBUTING file first; it exists to tell you the house rules.
- 04
Open the pull request
Describe what changed and why, and link the issue. Keep it to one concern. A small pull request gets reviewed; a large one waits.
- 05
Expect changes to be asked for
Review comments are not rejection. Most merged contributions go through at least one round. Answer, push another commit, move on.
Things nobody tells you
- A label is not a promise
- A good first issue can be three years old, already claimed, or much harder than it looks. Maintainers add labels once and rarely revisit them. This is the single biggest reason people bounce off their first attempt.
- Silence is normal, and not personal
- Maintainers are volunteers. A pull request sitting for two weeks is ordinary. Tracer shows you a project's typical first-reply time so you can pick one where that wait is shorter.
- Documentation counts
- Fixing a confusing README is a real contribution, lands faster than a feature, and teaches you the codebase while you do it. It is a better first move than most people assume.
- You do not need permission to start
- You need to not duplicate someone else's work. Those are different things, and the second one is solved with one comment.
How to read a Tracer score
The number is a summary, not the point. What matters is underneath it.
- Take it, worth a look, skip it
- The verdict is not just the score. An issue can score well and still be downgraded because somebody already called it, or because nobody can tell what finished would look like.
- In its favour, before you start
- Every score ships with the reasons that produced it. If a reason does not convince you, ignore the score. You know things about yourself that Tracer does not.
- Estimates are ranges, on purpose
- Three to ten hours means three to ten hours. Nobody can tell you how long an unfamiliar codebase will take, and a product that pretends otherwise is lying to you.
Worth reading elsewhere
- Open Source Guides: how to contribute(opens in a new tab)
The best single primer. Written by GitHub, not selling anything.
- First Contributions(opens in a new tab)
A repository whose whole purpose is letting you practise the fork, branch and pull request cycle on something harmless.
- GitHub docs: contributing to a project(opens in a new tab)
The exact commands, in order, for the fork and pull request flow.
When you are ready, the queue does the filtering so you can spend your time on the work instead of the search.