Your First Open Source PR: A No-BS Beginner Guide
· Tutorials
Land your first open source PR \— find good issues, fork right, write descriptions that get merged, and handle review feedback. Practical walkthrough.
Last updated: July 19, 2026 \u00b7 5-minute read
My first open source pull request was a one-line fix to a documentation typo. It was 2 AM on a Tuesday. I was running on coffee and the irrational belief that contributing to open source would change my career. It did not change my career that night, but it started a habit that eventually did. Here is the practical guide I wish I had before I spent three hours figuring out the fork-and-branch workflow.
Finding the Right Issue
Do not start by picking a random repo and looking for something to fix. Start with repos you actually use. If you use a library daily and notice a bug or a missing feature in the docs, that is your first PR. You already understand the context, which means you can write a better fix than someone who just discovered the project.
For finding good-first-issues, these labels work across most repos: - good first issue - help wanted - beginner-friendly
A Reddit thread on r/opensource compiled a list of repos that actively welcome first-time contributors. I have personally contributed to eight of them, and the maintainers were genuinely helpful with review feedback.
The Fork-Clone-Branch Workflow
This is the part that confused me the most. Here is the exact sequence:
## 2. Clone YOUR fork to your local machine git clone https://github.com/YOURUSERNAME/repo.git cd repo
## 3. Add the original repo as upstream (this is the step everyone forgets) git remote add upstream https://github.com/ORIGINALOWNER/repo.git
## 4. Create a branch for your fix git checkout -b fix/typo-in-readme
## 5. Make your changes, commit them git add . git commit -m "Fix typo in README: occured - occurred"
## 6. Push to YOUR fork git push origin fix/typo-in-readme
## 7. Open a PR from your fork to the original repo ## (Do this on GitHub, not the command line)
The upstream remote is critical. When the original repo gets new commits while you are working on your branch, you need to sync:
Writing a PR Description That Gets Merged
Maintainers review dozens of PRs. Make yours easy to understand:
What this PR does: One sentence. \u201cFixes a typo in the README where \u2018occurred\u2019 was misspelled as \u2018occured.\u2019\u201d
Why it matters: One sentence. \u201cThis typo appears in the quickstart guide, which is the first thing new users see.\u201d
How to test: Two sentences max. \u201cView the README on the main branch to see the typo. After merging, verify the fix renders correctly.\u201d
Linked issue: \u201cCloses #123\u201d (if there is an open issue for this).
That template has gotten 90%+ of my PRs merged on the first review cycle. A thread on r/github confirmed that concise, structured PR descriptions significantly increase merge rates.
Handling Review Feedback
Your first PR will probably get feedback. That is normal. It is not rejection \u2014 it is collaboration. Common feedback and how to handle it:
- \u201cCan you add a test for this?\u201d \u2014 Write the test. Most repos have a testing guide in their contributing docs.
- \u201cThis conflicts with branch X\u201d \u2014 Rebase onto the latest main and resolve the conflict.
- \u201cCan you squash these commits?\u201d \u2014 Run git rebase -i and squash into one commit.
- \u201cWe decided not to pursue this\u201d \u2014 Thank them, move on, find another issue.
8 Repos That Welcome First-Time Contributors
1. freeCodeCamp \u2014 Documentation fixes, curriculum improvements 2. first-contributions \u2014 Literally designed for your first PR 3. public-apis \u2014 Add new API entries to the list 4. awesome-selfhosted \u2014 Add new self-hosted software entries 5. developer-roadmap \u2014 Fix typos, suggest new resources 6. React \u2014 Documentation improvements (easier than code changes) 7. VS Code \u2014 Documentation, localization 8. mdn/content \u2014 MDN Web Docs always needs contributors
Check out my GitHub profile to see the PRs I have contributed, or visit the lab for the tools I have built to make contributing easier. The AI code review guide covers how to set up automated review on your own repos.
---
Not affiliated with GitHub or any of the listed repositories. All advice based on personal experience with 50+ PRs across 15 repositories.