The most common illusion before your first open-source PR is that you need to do something large. My first PR fixed one broken command in a document and added a short installation note. It still walked through the entire collaboration process.
This is that path, saved for the next time I am about to press “Create pull request”.
Read the contribution guide first
Before forking, spend ten minutes on CONTRIBUTING.md, README.md, and the recent issues.
Check four things:
- Does the project accept documentation or small fixes?
- Are there conventions for branch names and commit messages?
- What are the code-style and test commands?
- Is an issue discussion expected before a PR?
Skipping this step saves ten minutes and often costs two days in review.
Fork, clone, and connect upstream
Fork the project to your own GitHub account, then clone it locally:
git clone [email protected]:your-name/project.git
cd project
git remote add upstream https://github.com/original-owner/project.git
origin points at your fork. upstream points at the original repository. Start each piece of work by syncing the main branch:
git fetch upstream
git switch main
git merge --ff-only upstream/main
Keeping your fork's main branch clean saves you from unrelated merge commits later.
Make the change do one thing
That PR changed two things: a broken command and the line of explanation beneath it. It did not reformat the whole file, and it did not include a second issue I happened to notice.
A small, complete change is easier to understand and easier to revert. If the thought “I should fix this too” appears, write it down as a separate issue instead.
Check the diff before committing:
git diff
git status
Make sure no editor files or personal configuration slipped in.
Write the PR description for your future self
A readable PR description usually covers three things:
- why: what problem exists, and where a reader gets stuck;
- what changed: two or three sentences on the scope;
- how it was verified: which command you ran and what you saw.
A screenshot or a terminal excerpt makes the reviewer's job much easier. Politeness is not decoration here. It lowers the cost of understanding your work.
After the merge
A merged PR is not the end. Sync upstream, remove the branch you no longer need, and start the next change:
git fetch upstream
git switch main
git merge --ff-only upstream/main
git branch -d fix/install-command
If a maintainer asks for changes, it is not a rejection. Open-source collaboration defaults to asynchronous attention and limited time. A clear response is more useful than repeated apologies.
The path matters more than the result
The size of your first PR does not matter. What matters is walking the whole collaboration path for the first time: reading the rules, committing, responding, merging, and cleaning up.
Next time you will know where to pause, where to add a test, and where to stay quiet. Open source is not a stage. It is a star chart maintained by many people. The small piece of light you add is real.