开源项目治理设计与落地：当需要明确谁决策、维护者升降…

适用于任何开源项目需要明确真实决策权、维护者角色、冲突升级、继任和资产中立性时。

适用场景

解决思路

1. 先确定项目当前真实决策方式：按可靠性检查 repository permissions 和 code-owner files。
2. 再检查最近十个有争议的 pull request 或 issue。
3. 再检查 release history，记录谁 tag 和签名。
4. 最后才听 maintainers 说实际发生什么；在提议任何设计前先表面化现状。
5. 产出简短 as-is statement：谁决定什么、依据什么隐式规则、该规则已在哪些地方失败。
6. 检查常见缺口：没有死锁规则。
7. 检查常见缺口：没有增加或移除维护者的规则。
8. 检查常见缺口：一个人持有所有凭据。
9. 测量集中度：计算 contributor absence factor，即负责 50% 贡献的最小人数，按受治理领域和项目整体分别计算。
10. 建立独立的 privileged credentials 清单。
11. 参考 references/succession-playbook.md 的方法与可辩护性过滤器。
12. 访谈时一次只问一个问题，尽量提供多选选项。
13. 一旦能说出今天谁决策、谁受影响、触发请求是什么，就停止访谈；其余推断后确认。
14. 问：项目是什么，什么触发了此事——争议决策、新维护者、离职、采用者询问谁控制、还是基金会申请？
15. 问：今天谁能合并到主分支，谁能发布 release？通常不是同一人，要点名。
16. 问：他们各自受雇于谁，是否有人换工作后就不再贡献？
17. 问：上一个真正困难的决定是什么，如何解决？
18. 问：项目背后是否有公司——它是否持有 trademark、domain、registry account 或 roadmap？
19. 问：哪些用户被破坏会让你尴尬：爱好者、其他开源项目、还是有采购审查的公司？
20. 问：过去 90 天有多少贡献者合并过东西，去年以来有多少新贡献者？
21. 问：项目是否收到或需要钱——donations、sponsorships、paid contractors、travel？
22. 问：什么未经更广泛决策绝不能改变：scope、license、breaking-change policy、brand？
23. 问：维护者实际能容忍多少流程——每月几小时、常设会议、多容易撤销？答案限定设计。
24. 问：是否有必须解决此事的日期：基金会截止、release、采用者审查、离职？
25. 问：他们想要一次性的修复，还是未来多年复利增长的结构？
26. 记录答案；若 harness 有持久记忆则存储；现在选的模型成为下次审查反对的基线。
27. 在提议任何东西前问第 10-12 题，并说明哪个答案移动了哪个模型。
28. 硬日期会提升一下午能安装的模型（书面个人权威、维护者委员会），降低选举委员会，因为其合法性来自无法压缩的选举。
29. 复利授权会反向移动排序。
30. 低努力上限直接删除 federated 模型，而不是搁置。
31. 排名模型时不要选最令人印象深刻或最便宜的；先读 references/governance-models.md 再推荐。
32. 先跑两个 gate：absence factor 为 1 会让所有共享模型不可采用；先招募 co-maintainers（step 7），再重新排名。
33. 第二个 gate：没有自己贡献者社区的子组件会让 federation 不可采用。
34. 删除被 gate 排除的模型并说明已删除；被搁置在底部的被排除模型会以 scope 形式回来。
35. 按两轴排序：多少人依赖项目、多少人贡献（Nadia Eghbal 的 Working in Public 分类法，见 reference）。
36. 最常被误诊的是用户多贡献者极少，此时稀缺资源是维护者注意力，工作应是 curation、scope defence 和 succession。
37. 默认 efficiency 顺序：maintainer council > written solo authority > federated subprojects > elected steering committee。
38. 默认 value 顺序：elected steering committee > maintainer council > federated subprojects > written solo authority。
39. 默认 effort 顺序：elected steering committee > federated subprojects > maintainer council > written solo authority。
40. 模型 1：Maintainer council（3+ 维护者默认）：每月约一小时，无常设会议；一次投票可撤销；换来的小时解决 ad-hoc 项目最明显缺失的两条规则：死锁和晋升。
41. 模型 2：Written solo authority + succession plan：接近零努力，可免费撤销；不提供决策合法性，只提供声明的响应预期和指定终局，是慢项目与搁浅项目的区别。
42. 模型 3：Federated subprojects：每份 charter 约一周，然后每个常设工作；分岔的节奏抗拒重新合并；只换来解决跨组件死锁。
43. 模型 4：Elected steering committee：安装需一个季度（electorate、eligibility、officers、terms），然后常设工作；最难逆转，因为选举机构不会被它所约束的人悄悄解散；换来自选群体无法主张的合法性、通过席位上限抗捕获、创始人离开后的连续性。
44. 记住 Row 2 排第二只因其分母几乎为零；Row 3 虽买得少仍胜 Row 4，因其努力受子项目数量限制而非永远重复；该顺序会饿死 Row 4：价值最高、努力最高，所以每轮都输。
45. 在以下任一条件成立时仍提升 Row 4：维护者受雇于不止一个 payroll。
46. 在以下任一条件成立时仍提升 Row 4：创始人离开已可见。
47. 在以下任一条件成立时仍提升 Row 4：贡献者基础增长超过维护者集合。
48. 在以下任一条件成立时仍提升 Row 4：基金会申请有明确的治理门槛。
49. 该顺序是默认而非法律；根据项目形态和运行者重新排名。
50. 重新排名：维护者曾运行过选举会让 committee 比假设便宜得多。
51. 重新排名：从未投过票的团队会让 council 比看起来更贵。
52. 呈现前两名并带 trade-offs 和一个推荐，绝不要只给一个选项；每个都列出每月小时数及其买到什么。
53. 监控模型过时信号：决策停滞。
54. 监控模型过时信号：获得影响的唯一路径是“成为维护者”。
55. 监控模型过时信号：一个组织持有多数席位。
56. 监控模型过时信号：子项目发展出自己的节奏。
57. 将这些视为增长而非失败；这些信号不存在是保持当前模型的理由。
58. 为每个决策类别固定谁可决定、阈值、时钟、升级路径：routine change。
59. 同样用于：breaking change。
60. 同样用于：new maintainer。
61. 同样用于：removal。
62. 同样用于：scope change。
63. 同样用于：release。
64. 同样用于：security response。
65. 同样用于：amendment。
66. 默认规则见 references/decision-rules.md。
67. 对 routine work 使用 lazy consensus：宣布，等待声明的窗口，无人反对则继续。
68. 对任何有争议事项使用 consensus-seeking，并为有理由的反对提供去处。
69. 仅在规则要求时使用 explicit vote——维护者变更、修正案、钱、品牌；投票是最后手段（Fogel：妥协后每个人都不太满意，投票后一些人不满意而另一些人满意）。
70. 对重大变更使用 written proposal process，让决定留下 artefact 而不是留在通话里。
71. 要求任何 blocking objection 携带技术理由，让否决是论证而不是情绪。
72. 给每条路径加 timer，因为无界讨论对受益于现状的人是 silent veto。
73. 从 reference 中选一个现成 escalation ladder，而不是发明；reference 比较六个，按谁持有最终决定权及其排除什么。
74. 无论选哪个，升级只花费一个 label 或 agenda item，绝不升级为对抗。
75. 对没人同意的提案，明确 decline 或 hold，而不是悬而不决。
76. 写最小的 GOVERNANCE.md，只覆盖 step 3 的决策类别，不写其他。
77. 遵循 references/governance-doc-template.md 的 section order 和 fill-in guidance；其中展示 right-sized 版本与 over-engineered 版本对比。
78. 把相邻关注点放在自己的文件并链接：governance 说谁持有权威，邻居文件说工作如何完成。
79. 每条 clause 通过一个测试：这个项目做过这件事，或今年可能做吗？否则删掉。
80. 当维护者对阈值犹豫时，写他们实际会遵循的规则，并注明 review date。
81. 让治理可执行：合并权限、review requirements 和 protected branches 与书面角色匹配。
82. 让 code-owner routing 与 governance 命名的领域匹配，并与 commit history 中实际触碰这些领域的人匹配；这是可计算的 diff，不是意见。
83. 让 organization ownership、release signing 和 registry publishing rights 由 governance 命名的人持有，且持有人多于一个。
84. people file 列出当前 affiliations 加 emeritus section。
85. 若 forge 将设置暴露为 settings，读取并与文档 diff；若缺少设置，说明替代它们的手动约定。
86. 将资产与任何单一公司分离：中立性是转移的，不是宣布的；在已记录争议中，伙伴看资产落在哪里，而不是安排是否真诚。
87. 分别审计 code-license openness 和 governance openness；项目可以 permissive licensed 却完全 vendor-controlled（vendor 持有名称、domains、CI 和维护者多数）。
88. 采用者、基金会审查者和竞争者按权重检查：谁持有 trademark、domains 和 registry accounts。
89. 检查：多少维护者共享一个雇主。
90. 检查：contribution agreement 是否集中 relicensing 权利。
91. 检查：minutes 是否已发布且最新。
92. 对四项运行 references/neutrality-and-assets.md 中的 worked audit；它也固定走向中立的步骤顺序。
93. 在需要前设计 succession：工作通过 references/succession-playbook.md 并产出 target absence factor。
94. 产出 staged contributor-to-maintainer path，将 review rights 与 privileged credentials 分开。
95. 产出 inactivity definition。
96. 产出 emeritus path。
97. 产出 named end state。
98. 处理两个有来源冲突的立场：@felixge 给任何发送 pull request 的人 commit access（via opensource.guide）的规则，以及 post-xz-utils 的分阶段授权规则。两者在访问被 disaggregated 后都成立：对 ladder 慷慨，对 keys 慢。
99. Merge rights 授予和撤销都便宜，因此快速发出去是摆脱 bus factor 1 的最快出口。
100. Signing keys、publish tokens 和 organization ownership 既不便宜授予也不便宜撤销，因为签名的 release 在任何人注意前已到下游；这些应基于数月证据授予，并在文档中说明暂停是 policy 而非 distrust。
101. 处于压力下的维护者（burnout、持续骚扰的贡献者、deadline）需要的是 relief 而非 successor：先交出 scope、triage 和 funding，keys 最后。
102. 2024 xz-utils takeover 是案例研究：多年可信度运动加对精疲力竭的 solo maintainer 施压，产生签名的已发布后门。
103. 只有在项目需要处理钱或必须向采用者证明 vendor neutrality 时才打开 foundation/fiscal host 问题；否则说明不需要并停止，因为两者都不需要时，host 只增加义务。
104. 当问题真实时，把它框定为交易：用 autonomy（trademark、release process、decision rules、reporting cadence）换 neutrality 和 financial infrastructure。
105. 按 effort 和 compliance cost 对 host options 排名，这是 step 2 用不上的轴。
106. 记住 host 会增加 reporting obligation 和 counsel review；trademark assignment 在实践中是单向的，要求基金会归还名称是谈判而不是 revert。
107. 见 references/foundation-options.md 了解 host types、entity types、graduation mechanics、money governance 和两个 cautionary entity-risk cases。
108. 推荐一个方向，列出尚未满足的要求，并标出哪些是 legal gates 而不是 ranked choices；那些送 counsel，不进入排序。
109. 当已越过触发条件时，治理工作优先于效率顺序，并指定下一步；说明项目已越过哪个：一个决定有争议且没人能指出规则 → steps 3 和 4。
110. 同一争议反复出现且没有书面 appeal path → step 3 的 ladder，在它迫使 fork 之前。
111. absence factor 为 1，或一人独自持有某 credential row → step 7 优先于一切。
112. 不止一家公司雇用维护者 → 立即 step 6，趁移动 trademark 和 domains 仍无争议。
113. 一家公司雇用多数维护者，或持有 trademark → step 6 作为 blocker；affiliation ratio 将项目分类为 single-vendor（它在 fork 前标记 Redis），任何 messaging 都改变不了。
114. 钱正在进来，或采用者询问谁控制项目 → step 8。
115. Company-backed 项目：风险是不可见控制；用 per-organization seat 或 vote caps 修复——在席位还少到无争议时采用；决策放在 public issues；明确声明公司保留什么（brand、hosted product、release timing）；预先声明保留权利，因为引发反抗的是漂移的保证，而不是已声明的限制。
116. Independent 或 volunteer 项目：风险是可用性，因为没人拿钱回答，无界流程会停滞；用短 timers、小 quorums、asynchronous decisions、scope-refusal rule 修复，并把 funding 当作治理的一部分。
117. 治理成功在于被使用，因此衡量使用而不是完整性；说明五项中哪些有来源，哪些是本技能 baseline（evidence base）。
118. Health check 1 Rule coverage（self-set）：过去 12 个月每个困难决定映射到一条规则；目标 100%；漏掉说明缺少规则，不是例外。
119. Health check 2 Concentration（self-set number，sourced metric）：absence factor 至少 2，且每个 privileged credential 有两个持有人；这是唯一值得阻塞的阈值。
120. Health check 3 Alignment（sourced）：文档角色与 repository permissions 零矛盾；分歧是命名的 review-blocking anti-pattern。
121. Health check 4 Timers（self-set）：每个 decision class 有声明时钟；没有路径无限停滞。
122. Health check 5 Exercise（sourced expectation，self-set interval）：两个季度内，有证据规则运行过一次：增加维护者或转入 emeritus、举行投票、按书面路径解决升级。
123. 在 commit 文档前迭代直到 1-4 通过，为 5 安排检查，然后每年和任何维护者变更后重新运行。
124. 避免常见失败模式：不要因别人的理由买最贵模型；过期的任期比没有选举更糟，因为它们移除了选举本想增加的问责；在基金会审查前几周采纳 committee 且无使用历史是被认可的反模式。
125. 避免：只有头衔没有权威；角色分散到各组织而决策仍留在一家公司内部渠道，是 cosmetic diversity，和 neutrality by press release 一样容易被识破。
126. 避免：在真实信任冲突中写宪法而不是修复；信任冲突期间写新治理只会迁移战斗——一个重大项目同一年产生 elected committee 和两个 fork；先解决冲突，之后再发布结构。
127. 避免：没有 deadlock rule；没有升级路径时，最响亮的反对者通过消耗获胜。
128. 避免：用晋升修复 burnout；把 keys 交给任何可用的人会招致接管；先减少 scope 或暂停 releases。
129. 避免：不说结束。当项目结束时，把 end state 作为治理行为宣布，而不是让用户沉默搁浅。
130. 交付物是一份 review document，逐节验证；在路过时同意的模型会产生没人执行的文档。
131. review document 使用这些 sections：As-is。
132. 同样：Concentration。
133. 同样：Recommendation。
134. 同样：Decision rules。
135. 同样：Neutrality。
136. 同样：GOVERNANCE.md。
137. 同样：Enforcement。
138. 同样：Succession。
139. 同样：Foundation。
140. 同样：Review date。
141. 调用示例：用户说“为我的 library 写 GOVERNANCE.md” → 访谈，然后 steps 1-4；除非答案引发，否则跳过 6 和 8。
142. 调用示例：用户说“我们两个维护这个，我快 burnout 了” → 只做 steps 1 和 7；改变模型不是 remedy。
143. 调用示例：用户说“一个企业采用者问谁控制项目” → steps 1、6，然后如果他们需要证明中立则 8。
144. 调用示例：用户说“我们下季度申请基金会” → 按顺序 steps 1-8，readiness gaps 作为 headline。
145. 参考文件：references/governance-models.md、references/decision-rules.md、references/governance-doc-template.md、references/succession-playbook.md、references/neutrality-and-assets.md、references/foundation-options.md、references/published-findings.md。
146. 相关技能：samber/developer-relations-skills@oss-contributor-onboarding、@oss-issue-triage、@tech-press-relations、@developer-community-moderation、@oss-sponsors-fundraising、@open-source-company-strategy。

适用边界 · 注意事项

• 不适用于 license、CLA 或 DCO 选择；应改用 samber/developer-relations-skills@oss-license-strategy。
• 不是法律建议；licensing、contributor agreements、trademark filings、employment questions 转给律师，不在本流程回答。
• 如果项目不需要处理钱、也不需要向采用者证明厂商中立，不要启动 fiscal host/foundation；若正处于信任冲突，先解决冲突再写新治理结构。