jj 项目治理临时投票流程解析：从社区提案到 2/3 多数通过的四阶段机制
【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj
导读
本文基于 jj（Jujutsu，一个与 Git 兼容、兼具简洁与强大的版本控制系统）仓库中的治理文档，完整解读该项目为"工作组的政策提案"设计的临时投票流程（temporary voting process）。该流程用于让社区成员参与、影响并表决治理工作组提出的永久性治理政策（如正式治理结构governance.md、技术设计审批流程、代码评审流程等），是 jj 社区在建立正式治理体系前，获取"广泛社区认可"（widespread community approval）的核心机制。读完本文，你将掌握该流程的四个阶段、关键时间约束（提前一周预告、至少 72 小时评审、1~2 周投票）、2/3 多数通过规则，以及它在 jj 现有治理框架（GOVERNANCE.md、docs/governance/GOVERNANCE.md）中的定位与衔接方式。
为什么需要一套"临时"投票流程
jj 项目的治理工作组（governance working group）由 Martin（jj 的原始作者、当时的唯一维护者）推荐任命，并未经过更广泛的 jj 社区推荐或批准。这本身不是问题，但它意味着工作组在"为整个 jj 项目制定政策"之前，必须先获得某种形式的社区认可——否则就有被社区视为"对项目施加过度控制"的风险。
为此，社区引入了一套临时流程：它只用于批准"更永久的流程与政策"，一旦永久性治理政策落地，临时流程即停止使用。换句话说，这是一套"用来批准流程的流程"（meta-process），其适用范围包括但不限于：
governance.md：描述本项目正式治理结构的文档；- 技术设计审批流程（technical design approval process）；
- 代码评审流程（code review process）。
这套流程同时承载两个目标：
- 收集反馈、批准与认可：来自投入的 jj 社区成员，且应保证现有社区成员无需付出过大代价即可参与投票；
- 作为普通社区成员影响治理政策的主要途径：流程刻意"走到社区成员所在的地方"——GitHub 与 Discord，因为所有开发、大部分支持和技术讨论都发生在这两个平台上。
需要特别强调的是，这不是一个追求"全体一致同意"的流程（社区规模过大，不现实），而是一个追求广泛社区认可的流程。
谁有资格参与：社区成员的界定
流程的参与者是"社区成员"，文档给出了明确列举，包括：
- 代码提交者（code committers）；
- 代码评审者（code reviewers）；
- 提供用户支持的人；
- 提供高质量、可操作反馈的人；
- 提供文档的人（第一方或第三方）；
- jj 兼容工具与插件（如 GUI、IDE 扩展）的开发者；
- 提供设计输入与反馈的人。
如果你自认是社区成员但不在上述分类中，可以联系工作组任一成员，请求扩展这份名单。这份"社区成员"定义也与仓库中 GOVERNANCE.md 对 Contributor 的描述相呼应——后者将贡献者宽泛定义为"积极参与项目的人"，包括回答问题、参与讨论、提交高质量 bug 报告、提交补丁、评审他人 PR、参与测试与 QA 等。
四阶段流程详解
提案从构思到落地，共经历四个阶段：预告、评审、投票、实施。
阶段 1：提前预告（Advance Notice of Effort）
工作组在正式分享政策草案前，必须提前告知社区，时间要求为进入阶段 3 之前至少一周，且越早越好。此阶段工作组的职责：
- 说明工作组认为该政策为何必要；
- 说明政策应实现的基本目标；
- 说明正在考虑的实现细节（如有）；
- 在 GitHub 创建讨论帖（discussion thread），并从 Discord 链接过去。该 GitHub 讨论帖是唯一的正式讨论渠道，将随提案走完整个流程生命周期。
此阶段社区受邀：
- 推荐额外目标，或讨论工作组已提出目标的细节；
- 推荐实现细节。
工作组会以善意（in good faith）考虑这些建议，但可以选择不采纳。
阶段 2：提案评审期（Proposal Review Period）
本阶段持续到工作组认为主要顾虑已解决、提案可以进入投票为止。硬性约束是：提案发布与投票开始之间必须至少间隔 72 小时，以便全球各地的社区成员有时间阅读和评论。通常本阶段应持续至少一周。
此阶段工作组的职责：
- 将提案全文作为 GitHub Pull Request（PR）分享；
- 将该 PR 链接到既有的 Discord 通知线程与 GitHub 讨论帖；
- 在提案内或提案旁的评论中，解释提案如何满足阶段 1 声明的目标。
此阶段社区受邀：
- 在 GitHub 上分享建设性建议，修改提案文本或讨论措辞细节；
- 在 GitHub 上分享**"拦路虎"级别的担忧**（showstopper concerns），包括该担忧为何特别严重、以及如何/为何如此严重的细节。
文档特别把这一阶段类比为代码评审：目标是产出一份代表社区意愿的提案。反馈应可操作、建设性，例如"这一条款会排斥 X；如果我们把它表述成foo bar baz，就可能不那么有排他性"——远比"很明显工作组不想要 X！"更有价值。
最终，由工作组根据讨论结果酌情决定：提案进入投票，或被放弃。
阶段 3：投票期（Proposal Voting Period）
当工作组认为主要顾虑已解决、对提案文本满意时，即开启投票。核心规则如下：
- 投票方式：在 GitHub 上使用投票功能（poll feature）进行，并在投票期间通过 Discord 广泛宣传；
- 无法使用 GitHub 的成员：可通过 Discord 或邮箱联系 nasamuffin（Emily Shaffer）手动提交投票。只列出一名工作组成员，是为了避免意外重复计票；
- 反对票说明：投反对票的成员应在帖子下评论说明原因，并描述"做出何种修改后他们会改为弃权或赞成"；
- 投票可见性：一般假设投票结果可能公开可见，或日后被公开；
- 投票时长：至少开放 1 周，必要时最长 2 周；截止后 GitHub 投票将被锁定。截止时间必须在投票开始时就宣布，投票一旦开始不得更改；
- 延长投票的情形：工作组可延长投票期以覆盖两个周末（方便有日常工作的人参与）、用于紧急程度较低或较复杂的提案，或计入投票期间假期；
- 投票选项：赞成或反对；"参与者"即文档开头列举的社区成员群体。
通过标准：投票期结束时，赞成票达到或超过 2/3 的提案即获批准。
投票结束后有三种结果：
| 结果 | 后续动作 |
|---|---|
| 提案获通过 | 进入阶段 4 实施 |
| 提案被否决 | 可由工作组酌情修订后从阶段 2 重新开始 |
| 提案被否决 | 可被放弃 |
是否修订还是放弃，由治理工作组裁量。文档还要求工作组在提案未获通过后，重新检查提案所要达成的目标本身是否仍然可取——这体现了对目标层的反思机制。
阶段 4：实施（Implementation）
通常，实施就是把包含政策的文档合并进 jj 代码库，并在后续讨论中持续遵循该政策。这正与 GOVERNANCE.md 的定位一致：该文档本身就是正式治理文件，任何对其的修改都受其自身"决策流程"约束。
某些情况下，实施还可能涉及向某个小组或委员会提名个人。此时，被提名的政策应说明这些个人将如何被提名——包括初始提名和未来的持续提名。
文档也诚实地预见到一种罕见情况：实施过程中可能出现障碍，导致政策实际行不通。若发生这种情况，工作组应对社区保持透明，并可能部分或全部复用本流程来决定如何推进。
与正式治理流程的衔接：从临时到永久
本文所解读的临时投票流程，与 jj 仓库中的正式治理文档 GOVERNANCE.md（仓库根目录与 docs/governance/ 下各有一份）存在清晰的分工：
- 临时流程（本文主题）：社区全员（GitHub + Discord）参与，针对"批准永久政策"这一元层任务，要求 2/3 多数；
- 正式治理（GOVERNANCE.md）：定义了 Maintainer 与 Contributor 两类角色。日常决策采用"提议 + 2 至 4 周讨论期限"的机制，每位 Maintainer 投 Support / Reject / Abstain 三选一票，赞成票超过参与投票数（不含弃权）的一半即通过；增删 Maintainer 采用至少 2/3 多数；同时规定单一公司付费维护者不超过 1/3，以降低单一公司控制项目方向的风险。
从仓库结构看，这两个文件在 mkdocs.yml（第 173~174 行）中作为相邻的导航条目出现："Temporary voting for governance" 与 "Governance"，可以推断网站文档体系中二者互为上下文——临时投票流程正是通向正式治理的过渡桥梁。此外，docs/contributing.md 中记录的评审实践（如"不要合并仅由同一组织成员批准的 PR"，以及 docs/paid_contributors.md 要求记录支付贡献的公司名单以暴露利益冲突）与治理文档中的单一公司影响力限制互为印证，共同构成 jj 社区治理的完整图景。
社区成员如何参与：实操要点
综合全文，普通社区成员参与这套流程的关键动作可以总结为：
- 阶段 1：关注 GitHub 讨论帖（Discord 会同步链接），对政策的目标与实现细节提出补充建议；
- 阶段 2：在 GitHub PR 上做"代码评审式"的评论——提出可操作的文本修改建议，或陈述拦路虎级别的担忧；
- 阶段 3：通过 GitHub 投票功能投票；无法使用 GitHub 时联系 nasamuffin 手动计入；投反对票时说明原因与可改变态度的条件；
- 阶段 4：跟踪政策落地为代码库中的文档，并在后续讨论中共同遵守。
对贡献者而言，可以先从 docs/contributing.md 了解项目的贡献规范（CLI 快照测试、nightly rustfmt、MSRV 等），再依据 GOVERNANCE.md 中的提名机制申请成为 Maintainer——这同样是社区治理参与的一部分。
小结
jj 的临时投票流程是一套精心设计的元治理机制：以"提前一周预告 → 至少 72 小时评审 → 1~2 周投票 → 2/3 多数通过 → 实施"为主线，把社区认可嵌入到永久政策诞生之前。它明确了参与者范围、时间约束、投票规则与失败后的回退路径，并与 GOVERNANCE.md 的正式治理结构形成"临时过渡 → 永久治理"的清晰演进关系。对研究开源治理模型或有意参与 jj 社区的开发者而言，这套流程既是可操作的参与指南，也是理解 jj 项目如何平衡"维护者权威"与"社区意愿"的关键文档。
【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
