W3C 申诉选票写着“批准”，通过后却推翻决定

摘要

• 2025 年 8 月 18 日生效的 W3C 现行《流程文件》第 5.9 节问：“Do you approve of the Decision?”，可选答案为 Approve、Reject 和 Abstain。
• 同一节规定，Approve 票按参与率对应的比例超过 Reject 票时，咨询委员会申诉表决通过；下一句却说，表决通过后决定被推翻。逐字执行，便会得到“更多人批准决定，所以决定被撤销”的结果。
• 2023 年版的逻辑是连贯的：Reject 多于 Approve 时，决定被推翻。公开的 pull request 901 把这一规则换成以 Approve 为胜出方的分级门槛，却没有同步改写提问对象和通过后的后果。
• 分级门槛本身有合理目的：参与率低于 5% 时表决失败；5% 至 15% 时须严格超过三比一；高于 15% 且低于 20% 时须严格超过二比一；达到 20% 后只须简单领先。明确投出的弃权票计入参与率。
• 公开修订理由是借鉴 W3C 章程的 Requisite Member Vote，防止少量参与者凭微弱多数推翻重大决定；没有任何公开说明宣告 Approve 的语义从“批准原决定”改为“批准申诉”。
• 本文审阅的公开证据不能证明 W3C 已按这段文字实际举行过申诉投票，也不能证明选票曾被错误配置、结果曾被误计，或某项决定因此被错误维持或推翻。
• W3C 应在投票开放前公开由实际配置生成的一致性记录，列明完整问题、每个选项所指对象、合格成员分母、参与率区间、严格不等式、边界测试、汇总结果、决定状态、适用流程版本及更正历史。

申诉规则不能靠熟人猜意思

一般会议纪要里出现一个用词疏漏，参与者或许能凭上下文补齐含义。申诉规则不同。它恰恰在正常共识已经失灵、原决定受到挑战时才启动。此时，谁有权发起、谁能投票、哪一边需要达到多少票、通过后发生什么，都必须在同一条可执行链上。

现行第 5.9 节的前半段区分了几种权力。处于 Good Standing 状态的成员，其咨询委员会代表可在三周内对符合条件的决定提出申诉。W3C 团队随后在一周内公布申诉。若一周内至少有咨询委员会 5% 的成员明确支持该请求，才进入投票。

这个 5% 是受理门槛，不是实体结论。它说明有足够成员认为争议值得提交全体合格选民，却不代表决定已被否定，也不预告最后哪一方获胜。

真正的选票随后出现。规范原文明确问：“Do you approve of the Decision?” 它不是问是否批准申诉，也不是问是否批准推翻决定。回答标签是 Approve、Reject、Abstain。每个成员或相互关联的一组成员只有一票，只有 Good Standing 成员的代表计入第 5.9 节的选举范围。

接下来，参与率决定门槛高度。明确投出的 Abstain 票虽然不进入 Approve 与 Reject 的胜负比，却计入参与人数。参与率不足 5%，表决失败；从 5% 到 15%，Approve 必须严格大于 Reject 的三倍；高于 15% 而低于 20%，Approve 必须严格大于 Reject 的两倍；达到 20% 后，Approve 只需严格多于 Reject。

然后，条文立即规定：如果表决通过，原决定被推翻。

问题因此不再是“某个词听上去是否自然”，而是同一输入出现两个相反输出。若 Approve 承接问题中的 Decision，它表示维持决定；若 Approve 是让申诉通过的票，它又表示推翻决定。除非悄悄改变其中一个词所指的对象，否则四个环节无法同时成立。

把数字放进去，矛盾就会显形

假设参与率达到或超过 20%，Approve 为 12 票，Reject 为 8 票。按现行公式，12 大于 8，表决通过；按下一句，原决定被推翻。可按选票问题的普通含义，12 位代表刚刚表示他们批准原决定。

把数字反过来：Approve 8 票，Reject 12 票。现行公式不通过，决定继续有效。结果是，更多代表对“是否批准决定”回答了 Reject，申诉却失败。

低参与率区间也会得到同样的倒置。Approve 16 票、Reject 5 票时，16 严格大于 15，因此申诉通过并推翻决定。Approve 15 票、Reject 5 票时则不通过，因为英文条款使用 exceeds，即必须“超过”，恰好三倍并不够。

这些数字只是规则测试，不是任何真实 W3C 投票的报告。它们把人名、立场和政治后果暂时拿走，只问一个基础问题：同样的文字被机械执行后，决定会进入什么状态？

弃权票又为这个状态机增加了第二个变量。它不改变 Approve 和 Reject 的票数，却能把参与率推入另一档，从而降低胜出方所需的倍数。两场拥有完全相同赞成与反对票的表决，可能因为明确弃权人数不同而采用不同公式。

