Where Do Decisions Go to Die? Auditing the Graveyards of Open-Source Governance

Every substantial open-source project has a place where its real history lives, and it is almost never the documentation. It is a four-hundred-comment GitHub thread titled something like [RFC] Reworking the plugin lifecycle, last touched on a Tuesday in March by someone who no longer works on the project. Buried somewhere in that thread is a decision that affects every contributor who arrives after it — and no practical way to find it.

The problem is not that projects deliberate in public. Most do, and that is genuinely better than the alternative. The problem is that public deliberation, once concluded, is treated as exhaust. The thread is closed, the outcome is merged into a commit message, and the reasoning — the part that explains why — evaporates. Six months later, a new contributor proposes the exact same idea, gets linked to the thread, and is told to "read the discussion." They do not read the discussion. Nobody would.

The Scroll-Depth Problem

Decision-making in open source follows a predictable sedimentation pattern. The first twenty comments contain the original proposal and the sharpest objections. Comments forty through two hundred are clarifications, scope arguments, and one recurring tangent about Windows path handling. Somewhere around comment three hundred, a maintainer posts a terse "going to move forward with option B, thanks everyone." That comment is the decision. It is also, statistically, the least discoverable artifact in the entire repository.

Contrast this with how the same projects treat code. We version it, we review it, we write tests against it, we maintain changelogs. A decision that took six weeks of volunteer energy gets a URL and a closed tab. The asymmetry is striking once you notice it.

Some projects have tried to fix this with ADRs — architecture decision records. The pattern is sound: a numbered file, a status field, a context section, a decision, and consequences. But ADRs fail in practice when they become a separate, parallel universe that drifts from the discussion that produced them. The record says option B was chosen for performance reasons; the thread reveals it was chosen because option A required a maintainer to take on a maintenance burden nobody volunteered for. Context loss is not a bug in the thread model — it is the thing threads are actually good at preserving.

Treat the Thread Like a Release Artifact

Here is the argument worth making: a governance thread is a release artifact, and it should be managed like one. That means three things.

First, outcomes need status labels, not just closes. A thread that ends with a decision should be tagged decided, with the resolution pinned or linked in the opening post. A thread that stalled should be tagged stalled, not silently abandoned. Ambiguity about whether a decision was made is more corrosive than the decision itself. Contributors re-litigate settled questions not because they are lazy, but because the project never marked the question as settled.

Second, produce digests. A maintainer or a bot should be able to generate a summary at thread close: the proposal, the top three objections, the chosen outcome, and the dissent that was acknowledged but overruled. That last item matters more than it sounds. Preserving recorded dissent tells future contributors that disagreement was heard, which makes them more willing to disagree productively the next time. Projects that flatten every debate into a unanimous verdict are training their contributors not to speak.

Third, make it searchable. This is the piece most projects skip. Decision records scattered across issues, mailing list archives, Discord threads, and a private Slack channel are functionally invisible. If your project's governance genuinely happens partly in Slack — and for most mid-sized projects it does — then the honest move is either to move it back into the public tracker or to publish digests of what was decided there. "It was discussed internally" is the open-source equivalent of a voicemail from a lawyer: everyone knows what it means, and nobody likes it.

A Minimal RFC Template That Respects People's Time

The fix does not require process bureaucracy. A workable RFC template needs exactly five sections:

1. Summary — two sentences, written last, placed first.
2. Motivation — the problem, stated without the solution smuggled in.
3. Alternatives considered — including the status quo, argued honestly.
4. Decision log — a running, dated list appended as the discussion evolves. "2024-03-12: Scoped down to exclude plugins after objection from @maintainer."
5. Outcome — filled in at close, with a link to the digest.

The decision log is the load-bearing wall. It converts a linear comment stream into an append-only record, which means a newcomer can read five dated entries instead of four hundred comments. It also creates a mild social incentive toward clarity: people write better comments when they know someone will have to summarize them.

Governance Is Developer Experience

It is tempting to file this under "community management," a category most engineering teams treat as adjacent to their actual work. That framing is wrong. A contributor's experience of your decision-making process is their experience of your project. A brilliant codebase with illegible governance will lose contributors to a mediocre codebase with legible governance, every time, because contributors can live with your trade-offs but not with your silence.

The town hall metaphor in this piece's original brief is instructive precisely because it is wrong. Town halls work because everyone in the room sees the vote happen. Open-source threads are more like a zoning hearing whose minutes were never filed. The deliberation was public; the record was not.

Projects that survive their own growth — and the Asterix Project's own RFC process has stumbled through versions of this — are the ones that eventually admit a simple truth: the discussion was never the deliverable. The durable, findable, honest record of what was decided, by whom, over whose objection — that is the deliverable. Everything else is sediment.