Skip to content

The guide

Nobody explains this part. So here it is, in one place.

What happens after you hit submit, the commands, who reads your patch, and the words everyone assumes you know.

The loop

What happens after you press submit. Including the scary step.

Five steps. One of them is somebody asking for changes, which is the normal case, not a failure.

  1. You open the pull request

    Your branch, plus a line on what it fixes. Feels huge; it's the smallest step.

  2. CI runs

    Tests run on your branch. Red is info, not judgement — read the log, push again.

  3. A maintainer reviews it

    Someone reads your diff. It can take weeks — silence isn't about you.

  4. Changes requested

    Totally normal, even for pros. Someone cared enough to have opinions — push another commit.

  5. Approved and merged

    Your name is in the project's history for good. That's the prize — not a certificate.

That's the whole loop. Every contribution ever made went through it.

And the commands, for real

These work on this site's own repo. Copy away — the prompts stay behind.

your first contribution

# fork it on GitHub first, then:git clone https://github.com/<you>/scaleropensourcelabs.com.gitcd scaleropensourcelabs.com/webnpm installnpm run devready on http://localhost:3000# then, for the change itself:git checkout -b fix-the-thingnpm run typecheckgit commit -am 'Fix the thing'git push origin fix-the-thing
The full CONTRIBUTING.md ↗

Who is on the other side

There is a person at the other end of your pull request. Usually an unpaid one.

Knowing this changes how you write a pull request.

Often not paid for it

Whoever reviews your first PR is often doing it after their day job, just because they care.

Nobody had even mapped it

The Linux Foundation, OpenSSF and Harvard needed a whole census just to find out which packages the world depends on. So nobody's really in charge.

Which is why review feels slow

A PR sitting for three weeks is almost never about you. It's one person with a backlog and a day job — a queue, not a rejection.

Census III of Free and Open Source Software ↗

The words

Nobody is going to explain these to you. So here they are.

12 words used constantly, explained never. We all learned them by being confused in public.

upstream
The original project, not your copy. “Landed upstream” means the real project took your change.
fork
Your own copy of the project on GitHub. Break whatever you like — it's yours.
good first issue
A label for tasks sized for newcomers. Filtering by it isn't cheating — it's the point.
maintainer
The person who decides what gets merged. Usually a volunteer. Almost always busier than you assume.
triage
Sorting new issues into what they actually are. Unglamorous, endless, and hugely welcome help.
nit
A small, non-blocking comment. “nit: trailing whitespace” is not a rejection and is not criticism of you.
LGTM
“Looks good to me.” An approval. Your first one is a great day.
rebase
Replaying your commits on top of the latest upstream, so history stays a line, not a knot. You'll be asked to at least once.
squash
Collapsing your eleven “fix typo” commits into one clean commit before it is merged. Nobody minds that you needed eleven.
licence
The terms the code ships under. MIT and Apache-2.0 let anyone use it; the GPL also requires derived work to stay open.
CLA
A Contributor License Agreement. Some foundations want one before your first merge. Routine, not a trap, two minutes.
RFC
A written proposal for a change big enough to argue about first. Old ones show you how a project thinks.

Now do it with company

Reading about it is the slow way. A build day is the fast one.

One evening, a senior beside you, and setup sorted before you get stuck.

Join the club →