所以，任何可核验记录都必须同时保存：合格成员的分母、参与人数、弃权数、两个决定性选项的票数、适用区间以及严格不等式。只公布“多数通过”或一个百分比，无法重做这项计算。

数学完全正确，并不能挽救一个指向错误对象的授权命题。

2023 年版提供了清楚的对照组

2023 年 11 月 3 日版《流程文件》使用相同的问题，也提供相同的三个选项。但它对结果的规定不同：Reject 票超过 Approve 票时，原决定被推翻。

那条链很短，却没有语义折返。Approve 批准原决定，Reject 拒绝原决定；更多 Reject 让申诉成功；申诉成功使决定失效。

旧规则的缺点是没有随参与率提高或降低胜出要求。修订者担心，若参与者只是全体成员中的很小一部分，一场 51 比 49 的微弱多数就可能推翻影响重大的决定。这个担心并非借口。让低参与率下的行动方证明更强的内部共识，是可辩护的治理选择。

公开的 pull request 901 恰好显示了改变发生在哪里。差异记录删除了“Reject 多于 Approve，决定被推翻”这一两步规则，插入按参与率分档、每一档都要求 Approve 压过 Reject 的新公式。其后的“表决通过即推翻决定”没有改变。前面的“是否批准该决定”也没有改变。

这份版本证据比猜测个别编辑者的动机更可靠。它证明被计算的一方换了，而提问对象与最终状态没有一起换。矛盾可以被定位到一处公开修订，不必把它包装成阴谋。

issue 886 和 pull request 的说明都把问题表述为：如何避免低参与率时凭微弱多数作出重大改变。W3C 对 2025 年新版流程的公告也只说，申诉投票在低参与率时采用更高门槛。没有一份审阅过的公开材料说，W3C 决定把“Approve”从批准原决定改成批准申诉，更没有说赞同原决定的一方应促成撤销。

因此，可以严格地说现行规范存在内部极性冲突；不能据此声称 W3C 有意颠倒结果。

章程里的肯定票，批准的是同一项行动

分级门槛并非凭空出现。W3C 章程第三条第 11 节为需要成员肯定授权的公司行动规定了 Requisite Member Vote。

当出席或被代表的成员不超过 15% 时，肯定票至少须达到 75%；参与率高于 15% 而低于 20% 时，至少须达到三分之二；参与率达到 20% 后，过半即可。

这套逻辑的治理目的很清楚：活跃者越少，行动方内部就要越一致；参与面越广，普通多数越能代表整体授权。缺席者不会自动变成反对票，小群体也不能轻易用一票之差支配重大行动。

但在章程的结构里，affirmative vote 批准的就是提交成员表决的公司行动。问题、肯定票和法律后果始终同向。

申诉选票可以有两种自洽写法。第一种问：“你是否批准原决定？”此时 Approve 表示维持，Reject 表示推翻，分级门槛应由 Reject 一方满足。第二种问：“你是否批准本申诉，或批准推翻该决定的动议？”此时 Approve 表示撤销，现有以 Approve 为核心的公式便可成立。

现行条文保留了第一种问题，却接入第二种公式。它移植了肯定票的高度，没有先确定肯定票究竟肯定哪项行动。

边界表达也不完全相同。章程所说“至少 75%”包括 15 比 5；流程所说“Approve 超过 Reject 的三倍”则不包括，因为 15 并未大于 15。如果制度只说“借鉴章程”，却不展示实际运算，最接近边界的结果仍可能引发争议。

最有力的辩护，仍不足以替代规范

替 W3C 作最强辩护，并不困难。所有参与者都知道这是申诉。发起者希望改变原决定。2023 年文本清楚地把 Reject 放在推翻一方。公开讨论聚焦于提高推翻门槛，而不是赋予支持决定者一种反常权力。一个熟悉背景的投票管理员很可能会在实际表单中改问“是否支持申诉”，或者把“维持决定”和“推翻决定”直接写在选项上。

规范源文件公开、可追溯，也能修正。当前 Editor’s Draft 仍重复相同文字，因此不存在找不到修订入口的问题。本文证据范围内，也没有发现某场真实投票受害、某个结果误计或某项决定因此失去合法性的事实。

这些都是重要限制。它们阻止分析越界，却没有使现行文字变得可执行。

制度记忆不是表决规则。负责配置表单的人不应自行判断 Approve 到底批准决定、批准申诉，还是批准撤销。若操作界面悄悄选定一种解释，再在结果公布后被当成规范“本来含义”的唯一证据，技术配置就取得了规范没有清楚授予的权力。

越是接近门槛的争议，这个问题越严重。失败一方会有动机主张另一种字面解释，胜出一方会有动机维护已经运行的配置。无需任何人恶意行动，事后解释的可信度也会自然下降。

申诉规则若只能在无人挑战它时保持清楚，就没有为真正需要它的场景做好准备。

支持申诉、参与表决、决定实体必须分开

