尧图网站建设 
jj 项目治理临时投票流程解析从社区提案到 2/3 多数通过的四阶段机制【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj导读本文基于 jjJujutsu一个与 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由 Martinjj 的原始作者、当时的唯一维护者推荐任命并未经过更广泛的 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 RequestPR分享将该 PR 链接到既有的 Discord 通知线程与 GitHub 讨论帖在提案内或提案旁的评论中解释提案如何满足阶段 1 声明的目标。此阶段社区受邀在 GitHub 上分享建设性建议修改提案文本或讨论措辞细节在 GitHub 上分享**拦路虎级别的担忧**showstopper concerns包括该担忧为何特别严重、以及如何/为何如此严重的细节。文档特别把这一阶段类比为代码评审目标是产出一份代表社区意愿的提案。反馈应可操作、建设性例如这一条款会排斥 X如果我们把它表述成foo bar baz就可能不那么有排他性——远比很明显工作组不想要 X更有价值。最终由工作组根据讨论结果酌情决定提案进入投票或被放弃。阶段 3投票期Proposal Voting Period当工作组认为主要顾虑已解决、对提案文本满意时即开启投票。核心规则如下投票方式在 GitHub 上使用投票功能poll feature进行并在投票期间通过 Discord 广泛宣传无法使用 GitHub 的成员可通过 Discord 或邮箱联系 nasamuffinEmily 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），仅供参考 jj 项目治理临时投票流程解析：从社区提案到 2/3 多数通过的四阶段机制
jj 项目治理临时投票流程解析从社区提案到 2/3 多数通过的四阶段机制【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj导读本文基于 jjJujutsu一个与 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由 Martinjj 的原始作者、当时的唯一维护者推荐任命并未经过更广泛的 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 RequestPR分享将该 PR 链接到既有的 Discord 通知线程与 GitHub 讨论帖在提案内或提案旁的评论中解释提案如何满足阶段 1 声明的目标。此阶段社区受邀在 GitHub 上分享建设性建议修改提案文本或讨论措辞细节在 GitHub 上分享**拦路虎级别的担忧**showstopper concerns包括该担忧为何特别严重、以及如何/为何如此严重的细节。文档特别把这一阶段类比为代码评审目标是产出一份代表社区意愿的提案。反馈应可操作、建设性例如这一条款会排斥 X如果我们把它表述成foo bar baz就可能不那么有排他性——远比很明显工作组不想要 X更有价值。最终由工作组根据讨论结果酌情决定提案进入投票或被放弃。阶段 3投票期Proposal Voting Period当工作组认为主要顾虑已解决、对提案文本满意时即开启投票。核心规则如下投票方式在 GitHub 上使用投票功能poll feature进行并在投票期间通过 Discord 广泛宣传无法使用 GitHub 的成员可通过 Discord 或邮箱联系 nasamuffinEmily 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），仅供参考