摘要

  • W3C团队于8月10日启动沉浸式Web工作组新章程草案的细化程序，邀请公众在strategy第564号问题中讨论，同时允许会员在w3c-ac-forum保密列表中讨论。
  • W3C《流程文件》第4.2节要求，所有针对章程草案提出的问题都必须得到正式处理，其解决状态要进入意见处置记录，并标出未能通过共识解决的问题。
  • 公开线程已经展示了可核验链条：安全审查者提出阻断性措辞问题，回应者提交PR 862，并说明合并后才满足关闭条件；APA的问题得到答复并产生PR 865。截至8月30日，两项PR都仍未合并。
  • 保密本身不是缺陷。《流程文件》第7.2与7.3节要求保护会员专属信息，也允许获授权者制作不署名、但足以传达必要信息的公开版本。
  • 共同处置表应记录问题类别、所涉章程版本和条款、回应、公开差异或不修改理由、共识状态、下一权力步骤与替代历史；它不应公开姓名、原文、投稿数量或可反向识别会员的商业细节。
  • 公开参与贡献的是事实、专业判断和异议，不是咨询委员会投票，更不是抽象的“公众授权”。细化共识、团队决定、后续AC审议和W3C决定必须保持分层。

两个入口不是两套章程程序

8月10日的启动通知把路径写得很清楚。任何人都能进入公开的GitHub问题，W3C会员还可以在会员专属列表上讨论。通知为整个细化阶段指定同一位Chartering Facilitator，并把预计结束时间放在9月7日前后。也就是说，通道不同，制度对象却只有一份：拟议中的沉浸式Web工作组章程。

公开通道的优势是可核查。审查者能指向具体行，维护者能给出pull request，后来的读者也能重建文本变化。保密通道则可能承载不能随意公开的材料，例如尚未发布的实现计划、合同限制、商业依赖，或一旦署名就会改变谈判关系的判断。

因此，本文不把会员保密列表写成“幕后渠道”，也不把GitHub写成装饰性参与。制度难点不在于二选一，而在于两条输入怎样进入同一个处置状态。公众无须知道保密意见的原文，却有正当理由知道：是否有某类问题触及某一条款，由谁作出回应，文本是否改变，若未改变理由是什么，问题又在何种程序状态下关闭。

需要汇合的是状态，不是内容。原始通信继续服从各自的访问规则，章程的公共谱系则应当保持连续。

公开线程已经给出了一条样板链

第564号问题不是最终处置报告，但它展示了处置表应保存的颗粒度。

安全审查者发现，草案要求每份规范包含说明安全与隐私影响的“若干部分”，而当时的章程模板使用的是“相互独立的部分”。审查者明确把它称为阻断性意见，并给出关闭条件。回应者承认不一致，提交PR 862，还另行指向有关跨规范安全与隐私文档的讨论。审查者随后确认，该PR处理了阻断点，但须在合并后才视为解决。

这条链至少包含四个状态：提出问题、给出回应、形成拟议差异、满足关闭条件。截止时PR 862仍是open且未合并，所以“已经有修复”不能写成“问题已经关闭”；反过来，也不能说意见被忽略。

APA审查的结构不同。它询问平面与网格检测是否重叠，WebGPU绑定的时间表怎样对应实现进度以及WebGL是否继续支持，CSS Spatial Layout与触觉工作为何出现在协作段落而不是交付物中。回应者解释边界，并以PR 865修改若干描述。APA后来表示答复与PR已经回应那些问题，随后又提出“detection”“tracking”“sensing”等命名是否一致的新问题。

这不能压缩成一句“APA同意”或“APA反对”。有的问题得到答复，有的拟议文字仍未合并，另一个命名问题继续存在。总问题的开关状态太粗，处置表需要追踪内部问题类别。

同样，公开页面显示的14条评论没有代表性含义。一条评论可以包含五个问题，多人也可能围绕同一措辞往返。沉默可能意味着赞同、弃权、未注意或无权决定。评论数不是票数，处置记录应统计状态，而不是从活跃度制造授权。

《流程文件》要求的是处置，而不是热度

W3C章程细化有明确顺序。团队发起程序时要公开草案，说明参与方法，给出不少于28天的预期周期，并指定主持细化的负责人。细化期间要完成广泛审查；Chartering Facilitator在参与者之间寻求共识，并据此作出决定。找不到共识时，可以请求W3C团队作出Team Decision，而且必须记录理由。

与本案最直接相关的要求是：所有针对草案提出的问题都必须得到正式处理，其解决方案要在意见处置记录中追踪，并突出显示未能通过共识解决的问题。

这比“有人讨论过”更严格，因为它要求把输入连到回应和解决状态；但它又没有要求公开所有收到的文字。《流程文件》在要求处置的同时，并未取消自己设立的保密等级。

细化期限届满前，团队必须在三种路径中选择：启动咨询委员会审议、放弃提案，或延长细化期。决定要按规定公开；若不启动AC审议，还要说明理由。这个结束动作应当成为处置表的下一状态，不能倒过来改写此前的问题历史。

AC审议又是另一种制度工具。每个会员组织由其AC代表提交一份审议，届时的持续反对必须以Formal Objection表达。细化期的GitHub评论不是这张会员审议票，保密列表上的一句意见也不自动等于后来的正式反对。把所有表达都称为“投票”，会抹平制度刻意保留的权力差异。

