摘要

  • CPC 章程规定，自 2026 年秋季选举周期起，分别由非 Impact 项目和 Regular Members 产生的投票代表，将改为最多五个 Community Voting Member 席位。
  • 观察会议、成为 Regular Member、属于选民范围和实际取得投票席位，是四种不同状态；新类别候选人必须是 Regular Member，且当时不能担任 Impact 项目的投票代表。
  • 过渡应有一份公开记录，分别载明旧席位结局、新席位、选民分母、资格、结果、雇主集中度与 Board、CPC、项目各自权限；它不应把尚未发生的选举写成既成事实，也不应把内部选举扩写为整个 JavaScript 生态的授权。

写进章程的未来，不等于已经形成的构成

开放源码组织常有一个容易被忽略的时间问题：规则文件可以先于规则的实际运行。章程修订可以公开，会议可以允许旁听，网站可以出现新类别的标题。这些都是有价值的事实，却仍无法回答最关键的问题：谁在什么日期，经由什么程序，真正取得了哪一种决定权？

OpenJS 的资料对结构描述得很清楚。CPC 是 Foundation 的技术领导机构；Board 是其业务领导机构。Board 制定 CPC 总体政策，CPC 在该范围内处理受委托的技术治理。章程同时规定，从 2026 年秋季选举周期开始，两类原本分开的非 Impact 投票路径将统一为 Community Voting Members。

这证明的是一项已宣布的制度变化，并不证明提名已开启、候选名单已核定、投票已经完成、五个席位都已产生，或任何特定人士已经就任。把未来时态的章程安排当成已完成的席位事实，是用预期替代证据。

过渡发生后，贡献者不应依靠熟人记忆来拼凑答案。某位原代表是任期结束、辞职、被替补、转为 Regular Member，还是竞逐新类别？最多五席中究竟填了几席？有资格投票的 Impact Project Voting Members 与 Regular Members 在当日各有多少？单一雇主不得超过全部 Voting Members 四分之一的限制，是按哪个完整分母计算？眼前的事项又究竟由 Board、CPC，还是某个自治项目决定？

这些不是对违规的暗示，而是让日后读者不把一张更新后的名单误读为无来源的权力移交所必需的字段。

“社区”一词中的四层身份

CPC 章程区分 Observers、Regular Members 和 Voting Members。CPC 的公开仓库说明，非成员可以作为观察者参加会议；治理文件则说明，一名具有近期、持续 OpenJS 活动的协作者可申请成为 Regular Member。新类别的选民范围更窄：Impact Project Voting Members 与 Regular Members 才是 Community Voting Member 选举的选民。

Observer 可以参与公开会议和共识形成。这是真实的参与，但不等于自动拥有投票资格或席位。

Regular Member 是更明确的组织身份。规则要求其在项目、社区、协作空间或 CPC 工作中具备近期持续活动，并经过既定审查。该身份既是新类别的候选条件，也属于选民范围；但它本身并不是当选证明。

Impact Project Voting Member 来自另一条路径：每个 Impact 项目可依自身程序提名最多两位代表。新结构保留这一类别。其成员参与社区投票，并不会抹掉自己席位的项目来源。

Community Voting Member 则是秋季周期拟启用的具体投票类别，最多五席。候选人必须为 Regular Member，且不能同时担任 Impact 项目的投票代表。因此，“社区投票了”这句话很容易压缩四个不同事实：谁旁听或参与讨论，谁已获 Regular Member 身份，谁在选民名单中，谁最终获得席位。章程预先说明前面的边界；后面的事实必须由当期选举记录证明。

这正适用卢恒《多利益相关方幻象》的证据纪律。参与能够带来专业知识、警告和异议，不会因其存在就产生对所有受影响者的本体授权。CPC 的公开会议与内部选举，是一个被定义的 Foundation 内部程序的证据；它们不是对整个 JavaScript 生态的普遍代表权证明。

新类别不会吞没既有权限

投票类别改变，不会自动重画所有机构权限。Voting Members 对章程赋予 CPC 的事项承担最终 CPC 决定责任；CPC 首先寻求惰性共识，在异议无法解决时使用规定的投票路径。Board 仍掌握总体政策、特别是法律方面的权限，并参与章程修改的批准。项目仍在 CPC 指引下保留自身记录明确的技术决策程序。

这些层级相互连接，但不可互换。CPC Director 可以向 Board 代表 Foundation 的项目和相关社区；项目章程可能需要 CPC 批准；技术事项也可能需要上升给 Board。可是 Community Voting Member 不会因此自动成为 Board 董事、全体维护者的代表，或某项目内部技术决策者。过渡记录应当写明实际持有的是哪一种身份。

现有治理已经留下多个记录面：提名期首日的公开 issue、选举后的 README 更新 pull request、发往私密列表的结果说明、议程和会议材料。规则同时承认人员、法律与部分 Board 信息存在合理的非公开边界。透明并不要求公开每一份私人档案；它要求能够连接决定性公共事实。

仅在 README 出现一个名字，仍不能说明任期、旧席位去向或选民分母。治理文件规定，刚结束任期的 Voting Member 通常会自动成为 Regular Member，除非本人另有表示；这是一条有用的默认安排，不是每个人离任状态的完整凭据。同样，“最多五席”不等于某一届实际填满五席；单一雇主四分之一限制也不能只靠名字列表复核，必须有当日完整人数和可审查的关联口径。

Community Voting Member 过渡记录

Daniel Kade 建议发布一份简洁的 Community Voting Member 过渡记录。它不重写章程，也不要求公开私人候选材料；它把原本散落在 issue、议程、名单和仓库更新中的关键事实接在一起。

第一项是 周期状态：计划过渡、提名开放、投票进行、结果确认或更正。它应链接控制性章程文字，明确旧类别与新类别，并避免把一项未来规则读成已完成任命。

第二项是 席位图。每条受影响旧路径都应列出席位来源、已公开的持有人、常规任期边界与结束状态：任满、辞任、替补、仅转为 Regular Member、竞逐新类别，或未公开。新类别则应说明五个可能席位中哪些已填、哪些空缺、哪些状态尚未公开。没有名字，不能自动推断为存在空缺。

第三项是 资格与选民范围。它重述候选条件和章程规定的两类选民，并给出带日期的选民总数或一份可保留审计的方法。它不必披露每个人私下的资格理由，但必须让结果所依据的分母可以被理解和追查。

第四项连接 程序与结果：提名 issue、公开时实际使用的选举方法、结果说明、README pull request、生效日期以及由此形成的 Voting Member 名单。章程列举 Condorcet 与单一可转移投票等可能方法，并不代表任何具体周期必然采用其中之一。

第五项是 构成约束检查：生效日全部 Voting Members 数目、可用时的公开雇主关联基础、四分之一上限及其状态——符合、已纠正、待定或未公开。核查章程条件并不是在暗示存在利益冲突。

最后是 权限边界与更正日志。它分别链接 Board、CPC、CPC Directors 与项目自治权限，并列出公开材料尚不能证明的事项，例如私下资格理由、未公布票数、日后辞任或 Board 决定。更正应成为一条带日期的补充，而不是对名单的无声覆盖。

开放治理不是每个参与者都拥有全部权力。它是每一种真实权力都有可见来源、范围和终止状态。OpenJS 的秋季过渡正适合在事实产生时把这种区别留下来。

来源

  1. OpenJS Cross Project Council Charter
  2. OpenJS Cross Project Council Governance
  3. OpenJS Cross Project Council repository and current roster
  4. OpenJS Foundation Governance archive
  5. Lu Heng — The Multi-Stakeholder Mirage