You want to contribute to open-source projects but don’t know where to start? This article is a practical roadmap from someone who has gone through hundreds of pull requests, helping you overcome the fear of your first commit and make a real impact in the GitHub community. No empty theory—just concrete steps, along with classic mistakes and how to fix them.
Why Are You Afraid of Open-Source Contribution? I Was Too.
Honestly, the first time I opened a large repository like React or Kubernetes, my head spun. Thousands of files, endless commit history, piles of issues. I asked myself: “Am I skilled enough to touch this?”
Stop Treating AI Agents Like Microservices: Why Your Orchestration Needs a Survival Mode
Stop Treating AI Agents Like Microservices: Why Your Orchestration Needs a Survival Mode I’ve seen it happen a… ...
The answer is: Yes. But not everyone dares to start.
In fact, according to a GitHub report, over 80% of contributors have only one pull request. They try, then quit. Why? Because they lack a clear, easy-to-follow open-source contribution guide.
How I Finally Nailed My React Project Setup in 2026 (And How You Can Too)
TL;DR: Setting up a React project in 2026 isn’t about just running npx create-react-app anymore. This guide walks… ...
Let me be honest: you don’t need to be a coding genius to contribute. You just need to be able to read and understand code, be patient, and… dare to ask.
Step 0: Choose the Right Project – Don’t Go Big from the Start
It may sound counterintuitive, but don’t choose a too-famous project to start with. Why?
- Large projects have complex review processes and picky maintainers.
- Issues are easily snatched up by others.
- You can easily get discouraged by lack of progress.
In my experience, choose a project you’ve used, with a moderate codebase (under 50k lines), and labeled good first issue or help wanted. For example: a small JavaScript library, a CLI tool, or a VS Code extension.
Last month, I guided a fresher to contribute to the ECOA AI Platform. The project had a very detailed CONTRIBUTING.md document, even with a video walkthrough. They merged their first pull request in 3 days. Their confidence soared.
Step 1: Fork the Repository – Create Your Own Copy
This step is very familiar, but I see many people still get it wrong.
You need to fork the original repo to your GitHub account, then clone it to your local machine. Note: don’t clone the original repo directly because you don’t have push access to it.
# After forking on GitHub, clone it down
git clone https://github.com/YOUR_USERNAME/project-name.git
cd project-name
# Add remote upstream to sync with original repo
git remote add upstream https://github.com/ORIGINAL_OWNER/project-name.git
# Check
git remote -v
# origin -> YOUR_USERNAME
# upstream -> ORIGINAL_OWNERAlways keep origin as yours and upstream as theirs. Don’t mix them up.
Step 2: Create a Separate Branch – Don’t Commit to main
This is a classic mistake: committing directly to the main/master branch of your fork. Later, when you want to create a pull request for another project, you’ll run into trouble because of messy commit history.
Solution: create a new branch for each issue/fix.
git checkout -b fix/typo-in-readmeName branches according to standard: fix/..., feat/..., docs/.... Maintainers can instantly tell what you’re doing.
Step 3: Understand the Codebase – Spend 30 Minutes Rather Than Lose 3 Days
I once saw a friend edit a line in utils.js, only to break all tests. Because they didn’t realize that function was called in 15 other places.
Before coding, do:
- Read the CONTRIBUTING.md file (if available).
- Read a few old pull requests to understand the review style.
- Run the project locally. If it doesn’t run yet, don’t rush to code.
- Find existing tests for the part you plan to modify.
Tip: use VS Code’s Find in Files feature to trace dependencies. If your function is imported in 20 files, check at least the first and last 5 files.
Step 4: Write the Code – But Don’t Forget Tests
Open-source contribution isn’t just about typing code. What maintainers hate most is a pull request without tests.
So always write tests for your code. At least unit tests for new logic, or integration tests for the main flow.
// Example: test for capitalize function
test('capitalize should convert first letter to uppercase', () => {
expect(capitalize('hello')).toBe('Hello');
expect(capitalize('HELLO')).toBe('Hello');
expect(capitalize('')).toBe('');
});And remember to run npm test or the equivalent test command before committing. If tests fail, don’t push. It’s that simple.
Step 5: Commit Messages – The Art of Writing a Few Lines
Common mistakes: “Fix bug”, “Update file”, “changes” – too vague.
According to the Conventional Commits convention, write in this format:
git commit -m "fix: correct typo in CONTRIBUTING.md
- Changed 'githb' to 'github'
- Related issue #42"Maintainers can instantly know what you did, which error you fixed, and which issue you referenced. Extremely professional.
Step 6: Push to Fork and Create a Pull Request
After committing, push the branch to your fork on GitHub:
git push origin fix/typo-in-readmeOn GitHub, you’ll see a green “Compare & pull request” button. Click it and write a proper PR description.
PR description should include:
- A summary of changes (1-2 sentences).
- Screenshot or before/after log (if UI-related).
- Closes #<issue_number> to automatically close the issue when the PR is merged.
Example of a great description:
“This PR fixes the typo ‘githb’ in the CONTRIBUTING.md file. No functional changes. Closes #42.”
Step 7: Handle Reviews – Don’t Be Defensive, Learn
This is the step most people fear. You submit your PR, and a few hours later the maintainer comments: “Please use const instead of let”, “This function lacks error handling”.
Don’t be discouraged. That’s a good sign: they read your code.
In my experience:
- Reply to each comment, either fix the code or explain why.
- Never say “This is the code I wrote, I think it’s fine.” Ask back if you don’t understand.
- Commit fixes on the same branch and push again.
Once, a maintainer asked me to refactor a 50-line function into 3 smaller functions. At first, I thought it was unnecessary, but after doing it, the code was much cleaner. I learned a lot.
Common Mistakes When Contributing to Open Source (and How to Avoid Them)
| Mistake | Consequence | How to Avoid |
|---|---|---|
| Not reading CONTRIBUTING.md | Rejected due to incorrect format | Always read that file first |
| Committing to main branch | Messy history, hard to isolate PR | Create a separate branch for each issue |
| Missing tests | PR held or rejected | Write tests alongside code |
| Vague PR description | Maintainers don’t understand your changes | Write clearly, include issue link |
| Not syncing with upstream | Conflicts, difficult to merge | Rebase frequently |
How to Make Maintainers Like Your Pull Request?
I have a few tips after many years in open source:
- Small PR: One PR should fix one issue. Don’t bundle “fix bug A + add feature B + refactor C”.
- Clean code: Run linter, format code before pushing.
- Quick response: Within 24 hours. Maintainers like proactive contributors.
- Be grateful: Even if rejected, thank them for taking the time to review.
A story: I once submitted a PR to the ECOA AI Platform library, just fixing a few spots in the docs. The maintainer praised me for the clear commit message and for referencing the CODE_OF_CONDUCT.md file beforehand. Later, I got the opportunity to become a core contributor.
The Contributor Journey: From Zero to 100 PRs
Don’t think open-source contribution is a race. It’s a long-term learning journey.
My goal for you: set a target of 5 pull requests in 3 months. With 5 PRs, your GitHub profile will stand out significantly. With another 10-20 PRs, you’ll have your name in the contributor list of a large project.
And most importantly: enjoy the process. Don’t stress over reviews, don’t fear rejection. Every time you get rejected, you’re being taught for free by someone very skilled.
Frequently Asked Questions (FAQ)
I’m not good at coding, can I still contribute?
Absolutely. Many projects need people to write documentation, translate, design logos, manage issues. Contribution isn’t just about coding. Look for labels like “docs” or “help wanted”.
How to find an open-source project that suits me?
Go to GitHub, use search with filter: label:good-first-issue state:open and choose the language you know. Or use GitHub Explore. Additionally, the ECOA AI Platform has a list of issues suitable for beginners.
My pull request was rejected, what should I do?
Don’t be sad. Read the rejection reason carefully, ask if unclear, fix according to feedback, and resubmit. If it seems unreasonable, politely ask the maintainer. Most of them want to help you improve.
Should I contribute to multiple projects at the same time?
No. Focus on 1-2 projects in the first 3 months. Deep contributions are better than broad ones. A maintainer who recognizes you is worth more than 10 anonymous PRs.
How long does it take to get the first PR merged?
On average, 1-7 days, depending on the project and complexity. A typo fix might be accepted in hours. A new feature may take weeks. Be patient.
I hope this article helps you confidently start your open-source contribution journey. If you have any questions, feel free to comment below. I’ll answer to the best of my ability. Wishing you your first PR very soon!