最初的 5% 支持门槛与后续胜负不能混为一谈。发起者让机制启动；支持者让争议进入正式投票；全体合格选民在门槛下作出实体选择；W3C 团队负责公告和执行。原决定的作出者、工作组、实现者和其他依赖该决定的人承受最终后果。

这几种权力不是同一种代表关系。少数成员认为值得举行投票，不等于他们代表多数，也不等于他们已推翻决定。投票参与率说明有多少合格成员进入了过程，不自动说明哪项行动获得授权。

公开指南帮助申诉人识别决定并说明理由，但不取代第 5.9 节，也没有解决选票极性。支持声明档案只对成员开放，是一项可以理解的保密安排；它不要求 W3C 连汇总计算也保持不透明。

在不公开任何个人选择的前提下，W3C 完全可以公布合格分母、总参与数、明确弃权数、Approve 与 Reject 的汇总票数、应用的公式和原决定的新状态。个体投票隐私与集体授权透明并不冲突。

Heng Lu 对多利益相关方治理的批评在这里提供了一条纪律：参与能产生证据，也能在明确规则内形成授权；它不能凭人数本身制造委托人、议题或后果。门槛回答“多少票”，却不能替选票回答“这些票批准什么”。

从真实选票配置生成一致性记录

W3C 应为每次咨询委员会申诉建立“选票极性一致性记录”，并在开放投票前公布。记录必须由生成实际选票的同一份配置产出，而不是在结果出来后另写一篇解释。只有这样，公众所审阅的命题才与代表实际看到的命题一致。

记录至少应包括：

• 原决定的标识、标题、作出机关、公告时间和权威链接；
• 申诉标识、发起者资格状态及 5% 受理门槛的汇总结果；
• 控制该次投票的流程版本和准确章节；
• 未经改写的完整选票问题；
• 每个回答标签及其语义对象：原决定、申诉或撤销动议；
• 哪个选项维持决定、哪个选项可推翻决定的明确映射；
• Good Standing 合格成员分母及锁定分母的时间；
• 总参与人数和明确弃权人数；
• 适用参与率区间、公式以及相等是否足够；
• 每一处边界附近至少一个通过、一个失败的机器可检验例子；
• 最终汇总票数、具体运算和投票结果；
• 原决定最终是维持、推翻还是仍未解决；
• 任何更正、替代文本、临时解释和依赖该结果的后续行动；以及
• 哪些个人记录仍只限成员查阅的隐私说明。

这不是新增一个否决层级，也不是让工作人员通过元数据改写《流程文件》。它是一项一致性证明：问题、工具和状态变化必须在授权发生前指向同一方向。

提前公布还创造了低成本纠错窗口。如果问题写的是批准决定，而配置却把 Approve 连到推翻，代表可以在投票前提出异议。投票之后再改，争论的便不只是界面，而是已经投出的每张票究竟授权了什么。

两条修订路径，不替 W3C 代写法律文本

一种方案保留现行问题：“是否批准该决定？” Approve 继续表示维持决定；Reject 成为推动申诉的一方，因此分级公式改为 Reject 按参与率对应倍数超过 Approve。表决通过后推翻决定，语义便闭合。

另一种方案保留现行公式，把问题改为：“是否批准本申诉？”或“是否批准推翻该决定的动议？” Approve 直接表示支持撤销，达到门槛后推翻决定也同样闭合。

本文不替 W3C 选择最终法律措辞。定义术语、表决工具和机构惯例可能使其中一种更适合正式流程。本文只提出不可再退让的控制条件：approve 后面的对象、被公式计算的胜出方以及表决后的决定状态必须是同一项行动。

截至 2026 年 8 月 31 日，W3C 公布的 2025 年 8 月 18 日版仍是本文识别到的现行版本，当前 Editor’s Draft 也保留相同冲突。公开版本历史足以证明文字如何变化，却不足以证明任何现实误计票、故意操纵或既有决定失效。

发现一个规范缺口，并不需要先创造一个受害者。恰恰应在真实申诉出现之前修复它。

来源

1. W3C《流程文件》2025 年 8 月 18 日版，第 5.9 节
2. W3C《流程文件》当前 Editor’s Draft，第 5.9 节
3. W3C《流程文件》2023 年 11 月 3 日版，第 5.9 节
4. W3C Process pull request 901：按参与率设置分级门槛
5. pull request 901 中首次引入门槛的 commit
6. W3C Process issue 886：按参与率调整申诉门槛
7. W3C 公告：更新《流程文件》
8. W3C 指南：对 W3C 决定提出申诉
9. World Wide Web Consortium, Inc. 经修订及重述的章程
10. W3C Process issue 1034：咨询委员会申诉期限
11. 面向忙碌读者的 W3C 流程说明：咨询委员会申诉
12. Heng Lu：The Multi-Stakeholder Mirage
13. Heng Lu：On the Agency Problem at the Core of Internet Governance