C++26 Failed Its Ballot. Your Design Review Has the Same Bug.

Two numbers decided the fate of C++26, and neither of them is a line of code. The draft needed 14 votes in favor from the 20 national bodies that vote on ISO standards. It got 12. It was allowed at most five negative votes out of the 22 bodies that cast one. It got nine. Either miss would have been enough on its own, which means the most important C++ proposal in years failed twice, on the same day, by different arithmetic.

A DIS is a Draft International Standard: the stage in the ISO process where member countries vote yes, no, or abstain on a near-final text. For every C++ standard before this one, that vote was a formality. According to Daveed Vandevoorde of the WG21 direction group, no earlier C++ draft had ever received even a single vote against it. This one got nine.

What actually happened

The ballot closed on 23 October 2026, and the result was public the next day. Nine countries voted No. France and Ireland abstained but sent comments, so 11 bodies commented in total. Poland and the United States abstained without comment. The count is the story: two-thirds of 20 needs 14 votes in favor, and the draft got 12, which is 60%. A quarter of 22 permits five negative votes, and the draft got nine, which is 41%.

The author of the public post-mortem, a member of the Polish national body, is convinced the No votes were about contracts: the C++ feature that lets a function declare its preconditions and postconditions in the signature, checked by the compiler. It is a reasonable bet. The opposition was on record before the ballot, and a paper (P4238R1) had already asked national bodies to vote No over the contracts design and how it moved through committee. But the comments themselves are not published yet. ISO rules require a full report within 12 weeks, so the reasoning lands by mid-January 2027 at the latest.

Here is the part worth stealing for your own team: you cannot cleanly separate the verdict from the machinery that produced it. Whether contracts were good is a separate question from whether the process could hear the answer. The process could not, and that is a design flaw you probably share.

One threshold is a preference. Two is a system.

Two thresholds governed this ballot, and they measure different things. The two-thirds rule measures enthusiasm: do enough people actively want this? The cap on negative votes measures objection: is the opposition small enough that the rest of us can live with it? You can pass the first and fail the second, which is exactly what happened, and that is the point of having both.

Most engineering organizations run a diluted version of this without ever writing it down. The common pattern is "two approvals and no blocking objections," which sounds rigorous and is actually two undefined quantities. Approvals from whom? Out of how many eligible reviewers? What counts as a blocking objection, and who decides? When nobody writes the numbers down, the rule that gets applied is whatever the loudest person in the thread believes the rule to be.

Write yours as a sentence you can compute: "A decision passes if at least two-thirds of eligible reviewers approve and fewer than 25% of votes cast are No." Then go back and apply it to three decisions your team made last quarter. You will learn something uncomfortable about how many of them would have passed under a rule you actually wrote down.

Abstention is a decision, and often a silent one

Poland's path through this ballot is the most instructive detail in the whole story. Poland's position is set by a technical committee, KT 331, which held an internal ballot asking whether Poland should reject the DIS and attach technical comments. That internal vote did not pass. So Poland told ISO "Abstention" — and, because of how the two votes are coupled, no technical comments could travel with it.

Sit with that. A country with people who had read the draft closely enough to want to file comments ended up contributing nothing at all, because the mechanism for expressing partial disagreement did not exist. The only options were reject-with-comments or silence.

Your review process almost certainly has the same shape. Someone reads the design doc, sees a real problem, but does not think the problem is worth blocking the whole thing. So they write "looks fine to me, minor nit" or, more likely, nothing. Three weeks later the thing ships, and the objection surfaces in production. They were not wrong to abstain. You gave them no way to be half-right.

The fix is cheap: make "I have concerns that are not blocking" a first-class state in your review, and make those concerns publishable alongside the approval. A comment that rides along with a yes is worth more than a comment that kills a proposal.

Your voter roll is decaying right now

The part of the story that should genuinely worry you is the quorum. A few days before the Polish ballot closed, the committee was still short of the votes needed to have any position at all. Some members had changed jobs. Emails bounced, most likely because the addresses belonged to former employers. People had to be hunted down on LinkedIn to get a quorum.

