Issue #412 is at ninety-one comments. Around comment 12 somebody laid out the real tradeoff clearly and nobody quoted it. Comments 40 through 70 are three people relitigating that tradeoff without having read it. The four downstream maintainers whose packages break if you pick wrong have not commented, because they do not watch your tracker. It is Sunday night, you are the only person with merge rights, and you are about to ship the option you have the least energy left to defend.
Then the release goes out and someone opens a new issue: "Why was this changed?"
Why the thread format loses the decision
A thread is read newest-first. Your framing scrolls away by the third screenful, and many trackers collapse the middle of a long discussion outright. Someone arriving at comment 71 sees the title and the last five comments, so that is what they answer. Restating comment 12 is not laziness; it is what the interface produces.
Participation is self-selected by who watches the repository, a population skewed toward people who enjoy discussing the project. The packager, the team pinned to your last release, and the plugin author with two hundred users are not in it. You sample one group and bill another.
Then exhaustion decides. You pick alone because you ran out of energy to keep the thread coherent, which leaves no record of why — exactly what makes it relitigable at release.
Put the decision and the deadline at the top, and keep editing it
The opening post is the only stable surface in a thread; everything else moves. Treat it as a living document, not as your opening argument.
Four things belong in it: the decision in one sentence, the options as a closed list, the deadline with a stated default, and a "state of the thread as of comment N" line you actually maintain. When a genuinely new consideration lands at comment 45, edit it in and say that you did. That kills the restate-comment-12 problem, because the first thing a newcomer clicks is the top post.
Make the deadline mean something: "Decision on the 14th; absent a blocking objection I merge B." A deadline that names its default is real; one without is a wish, and people learn to ignore the next ten.
Enumerate the options before you open the floor
"Thoughts on how we should handle plugin versioning?" invites twelve designs and produces no decision.
Do the enumeration yourself: two to four named options, each with the cost attached — who changes code, what breaks silently versus loudly, whose maintenance burden goes up. Then open the floor to critique the enumeration rather than replace it. A fifth option is a good outcome; edit it into the top post with its tradeoffs. You have turned an open discussion into a bounded review of a document.
If you do not know the option space yet, say so and run that as its own thread. The mechanics — closed lists, a recommendation with a disconfirmer, facts labelled apart from guesses — are in how to ask for a decision and transfer to a tracker unchanged. A critique of one approach rather than a pick between several is a design review, a different shape.
Consultation theatre, and how to avoid being accused of it
Three requests look identical in an issue thread, and mislabelling one for another is how maintainers lose contributors:
- "I want opinions." The option space or the weighting is open, and a good argument changes the outcome.
- "I want a veto check." You have picked; you are asking whether anyone knows a concrete reason it breaks.
- "I have decided, I am flagging it." Notice, so nobody is surprised at release.
Most damage comes from labelling a veto check as a request for opinions: you invite a redesign, reject it, and the contributor who spent an evening on it reasonably concludes you were never listening. The inverse is worse — consultation theatre, where the thread exists to legitimise a settled call. People detect that and stop showing up.
Naming the ask also says what a sufficient reply looks like. "No objection" answers a veto check completely, and saying so out loud is what makes short replies possible; the reply is the point, not the discussion.
Ask the specific people, don't broadcast at them
Publishing an issue means anyone may respond. It does not mean the person who should respond will. If the change breaks four downstream projects, name those four maintainers and ask them.
What a direct ask needs, and a link does not supply, is the context attached. "See #412" bills the reader ten minutes of archaeology, and they will do it badly or not at all. Send the state of the question, not a pointer to it.
This is the one place in project governance where a briefing beats a link: a scoped question with 150 to 400 words of cold-reader context, the options and their tradeoffs, your recommendation and an honest deadline — your top post, addressed to one person instead of a tracker. If you already worked the tradeoff through with an assistant, it can compose that briefing from the private session, you review the exact package before it sends, and your read of what breaks is labelled as inference rather than fact. The recipient needs no account: it arrives as email with a reply box, and the reply lands on your thread. Reaching someone new is hard-capped per day and carries a one-click unsubscribe that blocks you permanently — the right posture for mailing a stranger whose only tie to you is that they depend on your package.
What this does not replace
Public deliberation earns its cost, and a private briefing does not substitute for it. The thread is the archive, and the archive is most of what governance means in a project without a payroll. It also lets someone you would never have thought to ask surface the objection that decides the thing — not a side effect, the main mechanism. Route every decision to three private inboxes and you have built a cabal with a git remote.
So keep the thread and maintain the top post. Run targeted asks alongside it and post the answers back with attribution, so the record stays complete. The private ask reaches the people the thread structurally cannot.
If that is the half you keep skipping because writing it out costs an evening you do not have, connect your assistant to draft the package from the session you already ran.