How Accelerate works
Months later, a new recruit asks you to explain the whole system in one sitting. You realize you actually can.
You're the one being asked now. A new General Member — this year's Ishaan — corners you after a meeting: "okay but like, what's actually going on with all this? Why is there a whole separate private repo? Why can some people push straight to main and others can't? Why does the Constitution keep getting mentioned?"
Six months ago you'd have had no answer beyond "that's just how it's set up." Now you realize you actually lived through every piece of it — you were there for the redesign conflict, the near-miss force-push, Anvesha's almost-leaked key. So you walk them through it, the same way it actually happened, compressed into one sitting.
"Why four repos, and why is one of them private?"
| Repo | What it's for | Visibility | Licence |
|---|---|---|---|
.github | Org-wide defaults: README, GOVERNANCE, Code of Conduct, CONTRIBUTING, SECURITY, the Constitution, issue & PR templates | Public | GPL-3.0 |
website | Everything you just spent twenty chapters building | Public | GPL-3.0 |
resources | This guide, Vidha's beginner track, learning material | Public | CC-BY-SA-4.0 |
records | Meeting minutes, the setup log, financial audit files | Private — Executive Board only | N/A |
".github is special," you explain. "GitHub itself treats a repo with that exact name as the org's fallback defaults — a Code of Conduct there covers every other repo automatically, so nobody has to copy it into website and resources separately and keep three copies in sync." And records is private for the same reason your own commits carry your name, Chapter 2's logbook lesson turned up to an org-wide scale — minutes, financial details, and internal decisions genuinely shouldn't be a search-engine-indexable public page.
"Why does the Constitution keep getting mentioned in commit messages and PR descriptions?"
Because the technical setup isn't arbitrary — nearly every rule you've learned traces back to an actual article:
| What you've been living with | Which article requires it |
|---|---|
| Four teams matching four membership tiers | Article IV |
| PR + review required before merging to main | Article XIV.3(e) |
| Squash for solo PRs, merge commit for co-authored ones | Article XIV.3(e) — authorship preservation |
| Rebase-merge disabled org-wide | Same clause — no silently rewritten hashes on landed history |
records private, Board-only | Article II.2.3 (5-year minutes retention) + Article XV (data protection) |
| The setup log itself, never edited, only appended to | Article VIII.2(d) — the audit trail requirement |
"That last one," you tell them, "is the exact same idea Chapter 6 taught you about git revert. The Constitution doesn't let the club quietly rewrite what actually happened — it makes you append a correction instead. Once you've internalized that as a Git habit, the governance rule isn't a separate thing to memorize. It's the same instinct, applied to a different kind of record."
"Why can some people push straight to main and I can't?"
Team membership, mapped directly onto GitHub access — the same structure from Chapter 15, now with names attached:
| Team | Who | Access |
|---|---|---|
executive-board | The 8 elected officers | Admin on all 4 repos, including records |
core-committee | Appointed specialists — this is Vidha and Sahil's tier | Write on the 3 public repos |
junior-working-team | Recruited builders — Rachit and Anvesha started here | Write on the 3 public repos |
general-members | Enrolled students — where Ishaan started, where your new recruit is now | No direct grant — contribute through fork + PR, exactly like Chapter 11 |
"Notice," you add, "that being an org member at all grants you nothing by itself — base permission is set to none. Every single access right anyone has traces back to an explicit team grant. That's not an accident, and it's not distrust either — it's Chapter 20's whole point: nothing works by default, everything works because someone deliberately turned it on."
"Who's actually in charge of the GitHub org itself?"
Two people hold the Owner role — the highest level, capable of deleting the org outright: the President and the Project Director. Everyone else on the Board operates with full day-to-day control through the executive-board team's admin grant, without needing Owner. Fewer Owners means a compromised account or a moment of carelessness has a smaller blast radius — the same "smallest necessary access" instinct as Anvesha's near-miss with the Mailgun key.
"What actually happens if I want to help?"
Exactly what happened to Ishaan, chapter by chapter: pick an issue, fork if you don't have write access yet, branch, commit with a real message, push, open a PR, respond to review, get merged, watch it deploy automatically within minutes. Nothing about that process is different for you than it was for him — and it's the entire subject of the next, final chapter, except this time you're doing it yourself, start to finish, on something real.
The map, all in one place
- The Dashboard — a single self-contained page,
Dashboard/index.html, that pulls live data straight from the GitHub API — every repo, PR, issue, member, and team — into one view for whoever's directing projects. With a properly scoped token, it can push meeting minutes and calendar entries directly intorecords/. Runs locally; ask a Board member for a copy. - The Discord bridge — the Board's private channel is wired to receive every commit landing in
records, so a minutes push from the dashboard shows up there within seconds. The public build channel gets PR and issue activity fromwebsiteandresources. - This guide — living in
resources/git-guide/, which means if any of it ever goes stale or unclear, fixing it is itself a completely normal PR, following the exact same path as everything else in this chapter.