Contributing to Someone Else's Project

You have found a typo in the documentation of a tool you use every day. You know exactly what it should say. And you cannot push the fix, because you have no access to that repository.

The route around it is a fork: your own copy of their repository, under your account, where you can do anything you like — and from which you can propose a change back to the original.

What a fork is

GitHub makes a copy of the repository under your username. It is an ordinary repository in every respect, and it remembers where it came from, which is what lets GitHub offer a pull request from your copy to theirs.

Like the pull request itself, a fork is a GitHub feature rather than a Git one. Git only ever sees repositories and remotes.

The full loop

Fork on the website, then everything else is Chapter 8 with one extra copy in the chain:

git clone git@github.com:YOUR-USERNAME/their-project.git
cd their-project
git switch -c fix-install-typo

git add README.md
git commit -m "Fix the package name in the install instructions"
git push -u origin fix-install-typo

Then open a pull request on GitHub — from your fork's branch, into the original repository. GitHub offers this the moment it notices the new branch, and it fills in both ends for you.

Notice that origin here is your fork, not the original project. That is the one detail that trips people up, and it is why the clone command above uses your username.

Read the rules first

Many projects have a CONTRIBUTING.md file saying how they want to be approached: whether to open an issue before writing anything, how they want commits formatted, what they will and will not accept.

Read it before you start. Ignoring it is the fastest way to have genuinely good work declined, and it is entirely avoidable.

Also skim the open issues. Someone may already have reported your typo, and a project with two hundred untouched issues and no commits for three years is telling you something about how long your pull request will sit there.

Etiquette

One change per pull request. A typo fix and a feature idea in the same proposal cannot be accepted separately, so both wait for agreement on the harder one.

Explain what and why. The maintainer has never met you and has no context. Two sentences is usually enough.

Be patient. Most maintainers are volunteers doing this in evenings. A week of silence is normal and is not about you.

Take a no gracefully. A declined pull request is not a wasted one — you learned the codebase, and the maintainer's reason is usually something you could not have known.

A realistic first contribution

A typo. A broken link. A missing step in an install guide. A sentence that is technically correct and impossible to follow.

These sound trivial and they are genuinely valued, because they are exactly the problems that maintainers cannot see any more — they know how the thing works, so the missing step is invisible to them. Documentation fixes are how a very large number of open-source contributors started.

On Sandpiper: Theo uses a small photo-gallery script and finds its README missing a step. He forks it, fixes the step, and opens his first pull request to a stranger, using nothing that this book has not already taught.