Every long GitHub issue thread ends the same way. Not with a decision — with a comment that refers to one:
Per our offline discussion, we're going with option B. Closing this out.
Sixteen people followed that thread. They read the proposal, weighed in on the caching layer, argued about the migration window. Then the actual decision happened somewhere else — a hallway, a huddle, a DM — and the thread got a postcard from it.
Nobody knows why option B won. The people who pushed for option A don't know whether their objection was answered or just outlasted. Six months from now, someone will read this thread top to bottom looking for the reasoning, and it won't be there, because it was never written down anywhere.
"Per our offline discussion" is an admission of failure. It says: this thread was supposed to produce a decision, it couldn't, so we abandoned the format and went back to talking. The written record — the entire point of doing this in an issue — is the casualty.
This isn't a discipline problem. It's a format problem, and it has a predictable shape.
Thread rot
Every decision thread decays through the same four phases:
Comments 1–5: signal. Someone clarifies the problem, someone proposes a solution, someone asks a genuinely good question. If threads stayed like this, nothing else in this post would need to exist.
Comments 6–15: branching. Three sub-conversations start. Someone responds to comment #3, but you can't tell, because GitHub comments are flat. A tangential concern arrives and takes root. The original question is still open, but now it has company.
Comments 16–30: drift. Half the comments debate implementation details of a solution nobody has agreed to. Someone new joins and re-asks comment #4's question. Someone posts a wall of text that addresses everything and resolves nothing.
Comments 30+: archaeology. A first-time reader now needs twenty minutes to reconstruct the state of the argument. Almost nobody invests that. They skim, get it slightly wrong, and either stay silent or add a comment that restarts a settled debate.
Somewhere past comment 30, the people who actually have to decide give up on the thread and book a call. Hence the postcard.
This happens to the best-run projects in software
You might think thread rot is a symptom of a sloppy team. The public record says otherwise.
Rust runs one of the most mature RFC processes in existence, and RFC 2005 (match ergonomics) still racked up over 300 comments. Rust's response was institutional: they invented the "Final Comment Period" — a formal mechanism whose entire job is to force an ending on threads that can no longer end themselves. When a project has to build an escape hatch from its own comment sections, the format is the problem.
Go's try proposal drew hundreds of comments in a matter of weeks — enough that the team had to ask people to stop posting "me too" reactions, and the signal had to be manually distilled out of the noise before the proposal was withdrawn.
These are disciplined teams with written processes, dedicated shepherds, and years of practice. If they can't keep a flat comment thread coherent, your team won't either. Stop blaming your team.
Why flat threads can't produce decisions
Three structural reasons:
Questions and answers aren't separable. A thread interleaves proposals, pushback, tangents, +1s, and emoji into one chronological stream. There is no view that shows "here are the three open questions, and here's what each person said about each one." If you want that view, you build it by hand, in your head, every time you read the thread.
There's no mechanism for a directed ask. "Thoughts? cc @team" is a broadcast, not a request. People engage with whatever catches their eye — which is reliably the most arguable detail, not the load-bearing question. The thing the author needs decided is exactly the thing the thread avoids.
Threads are open-ended by default. No review period, no deadline, no forcing function. The thread grows at the speed of whoever happens to notice it, and "resolved" is a state it can only reach by exhaustion.
What a decision actually needs
Not better threading. Structure:
- Specific questions with bounded answers — "option A or B for the caching layer?", not "what do you think?" (There's a whole method for writing these; we wrote it up in how to ask questions that can't be brushed off.)
- Questions placed next to their context — the schema question right after the schema section, not at the bottom of a five-page issue.
- Named reviewers, asked individually, with a reason their perspective matters. Not @team.
- Responses organized by question, not by timestamp — every answer to question 1 in one view.
- A deadline, so the thread has an ending built in instead of bolted on.
GitHub gives you none of this, which is why "per our offline discussion" exists. (It's also why GitHub Discussions doesn't fix it — same flat thread, different tab.)
Keep the issue. Replace the thread.
The issue is the right home for the proposal — version-controlled, linked to the repo, visible to the team. It's only the feedback layer that's broken.
That's the layer Inkling replaces. Paste the issue URL, embed questions inline next to the sections they're about, and send scoped links to the people whose input you need. They read the proposal, answer each question in the flow of reading, and the responses come back organized by question — with a summary posted back to the issue thread.
The thread still exists for general discussion. But the decision gets made in writing, in structure, on a deadline — so nobody has to write the postcard.