Your first contribution
Everything up to now has been watching this story happen to other people. This one's yours, start to finish.
You've just finished explaining the whole system to this year's newest General Member. They ask the obvious next question: "okay, so what should I actually do?" And you realize the honest answer is the same thing that happened to Ishaan, chapters ago — except this time you're going to do it together, and this time, it's this exact guide that needs the fix.
Reading back through Chapter 12 together, they notice something: the SSH section says to add the key at github.com/settings/ssh/new, but doesn't mention that GitHub now sometimes calls this page something slightly different depending on which onboarding flow you land in first-time. Small, genuinely useful, exactly the kind of thing only someone reading it fresh would ever catch. A real "good first issue" that Vidha, if she saw it, would tag immediately.
Find something real before you touch a single command
Browse accelerate-muj/resources/issues, filter for label:"good first issue", read whichever one you pick completely — including every comment, in case someone's already claimed it. If nothing's tagged yet for what you found, that's fine too: comment on the guide's own tracking issue, or open a new one describing exactly what's unclear and why, the same discipline Chapter 16 taught. Either way, say something before you start: "I'd like to take this on" — a fifteen-second message that saves two people from duplicating the same work.
1. Fork, since you're still on the General Members tier
Click "Fork" on accelerate-muj/resources. You now own a complete copy at your own GitHub username — Chapter 11's whole diagram, except it's your name on it this time.
2. Clone your fork, not the original
3. A branch with a name that explains itself
4. Make the actual change
Open git-guide/12-auth.html, find the SSH section, add the clarifying sentence. Small, honest, exactly scoped to the issue — resist the urge to also "fix" three unrelated things you notice along the way. A tightly scoped PR is dramatically easier for someone to review than one that quietly grew.
5. Actually check it, don't just assume it's right
Open the file in a browser — this whole guide is plain HTML, so a double-click or a local server is all it takes — and read your change exactly as the next confused newcomer will. Does the sentence land? Is it still accurate? For a code change instead of docs, this is the moment you'd run npm test or npm run build — the same CI checks from Chapter 18 are about to run this exact verification automatically anyway, but catching it yourself first is faster than waiting for a red X.
6. Push to your fork
7. Open the PR — from your fork, into the real repo
Title: docs: clarify SSH key settings page for new GitHub UI
## What
Added a note that GitHub's SSH key settings page name has
changed slightly depending on the onboarding flow, so newcomers
don't get stuck looking for an exact page title.
## Why
Closes #41 — caught this while walking a new recruit through
Chapter 12 in person.
## Tested
Opened the page locally, read it fresh, confirmed the new
sentence reads clearly in context.Base repository: accelerate-muj/resources, main. Head: your fork, your branch. Exactly Chapter 13's shape, except the PR author is you.
8. Review happens, same as it did for Ishaan
CI runs automatically (Chapter 17 — even a docs-only PR gets the lint pass, harmless, just confirms nothing's structurally broken). A maintainer — maybe Vidha, maybe you a year from now, reviewing someone else's first PR — reads it, comments if something needs adjusting, approves when it's right. You reply to anything raised, push a follow-up commit if needed, same etiquette Chapter 13 walked through.
9. Merged
Squash and merge, since it's solo work — Chapter 14's rule, applied without you even having to think about which button to click, because you already understand why. Your name lands on main, permanently, with a link back to your PR. Your branch auto-deletes from your fork. The next person who reads Chapter 12 gets your fix, with no idea how many confused minutes it saved them.
10. Tidy up, and get ready for the next one
Where this story started, and where it stops being a story
Chapter 1 opened with a folder on Rachit's laptop that existed in exactly one place on Earth, one dead battery away from being nothing. Twenty-two chapters later, the same project has full history, branch isolation, reviewed changes, automatic deployment, security scanning, and an org structure that survives any single person leaving. Every piece of that arrived because a specific, felt problem showed up and got solved — never because a list of features seemed impressive on its own.
That's the actual habit worth keeping, more than any individual command: when something about the workflow feels manual, error-prone, or dependent on someone remembering to be careful, that feeling is usually pointing at a tool that already exists for exactly that problem. Go looking for it before you accept the risk as normal.
Where to go from here
- Take another
good first issue, or file one yourself for something you noticed. - Ask Sahil or Vidha what the website's next real feature is — most of what's left is genuinely up for grabs.
- Improve this guide specifically. It lives in
resources/git-guide/, and if any chapter was unclear to you, that unclarity is a real, fixable PR — you just proved you know exactly how to make one. - Offer to run a session for the next intake, the way Vidha ran hers. You have more to teach than you think you do.
Read git-scm.com/docs when you need the exact reference for a command. Read docs.github.com for platform features that keep evolving faster than any guide can promise to track. And when something feels uncertain mid-task — it always, still, starts with git status.