Start with documentation on a project you actually use. It's the highest-acceptance, lowest-intimidation entry point, and it's genuinely valuable — docs are chronically neglected and maintainers are usually delighted when someone fixes them.
The path that works:
1. Pick a project you use. Familiarity matters enormously — you'll spot problems naturally and understand the context. Contributing to a random 'beginner-friendly' repo you've never used is much harder than it sounds.
2. Look for the easy-entry labels: `good first issue`, `help wanted`, `documentation`, `beginner-friendly`. GitHub lets you filter by these across repositories.
3. Read `CONTRIBUTING.md` before anything. It tells you the branch conventions, commit style, how to run tests, and how they want PRs. Ignoring it is the most common reason a PR sits unreviewed.
4. Comment on the issue before starting: 'I'd like to work on this — is it still available?' This avoids duplicated effort and gets you an early signal about whether your approach is wanted.
5. Keep the first PR small. One typo fix, one clarified paragraph, one small bug. A large first PR from an unknown contributor is hard to review and often stalls. Small merged PRs build the relationship that makes bigger ones possible.
The mechanics: fork the repo, clone your fork, create a branch, make the change, commit, push to your fork, open a pull request against the original. GitHub walks you through most of it. Write a PR description that says what problem it solves and how you tested it — reviewers are volunteers with limited time, and a clear description is a genuine kindness that gets you reviewed faster.
What to expect emotionally, so it doesn't derail you:
- Review comments are normal, even many of them. They're not rejection; they're the process working. Respond, make the changes, push again to the same branch.
- Some PRs sit for weeks. Maintainers are unpaid and busy. A polite ping after a couple of weeks is acceptable; frustration is not.
- Some get closed. It happens, often for reasons unrelated to your code quality — a direction change, a duplicate effort. Move on to the next one.
Why it's worth doing beyond the badge: you get real code review from experienced developers, which is expensive to get otherwise; you learn to work in a codebase you didn't write, which is exactly what a job is; and you build a public record of collaborative work. For self-taught developers without professional experience, a few merged PRs to a project people recognise is one of the strongest signals available.