RFC 0000: 治理规则（Governance）

状态：Draft v0.15（社区讨论稿，非官方标准）

字段	内容
编号	0000
标题	治理规则
状态	Draft
目标版本	v0.15
范围	RFC 流程、评审与决策、merge 权限、命名登记、安全披露、表述边界；不管任何技术契约的内容
依赖	无（本 RFC 是其他一切 RFC 的前置）
讨论方式	omdsh-dev/community

这份文件回答一个问题：这个标准谁说了算、怎么改、吵起来怎么办。 治理规则是标准合法性的来源——想参与标准制定的人先读这份；只写插件或宿主的人可以不读。按 docs-plan.md §7 的建议，治理文档不应由一个人定稿，本 RFC 征求 2-3 人合写与共同评审。

一句话摘要

规定 RFC 从 Draft 到 Final 怎么走、最短 14 天公开评审、lazy consensus 加 maintainer 合议兜底的决策方式，以及命名登记、安全披露和"社区标准不自称官方"的表述边界。

背景

标准的第一原则是"标准的存续不依赖 dsh 上游的任何决定"——这要求社区自己的决策规则先于争议存在。RFC 0001 在底稿中明确把治理列为前置条件（评审期、merge 权限、争议解决是 issue #23 留下的开放问题之一），decisions/ 已有的两轮处置记录是"变更先过审查再登记"规则的实践样本，但规则本身从未成文。本 RFC 把它成文。

目标

• 每个规范变更都可追溯：谁提的、谁评审的、异议如何处置、落在哪个文件。
• 决策规则先于争议存在，而不是吵起来之后现定规则。
• 任何人看完本文件就知道：怎么提案、怎么反对、反对不成怎么申诉。

非目标

• 不规定插件 / 宿主的技术内容（那是 RFC 0001+ 和 spec/ 的事）。
• 不设立基金会、理事会等法人或类法人结构。
• 不要求、不预设 dsh 官方参与（官方参与的请求与边界见 RFC 0001 §7）。

设计

1. RFC 状态机

状态机本身定义在 template.md：Draft → Review → Accepted → Final，终止或替代状态 Deprecated / Superseded / Withdrawn / Rejected。各状态的进入 / 退出条件如下：

状态	含义	进入条件	退出条件
Draft	写作与早期讨论中，可随时修改	作者按模板提 PR	申请评审 → Review；作者撤回 → Withdrawn
Review	公开评审期	Draft 内容完整，且至少一名 maintainer 认为可以评审	评审期满且无未决异议 → Accepted；有实质异议 → 回 Draft；被合议否决 → Rejected
Accepted	方向已定，等待落地证据	Review 通过	规范文本 + schema/registry + fixtures + 一致性测试齐备 → Final；被新 RFC 替代 → Superseded
Final	契约冻结	落地证据齐备	弃用 → Deprecated；被替代 → Superseded
Deprecated	仍可用但不推荐	Final / Accepted 经弃用 RFC 标记	移除时间由弃用 RFC 声明
Superseded	已被另一份 RFC 替代	替代 RFC 进入 Accepted	终态
Withdrawn	作者撤回	Draft / Review 中作者主动撤回	终态
Rejected	评审后明确不采纳	Review 期合议否决	终态（同一主题可用新编号重新提案）

已 Accepted / Final 的 RFC 不再修改正文；勘误与修订走新 RFC。

2. 评审期与决策方式

• 最短公开评审期：14 天。 Review 状态不满 14 天不得转 Accepted。影响面大的变更（breaking change、命名空间占用、表述边界），maintainer 应延长评审期并公示理由。
• 决策方式：lazy consensus + maintainer 合议兜底。 评审期内无人提出实质异议即视为通过；有异议则逐条处理（作者回应 → 修改 → 重新公示），无法收敛时由 maintainer 合议裁决，裁决必须公开写明理由。
• "沉默 = 同意"的前提是"足够可见"：进入 Review 的 RFC 必须在 community 讨论区有独立的、可从仓库 README 抵达的讨论入口。

3. 异议与申诉

• 异议必须公开、具体、可回应：指出哪条设计、造成什么后果、建议的替代方案。单纯表达不喜欢不计为实质异议，但会被记录。
• 作者对每条实质异议给出处置（已采纳 / 限定采纳 / 拒绝 + 理由），处置登记到 decisions/。
• 申诉：对合议裁决不服，可在裁决公示后 14 天内公开申诉；由未参与原裁决的 maintainer 复核一次，复核结果为终局。

4. merge 权限与 maintainer

• maintainer = 对本仓库有 merge 权的人。 当前名单待社区公示确认（见开放问题 1）。
• 增补：任何 maintainer 可提名；提名在 community 公示 14 天，按 lazy consensus 决定。被提名者须公开声明利益关系（维护哪些宿主 / 插件 / 分发渠道）。
• 退出：可随时主动退出；连续 6 个月对评审与合议均无响应的，经公示 14 天后移出。
• 义务：评审期内对 RFC 给出"已读"表态；参与合议；遵守利益冲突回避。
• 构成：建议 3–7 人，且不得全部来自同一宿主产品或同一组织。

