Why open source is worth it
- Proof of work - a merged PR in a real project beats a dozen tutorial clones on a resume.
- Real teamwork - you learn Git, code review, and how professional projects actually run.
- Network - maintainers and contributors are exactly the people who refer others to jobs.
- Confidence - your code, used by real people. That feeling is unmatched.
You will lean on Git heavily here. If you are rusty, keep the Git Guide open in another tab.
Step 0: Get ready
Before your first contribution, make sure you have:
That is genuinely enough to start. You will learn the rest by doing.
Step 1: Find a beginner-friendly issue
The secret is looking for issues that maintainers have marked as welcoming to newcomers. Search GitHub for these labels:
Great places to look:
- goodfirstissue.dev - beginner issues across popular projects.
- up-for-grabs.net - projects that want new contributors.
- Awesome for Beginners - a curated list of friendly repos.
- GitHub search:
label:"good first issue" language:javascript state:open
Pick a project you actually use or find interesting, you will care more and understand the context faster.
Step 2: Read the project's rules
Every serious project has a CONTRIBUTING.md and often a CODE_OF_CONDUCT.md. Read them, they tell you how to set up, how they want commits, and how to submit. Following these is the number one thing that gets your PR accepted (and ignoring them is the number one reason PRs get rejected).
Then comment on the issue before you start: something like "Hi! I'd like to work on this, is it still open?" This avoids two people doing the same work and shows good etiquette.
Step 3: The contribution workflow
This is the standard fork-and-pull flow. Learn it once and it works everywhere.
git clone https://github.com/YOUR-USERNAME/PROJECT.git
cd PROJECT
git checkout -b fix-typo-in-readmegit add .
git commit -m "Fix typo in installation section of README"git push origin fix-typo-in-readmeWhat a good pull request looks like
- Small and focused - fix one thing. Huge PRs are hard to review and often stall.
- Clear title and description - what changed, why, and how you tested it.
- Follows the project's style - match the existing code and their contribution rules.
- Links the issue - "Closes #123" ties it together.
- Polite and patient - maintainers are often volunteers. A friendly tone goes a long way.
Do's and don'ts
Avoid
- Giant PRs that change everything.
- Starting before reading CONTRIBUTING.md.
- Low-effort spam PRs (whitespace, pointless edits).
- Getting discouraged by a "changes requested".
- Ghosting your PR after review comments.
Do
- Comment on the issue before starting.
- Keep changes small and focused.
- Test your change before submitting.
- Ask questions politely if you are stuck.
- Say thanks, maintainers remember kind contributors.
Contributions that are not code
Open source needs more than programmers. All of these count and are great first steps:
What to do next
Once you have a merged PR, add it to your resume and portfolio, it is real, verifiable experience.
You do not need to be an expert to contribute. Fixing a typo in docs, improving an example, or closing a small bug are all real, welcome contributions. Maintainers love beginners who follow the rules and communicate clearly. Not sure how to word a comment or PR? Tap ✦ Ask AI and it will help you sound clear and professional.