公开状态索引不必突破保密边界

W3C把信息分为公开、会员专属和团队专属。获准接触受限信息的人必须保密，不得向公众或超出指定范围的对象释放。因此，任何要求复制邮件、公布作者，或用细节丰富的转述让人猜出身份的方案，本身就是不合格的治理设计。

但保密不等于决策路径必须不可见。第7.3节指出，对具有显著公共成分的程序，影响决策的信息可能需要公开。只有团队或获得团队授权者才能改变保密等级；若原作者没有提供可公开版本，团队可以制作一个不署名、合理传达所需信息，同时尊重原保密等级的版本。

由此可以建立一个很窄的公共层。例如：“会员专属问题类别M-03：拟议交付物的范围边界。”公开表格可标明它触及哪一版草案的哪一节，是否引发公开文本改动，当前处置是什么。它无须说明哪家会员提出、有多少会员参与、哪款产品受到影响，更不能引用受限列表中的一句原话。

有时连问题类别都会暴露身份。那就应退回到可以安全披露的最低程序状态，而不是假装“汇总”之后便没有泄密风险。公共记录宁可少写，也不能猜写。

本文并不知道该章程的会员保密列表上是否真的出现过意见。通知说“可以使用”不等于“已经有人使用”。共同处置表应在获得授权的事实基础上工作，不能为了形式完整虚构一条保密问题。

参与的价值来自证据，不来自虚构的主权

公开入口之所以重要，是因为有效意见可能来自工作组之外。《流程文件》要求各组考虑来自活跃参与者以及其他组织和公众的正当观点与反对。安全、隐私、无障碍、国际化或架构专家都可能指出草案里的真实缺口；实现者也能识别不现实的里程碑。

然而，提供专业判断并不会把审查者变成委托人。意见的力量来自理由、证据和它所暴露的后果，不是因为“利益相关方”四个字产生了可执行权力。

权力仍有清楚归属。细化阶段由Chartering Facilitator寻找并判断参与者的共识；团队负责《流程文件》分配给它的决定，并选择提案进入AC审议、延期或终止；后续咨询委员会按每个会员一份审议的机制工作；最终形成W3C Decision。

一份好的处置表，会在适合公开时记录意见来源，却必须始终记录由哪个角色回应、由哪个权力状态关闭。这样既不会因为公众没有投票权就把审查看成表演，也不会因为参与公开就把它夸大为无边界的公众授权。

一张跨渠道处置表应当写什么

共同层应当比任何一条讨论渠道都薄。它是状态索引，不是第二个辩论存档。

每个问题或可安全公开的问题类别至少需要：

  1. 不随标题改变的稳定编号；
  2. 来源类别：公开或会员专属，但不暴露受限贡献者身份和数量；
  3. 可以公开的问题摘要；
  4. 被审查的章程版本、commit与具体条款；
  5. 回应角色和日期；
  6. 公开PR、差异或替代文本，若不修改则给出理由；
  7. 接受、部分接受、不修改、被替代、撤回、延期或未解决等处置；
  8. 是否通过共识解决，以及《流程文件》要求披露的未达共识状态；
  9. 下一权力步骤：继续细化、Team Decision、AC审议、延期或放弃；
  10. 关闭时间、替代事件与纠错历史。

来源类别不是权重。会员专属不必然比一条技术上决定性的公开审查更有权威，公开也不意味着更具代表性。渠道说明的是保管与访问，决定的强弱要看理由和获得授权的程序。

固定版本尤其重要。PR 862只有真正进入那一版推进中的章程，才满足审查者给出的条件。open补丁不等于merged文本，merged文本也不等于已经批准的章程。把版本写入处置表，才能避免三个状态互相冒充。

这项发现的边界

证据截止时，第564号问题与两项PR仍然open，章程仍处于细化中的草案阶段。W3C小组页面显示，工作组仍在现行章程下运行，期限到9月25日。

这些事实不证明延误、违规或技术质量不足。细化阶段本来就应当出现评论、未决补丁和占位符。9月7日也是估计日期，《流程文件》允许正式宣布延长。本文发布后状态可能变化。

关联到privacy名录条目只表示本文讨论的保密边界；它不把该条目认定为W3C、沉浸式Web工作组或WebXR，也不表示任何一方认可本文。

建议很克制：保留两条意见入口，守住各自访问规则，同时公开足以让同一份章程的处置谱系接受检查的最小状态。

来源

  1. W3C：启动沉浸式Web工作组章程草案细化，2026年8月10日
  2. W3C：沉浸式Web工作组章程草案
  3. w3c/strategy第564号问题：Immersive Web WG 2026 Group Charter
  4. w3c/charter-drafts PR 831：2026年IWWG初始章程草案
  5. w3c/charter-drafts PR 862：使协作措辞与模板一致
  6. w3c/charter-drafts PR 865：使规范描述与摘要一致
  7. W3C《流程文件》，2025年8月18日
  8. W3C：沉浸式Web工作组
  9. W3C：2024年9月现行沉浸式Web工作组章程
  10. w3c/charter-drafts：2026年草案commit历史
  11. w3c/charter-drafts commit 488587ec141b：标注DRAFT
  12. W3C：Horizontal Review指南
  13. Heng Lu：On the Multi-Stakeholder Mirage
  14. Heng Lu：On the Reality Layers of Internet Governance