5. 利益冲突回避

• 评审与自己直接相关的 RFC 时（例：某宿主维护者评审影响自家宿主的 conformance 规则），必须在该 RFC 的讨论中声明利益关系。
• 声明后仍可正常参与讨论与表态，但不参与该议题的合议兜底裁决。
• RFC 作者本人是 maintainer 时，对自己的 RFC 不行使合议裁决权。

6. 命名登记与官方保留命名空间

• capability / event / 扩展点坐标的唯一权威来源是 registry/；任何人不得从 RFC 正文或实现代码中自行发明"等价"名称。
• 登记流程：新坐标 = 一份 RFC（可以是轻量的：坐标、kind、语义边界、owning spec、fixtures 计划）+ registry 条目 PR。条目格式与必填字段见 registry/README.md。
• x-org.* 私有命名空间与官方保留命名空间的规则本体见 VERSIONING.md §5，此处只定流程：占用或释放官方保留命名空间须经 maintainer 合议；若官方已参与治理，应同时征求官方代表意见。

7. 安全问题的非公开披露

• 渠道：通过 GitHub Security Advisories 向本仓库提交私有报告（示意渠道，以仓库 Security 页面定案为准）。
• 流程：maintainer 在 7 天内确认收到；修复与公开的时间线由报告者与 maintainer 协商，默认 embargo 不超过 90 天；修复发布前不得公开细节。
• 范围：规范缺陷（例如某条约束可被规避且后果严重）与参考实现漏洞都走这个渠道。

8. "社区标准"与"官方标准"的表述边界

• 本仓库所有文档与对外表述必须标注"社区 Draft / 社区标准，非官方标准"；任何版本不得自称官方标准或暗示官方背书。
• 一致性表述的规范本体（"通过 conformance 能说什么、不能说什么"）在 spec/conformance.md；此处只重申底线：禁"安全插件"、禁"官方认证"。
• 官方以任何身份参与治理，不改变本标准的社区属性；是否采纳为官方标准是官方自己的决定，不由本仓库代为宣布。

9. 参考实现与规范的关系（原则 ⑧ 的治理落地）

• 标准只由四件套定义：规范文本（spec/）+ registry/schemas + fixtures + 一致性测试。 任何实现——包括 fabric 参考实现——都不是标准本身。
• 实现与规范冲突时以规范为准；若实现证明规范有错，走勘误 RFC 修改规范，不允许"实现先行、规范追认"。
• 实现不能自我认证：conformance 证据必须由独立于实现作者的一方复跑或复核。验收要求见 spec/conformance.md。
• 许可证：规范文本与参考实现均采用 MIT（见仓库根目录 LICENSE 文件）。

10. 反馈链路与 decisions/

新评论不静默改写 Draft：来自 issue / discussion 的实质意见，先过本 RFC 规定的审查流程，再登记到 decisions/；处置类别与格式沿用既有记录（见 round-1 文件头的规则说明）。

被拒绝的替代方案

1. BDFL 单人裁决。 由一名核心作者对所有争议一锤定音。拒绝理由：单一决策者与"社区标准"的定位矛盾，且单点风险高——个人离开即停摆。重新考虑的条件：若社区长期凑不齐 3 名活跃 maintainer，应诚实降级为个人项目治理并对外说明，而不是保留名义上的社区流程。
2. 不设流程，直接改 main。 像普通开源项目一样"PR 看着行就合"。拒绝理由：标准的价值来自可预期的变更节奏；没有评审期与处置记录，生态无法判断何时可以跟进实现。说明：错别字、断链等非实质修改本来就不需要 RFC，本流程只对规范语义变更生效。
3. 按 star / 下载量 / 出资加权投票。 用可量化指标代替共识。拒绝理由：指标可被操纵，且会把生态推向"大宿主说了算"，违背多宿主制衡的设计初衷。重新考虑的条件：合议长期无法裁决、且社区规模大到 lazy consensus 事实上失效时，可作为补充机制重新提案。

开放问题

1. 初始 maintainer 名单与人数——本 RFC 定稿前须在 community 公示确认。
2. 官方若接受参与邀请（见 RFC 0001 §7.2），其治理身份（观察员 / 评审者 / 共同维护者）如何落座？
3. 安全披露渠道的具体落地（Security Advisories 还是邮箱列表）与响应时限是否需要更硬的承诺？
4. 14 天评审期的实际节奏是否合适——首份 RFC 进入 Final 后复盘一次。

变更记录

日期	变更
2026-08-18	初稿（依据 issue #23 / #24 讨论与 docs-plan §2 必答题撰写）