The problem with the advice
A pull request is a stone thrown into a lake you don't own. The moment it lands, ripples spread outward in ways you can't predict - a CI system kicks off, a maintainer gets notified, a reviewer you've never met reads your code. If it merges, those ripples don't stop. They reach every user who installs the next version, every developer who reads your fix as a reference, every bug that doesn't happen because your test is there to catch it.
Most of those ripples you'll never see. That's the point.
Everyone says "contribute to open source." Nobody explains what that means when you're staring at a GitHub repo with 3,000 files and have no idea where anything is. This post is the practical version - how to find the lake, how to pick the right stone, and how to throw it cleanly. By the end of it you'll know how to find a project, understand it, make a change, open a pull request, and survive the review. I'll use examples from my own contributions to Fedora packages - the Packit post goes into one in depth if you want the full story.
What "contributing" actually means
First, kill the idea that contributing means writing clever new features. The vast majority of valuable contributions are:
- Fixing a bug someone else reported
- Adding or improving tests so future bugs get caught
- Improving documentation - fixing outdated steps, clarifying confusing sections
- Updating a dependency that's fallen behind
- Adding a small feature that's been sitting in the issue tracker for months
Docs and tests are genuinely undervalued. Most maintainers would rather have someone write a test for an edge case than build a new feature. They're also far more approachable for a first contribution.
Finding a project
The best first project is one you already use. If you've used a tool and hit a rough edge - a confusing error message, a step in the README that didn't work, a bug you had to work around - that's exactly where to start. You already understand the user perspective.
On GitHub, every repo has an Issues tab. Filter by the label good first issue. These are issues maintainers have explicitly flagged as approachable for newcomers. They're real problems, not make-work.
Other ways to find projects:
- github.com/explore - browse by topic or language
- The tools you already use - Flask, React, any CLI tool you install regularly
- Projects used by companies you admire - if you want to work somewhere, contributing to what they use gets you noticed
One practical tip: pick a project that's active but not enormous. A repo with 10 issues and no commits in two years won't give you feedback. A repo owned by a major company with 10,000 issues will be overwhelming and slow to review. A mid-sized project with regular commits and maintainers who respond in a few days is the sweet spot.
Understanding the project before you touch anything
Before writing a single line, spend time reading:
- README - what does this project do, how do you build it, how do you run tests
- CONTRIBUTING.md - many projects have one; it tells you exactly how to submit changes, what format commit messages should be in, whether to open an issue before a PR
- Recent pull requests - look at a few that were merged. How long was the review? How many rounds of changes? What did reviewers ask for? This tells you more about the project culture than any document
- The issue you want to fix - read the whole thread. Someone may have already started working on it. If so, don't duplicate - either collaborate or pick something else
Comment on the issue before you start. Something like "I'd like to take a look at this - does this approach seem reasonable?" saves you from building something in the wrong direction.
The mechanics
Everything from here happens in two places: your terminal (the black window where you type commands) and your browser (GitHub's website). If you've never opened a terminal before: on Mac it's called Terminal, on Windows it's called Command Prompt or PowerShell, on Linux you probably already know. Don't be intimidated by it - it's just a way of talking to your computer in text instead of clicks.
Here's the full flow, from zero to open pull request.
Step 1 - Create a GitHub account
Go to github.com and sign up. It's free. Pick a username you'd be happy putting on a CV - this is your public developer identity. Everything you contribute will appear here permanently.
Step 2 - Install Git
Git is the tool that tracks changes to code. Check if it's already installed by opening your terminal and typing:
git --version
If you see a version number, you're good. If not, download it from git-scm.com. Follow the installer - the default options are fine.
Step 3 - Tell Git who you are
You only do this once. Open your terminal and type these two commands (replace the name and email with your own):
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
Use the same email address you signed up to GitHub with.
Step 4 - Fork the repo
Go to the project's page on GitHub. In the top right corner, click the Fork button. This creates your own personal copy of the project under your GitHub account. Think of it as making a photocopy of a document so you can write on it without touching the original.
Step 5 - Clone your fork to your computer
Back in your terminal, type this (replace your-username and the-project with your actual GitHub username and the project name):
git clone https://github.com/your-username/the-project.git
This downloads your copy of the project to your computer. Then move into that folder:
cd the-project
Now you're inside the project. All the files are here.
Step 6 - Connect to the original project
Your fork is a copy, but the original project keeps getting updated. This command lets you pull in those updates later:
git remote add upstream https://github.com/original-owner/the-project.git
Replace original-owner and the-project with the real values from the project's GitHub URL.
Step 7 - Create a branch
A branch is a separate workspace inside the project. You create one so your changes are isolated and don't interfere with anything else. Never make changes directly on main - always create a branch first.
git checkout -b fix-readme-install-steps
The name after the -b is your branch name. Make it describe what you're changing.
Step 8 - Make your change
Open the project files in a code editor (VS Code is a good free option if you don't have one). Find the thing you want to fix and fix it. Follow the style of the code around it - if everything uses double quotes, use double quotes.
If the project has tests, run them before and after your change to make sure you haven't broken anything. The README usually explains how.
Step 9 - Save your change with Git
When you're happy with the change, go back to your terminal and run:
git add .
git commit -m "docs: fix installation steps on macOS"
The first command stages your changes (marks them as ready). The second saves them with a message. Write a commit message that explains what you changed and why - not just that you changed something. A good message: "fix: handle empty username in login form". A bad message: "fix stuff".
Step 10 - Push your branch to GitHub
This sends your local changes up to your fork on GitHub:
git push origin fix-readme-install-steps
Step 11 - Open a pull request
Go to your fork on GitHub (github.com/your-username/the-project). You'll see a yellow banner saying "Compare & pull request" - click it. Write a clear description of what you changed, why, and how the reviewer can test it. Then click "Create pull request."
That's it. The stone is in the water. Now you wait for the ripples to come back.
Writing a good pull request
The PR description is a communication to the maintainer - someone who doesn't know your thought process. Include:
- What you changed (a one-line summary)
- Why you changed it (link to the issue if there is one)
- How to test it - what should the reviewer actually do to verify your change works
Keep the change focused. Don't fix the bug and then also refactor three files and update the README structure. One thing per PR. It's easier to review, easier to revert if something goes wrong, and much more likely to get merged quickly.
The review loop
Most first-time contributors are surprised by how much back-and-forth there is. A maintainer will ask for changes. This is normal. It's not rejection - it's collaboration.
When you get review comments:
- Read all of them before responding or changing anything
- Ask questions if you don't understand what's being asked for
- Push your changes to the same branch (
git push origin your-branch) - the PR updates automatically - Reply to comments to let the reviewer know what you changed
Be patient. Maintainers are volunteers with day jobs. A few days to a week for a response is normal. A few weeks for a complex PR is also normal.
Don't take the feedback personally. "This could be simplified" or "we handle this differently elsewhere" is just code review - the same thing happens inside every professional engineering team.
A real example
When I added Packit CI to a Fedora package (the full write-up is here), what looked like a one-ticket change turned into multiple review rounds, a spec file rewrite, a discovered bug in how patches were being applied, and eventually a tagged release. Every one of those rounds taught me something that no course would have covered.
The first review comment asked me to change how I was handling the spec file. I had to understand why before I could fix it properly. That's the value - not just making the change, but understanding the reason.
What it does for your career
Two concrete things.
First, your GitHub profile becomes a public record of how you work. Commit messages, PR descriptions, how you respond to code review - all of it is visible. For someone without a traditional CV, this matters a lot. My profile is github.com/c4rt0 if you want to see what that looks like in practice. The commit history is the ripple trail - a record of every stone thrown and where it landed.
Second, it gets you inside the door of a community. The maintainers who reviewed my Fedora contributions are the same people I work alongside at Red Hat. A stone dropped in the right lake reaches shores you can't see from where you're standing. Contributing is how I showed I could operate in that environment before I was officially part of it.
The short version
- Pick a project you already use. Filter issues by
good first issue. - Comment on the issue before you start. Agree on the approach.
- Fork, clone, branch - never work on
main. - Make the smallest change that solves the problem.
- Write a commit message that explains the why, not just the what.
- Open a PR with a clear description and a way to test it.
- Respond to review comments. Be patient. Push updates to the same branch.
The first one is the hardest. After that, the process becomes familiar and the contribution size can grow. Start small, start somewhere, and the rest follows.
Find a lake. Pick a stone. Throw it.