摘要

  • W3C Strategy issue 566 将 LWS 工作列为现有工作组续期，预计 10 月 15 日结束细化，并称没有实质变更。
  • 该议题同时承认原章程“过于乐观”，把新目标写成 2026 年第四季度或 2027 年第一季度进入 CR，之后转入维护；这仍需在章程中澄清。
  • 原章程曾把 CR、Proposed Recommendation 与 Recommendation 分别排在 2026 年 3 月、6 月和 9 月。当前公开文档仍列在 Working Drafts 下，这只是成熟度事实，不是失败判决。
  • 8 月 5 日的冻结草案仍有五个 [Q1–4 YYYY]、成熟度“二选一”、虚拟交付物、通用时间线与未定的会议/沟通选项。
  • W3C 应在 Advisory Committee 审议前，为实际送审提交发布就绪回执，逐项说明终点、日期、维护主体及所有模板标记的处置。

“范围不变”不等于“文档已经就绪”

Issue 566 的两句话需要分开读。“无实质变更”可以准确描述技术使命与五项规范家族没有被重写；“原章程过于乐观”则说明生命周期计划已经改变。前者回答做什么，后者回答做到哪个成熟阶段、何时完成，以及之后谁能以何种权限维护。

现行章程有效期为 2024 年 9 月 9 日至 2026 年 9 月 8 日。它原定核心协议在 2026 年 3 月进入 CR，6 月进入 Proposed Recommendation，9 月成为 Recommendation，并以两套独立可互操作实现作为继续推进的预期条件。章程历史页把这份有效文件与后续提案分开呈现。

截至证据截止，LWS 发布页仍把相关文档列为 Working Drafts，核心协议也是 Working Draft。公开时间表与公开成熟度之间确有差距，但它不解释原因，也不能证明实现不足或未来无法进入 CR。可得出的结论只有一个：续期文件需要新的、明确的生命周期说明。

不可变提交里仍有真正的选择题

公开仓库在 8 月 3 日留下由 charter assistant 生成的初始提交，8 月 5 日又有一笔删除协调对象的修改。因此应以第二笔提交中的不可变文件为证据，而不是只看会继续变化的渲染页。

文件中的起止日期仍是括号提示；0.1 FTE 被标成待办；电话会议可以是“按主题召开”或“其他”；沟通段落要求从邮件列表与 GitHub issues 中选择一项或两项。更关键的是交付物前言仍写着 Choose one：一条路径把“预计完成”指向 Recommendation 或稳定状态，另一条明确写只发布 Candidate Recommendation Snapshots、不打算推进到 Recommendation。

五项规范的预计完成时间全部是 [Q1–4 YYYY]。暂定交付物中还有 Web [spec name]，时间线仍使用 FooML 与 BarML。成功标准一处要求“不走向 REC 时删除”，另一处要求“不走向 REC 时考虑加入”。这些标记未必对应尚未形成的内部意见；它们能证明的，是公开冻结文件尚未把 CR 后维护的意图写成一份自洽章程。

细化期开放，所以只能谈就绪状态

W3C Process要求 Team 在细化截止前启动 Advisory Committee 审议、放弃提案或延长细化。章程应说明交付物、可用的预计里程碑、会议与沟通机制等；章程采纳则是之后的 W3C Decision，获批后才发出 Call for Participation。

10 月 15 日在证据截止时尚未到来。8 月 5 日文件不一定是最终送审版，公开记录也不覆盖所有内部决定。因此，不能把模板痕迹写成程序违规；同样不能把草案写成已获授权的继任章程。

为 LWS 设计一份就绪回执

回执首先绑定实际送审的提交与细化状态，再列出续期起止日期。核心是一张五行表：每项规范当前状态、所选终点、目标季度或无法估算的负责人说明、适用的成功标准。

如果终点确为 CR 后维护，回执还应定义维护允许哪些改动、由谁决定后续发布、是否继续发布 Snapshot。另一张模板登记表逐项处理虚拟交付物、FooML/BarML 时间线、FTE 标记、会议与沟通选项，状态可以是“已在某提交解决”“有意保留”“不适用”或“由具名主体延期”，但不能默默消失。

最后，变更说明应明确：技术范围可能没有实质变化，时间表、成熟度终点与运行机制仍发生了变化。这样，“无实质变更”就不会替代它没有回答的问题。

这份回执不会强迫 LWS 成为 Recommendation，也不会把外部观察者变成 W3C 决策者。它只让被审议的命题可以复现。

来源