The author's conclusion is blunt and correct: if you are on a national committee, vote, in whichever direction. If you can no longer participate, ask to be removed. An inactive member still counts toward the quorum, so a quiet member makes it harder for everyone else to reach one — in this ballot and every one after it. The committee office cannot simply remove someone who has gone silent. It depends on the member asking.

Now look at your own lists. The GitHub team with merge rights. The architecture review group. The on-call rota. The approvers in the deploy pipeline. Every one of them is a quorum with a decay rate. People leave, change teams, go on parental leave, quietly stop reading. Nobody prunes, because pruning is nobody's job and removing someone feels rude. Then a real decision arrives and you discover that four of your seven required approvers are unreachable, and the two who remain approve it because the release is on Thursday.

That is not a governance failure. That is a roster maintenance failure, which is easier to fix and almost never fixed.

A 20-minute audit of your decision rules

You do not need an ISO committee to apply this. You need one hour and the willingness to be embarrassed by the answers.

• Write the threshold and the quorum as two separate numbers. "Three of five approvers, and at least one from the platform team" is a rule. "Consensus" is a mood.
• Count abstentions explicitly. Report the denominator every time. "Approved 4-1" means something different when two people did not vote and nobody noticed.
• Separate "no position" from "no objection." If your tooling only records yes/no, half your reviewers are being silently converted into yeses.
• Prune the roster quarterly. One email per quarter: confirm you are still the right reviewer, or hand it to someone else. Remove non-responders. Yes, actually remove them.
• Publish the reasoning within a fixed window. The 12-week ISO deadline exists so that a failed vote produces learning instead of rumor. Your post-mortems should have the same clock.
• Decide what happens if the vote fails. C++26 now faces a delay of unknown length because no one wrote down the fallback. A rule without a failure branch is a rule that gets renegotiated under pressure.

Where this hurts, and where it is worth it

A two-thirds threshold with a cap on negatives is slow, and it is designed to be. It gives a motivated minority real leverage: nine of 22 bodies is 41%, and under these rules 41% is enough to stop a project. That is a feature when the decision is hard to reverse — a public API you cannot un-ship, a schema change that breaks stored data, a deletion path, a hiring bar. It is an expensive mistake when the decision is a two-way door you could undo in an afternoon.

So do not apply one rule to everything. Segment by reversibility. Reversible decisions: one owner, one reviewer, move. Irreversible decisions: supermajority, published comments, and a roster you trust. And be honest about which one you are actually making, because the most common failure is treating a one-way door like a two-way door and discovering the difference six months later.

The substance was probably fine

One more thing, because it matters to the argument. The case for contracts is not that they catch bugs, although they do. It is that a precondition in a signature is documentation that cannot quietly go stale. A comment can drift away from the code and nobody notices. A contract is checked by the compiler alongside the function, and when checks are enabled, a violation fails loudly. That is a genuinely good idea, and it is a shame it did not make this ballot.

But a good idea that cannot survive its own approval process is, organizationally, the same as a bad one. The mechanism is the product. If your team's decision rules turn abstention into consent, silence into approval, and quorum into an accident, it does not matter how good your ideas are. You will find out the answer months later, in production, with no comments attached.

Key Takeaways

• C++26 became the first C++ draft to fail an ISO ballot, missing both thresholds: 12 of 20 votes in favor against a 14-vote requirement, and 9 negative votes against a cap of 5. Either miss alone would have failed it.
• Two thresholds measure two different things — enthusiasm and objection. Write both of yours down as computable numbers, then re-score three recent decisions against them.
• Abstention is a decision. Poland abstained and, because of how its internal vote works, could attach no technical comments at all. If your process has no "concerns, not blocking" state, you are deleting the most useful feedback you get.
• Your reviewer lists, approver groups, and on-call rotas decay silently. A quorum almost vanished on a global standards ballot because people changed jobs. Prune quarterly, and ask people to remove themselves.
• A rule without a failure branch gets renegotiated under pressure. Decide now what happens when the vote does not pass — and match the strictness of the rule to how reversible the decision is.