Jujutsujj开源治理指南项目角色、决策投票流程与单一公司影响限制【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jjJujutsu命令行工具为jj是一个面向全球社区的开源版本控制系统其治理模型定义了 Maintainer 与 Contributor 两类角色、一套基于投票的决策机制以及防止单一公司控制项目方向的制度约束。本文以仓库中的治理文档GOVERNANCE.md为骨架结合配套的临时投票流程、贡献指南等仓库资料完整解读 jj 项目的治理体系——读完本文你将了解项目的权力结构、提案如何被批准、Maintainer 如何进出、以及社区如何制衡商业资本的影响无论你是想深度参与 jj 的贡献者还是想研究开源项目治理模式的开发者都能从中获得可直接对照的参考。治理概述面向全球社区的开源项目Jujutsu 是一个开源项目由一个面向全球社区的团队领导、维护和设计。任何感兴趣的人都可以加入、贡献并参与决策过程。治理文档的存在正是为了帮助社区成员理解如何参与决策。这一治理框架在仓库中有多个副本服务于不同的文档站点与目录结构官方文档站点的治理页web/docs/src/content/docs/governance/GOVERNANCE.md由 Astro Starlight 构建通过 web/docs/src/content.config.ts 中的docsLoader加载发布通用 Markdown 文档docs/governance/GOVERNANCE.md仓库根目录的同步副本GOVERNANCE.md。值得注意的是治理文档本身也处于治理流程的管辖之下——本文档自身的修改同样要遵循下文所述的决策流程由现任 Maintainer 集体投票决定。这是一个元治理设计规则本身也必须按规则修改避免了少数人单方面改写制度。项目角色体系Maintainers 与 Contributors项目参与者被划分为两个特殊角色Maintainers维护者与Contributors贡献者。其中 Maintainer 的角色是正式定义的他们被授权就项目的大多数方面集体做出最终决策并需要认真对待社区意见、以整个社区的利益为出发点。Contributor 的角色则相对非正式——当意见众多且存在争议时Maintainer 可以给予更资深的 Contributors 更多话语权。Maintainers项目的对外守护者Maintainers是那些贡献、评审、引导并集体决定项目方向与范围的人。他们并非仅靠提交过大型补丁获得资格而是展现了对项目及其社区的持续承诺。文档列出的预期职责包括并非穷尽列举也非要求每位 Maintainer 均摊承担展现高度承诺并成为榜样对项目与社区保持高投入为他人树立行为标杆大量撰写补丁尤其是胶水代码体力活和日常家务——修复 bug、保证文档质量、一致的 UX 设计、改进流程、评估依赖、处理安全漏洞等评审他人代码以可维护性、性能、代码质量和风格与项目契合为评审视角参与设计讨论特别是架构与长期愿景层面的讨论维护社区氛围确保社区对新老成员都保持温暖、欢迎的态度践行透明度适时沟通决策及其背后的理由。文档特别强调这不是一份要求每位 Maintainer 平均完成所有任务的清单而是一份概念性的行为指引。简而言之Maintainers 是项目对外可见的守护者stewards。现任 Maintainers 名单依据治理文档当前 Maintainers 名单如下Austin SeippthoughtpoliceBenjamin Tanbnjmnt4nIlya GrigorievilyagrMartin von ZweigbergkmartinvonzWaleed KhanarxanasYuya Nishiharayuja注名单会随投票结果动态变化具体以最新治理文档为准。Contributors何为活跃参与Contributors 被定义为积极参与项目与社区、但并非 Maintainer 的人。典型的贡献者行为包括帮助用户解答问题参与各渠道积极且相互尊重的讨论提交高质量的 bug 报告、复现他人报告的 bug、验证修复提交补丁或 Pull Request为他人 PR 提供评审意见与输入协助测试与质量保障就规划中的功能、使用场景或 bug 提交反馈。文档同时明确列出了哪些行为不算贡献者提交过一次 bug 报告后便不再出现撰写博客文章或其他宣传行为在生产环境中使用该软件Fork 项目并维护自己的版本编写第三方工具或插件。这些行为虽然通常很有价值但文档明确它们不构成对代码库或项目本身的持续贡献单凭这些行为不被视为活跃参与。决策流程Decision-Making治理文档为跨项目的决策定义了明确流程提案与期限提出决策的人无论是技术决策还是项目方向决策提交提案并附带2 至 4 周的讨论截止期限。投票选项讨论期间Maintainers 可以投出三种票之一A支持SupportB反对RejectC弃权Abstain计票规则每位 Maintainer 拥有一票参与投票数等于非弃权票的总数当支持票超过参与投票数的一半时提案获得通过。提前达成若在设定时间线之前即达成决策提案可以立即推进并被接受。未达共识若未达成共识提案可以在之后重新提交。这一机制是典型的简单多数 弃权不计入分母设计弃权既不影响通过门槛也避免了少数反对票因分母计算而放大权重。同时提案可稍后重新提交为争议较大的决策保留了迭代空间。Maintainer 的加入与移除机制治理文档对 Maintainer 的增删给出了明确且可操作的规定。加入提名与选举任何活跃的 Contributor 都可以随时提名自己或另一位 Contributor成为 Maintainer该过程纯属自愿无人被强制要求参与但文档鼓励活跃参与者自我提名最终结果由现任 Maintainers 投票与讨论决定。文档同时给出了两个重要的现实提示成为 Maintainer 需要持续参与的高标准且 Maintainer 数量上限在实际上是有界的因此被拒绝是真实可能发生的结果随着项目范围变化该上限可以增加但本质上是动态流动的。如果你不确定当前是否有空缺可以先私下询问现任 Maintainers。退出主动卸任与被动移除主动卸任Maintainer 可以随时放弃职责并退出无需投票被动移除其他 Maintainers 可以通过投票移除某位 Maintainer要求是现任 Maintainer 群体中至少 2/3 多数同意不含被移除者本人的票。原因包括缺乏参与、行为违规等。文档特别强调Maintainers 被要求遵循比普通贡献者或参与者更高的行为与沟通标准。这与 docs/code-of-conduct.md 中社区领袖负有澄清与执行行为标准责任的定位相互呼应。单一公司影响限制防止资本垄断方向治理文档中一项极具特色的制度是单一公司影响限制Single-Company Influence至多 1/3 的 Maintainer 可以由同一家公司付费贡献以降低单一公司控制项目方向的风险若因现有 Maintainer 被同一家公司雇用而导致 1/3 上限被超出Maintainers 必须协商决定如何解决该局面例外条款被雇用的当事 Maintainer 仍有权投票只要这不意味着该公司掌握半数票通常意味着 Maintainer 总数至少为 5 人。这一制度与仓库中的 docs/paid_contributors.md 形成配套该文件公开列出了为 jj 贡献付费的公司及其雇员名单如 East River Source Control、Alphabet/Google、IMC Trading 等其目的正是便于识别利益冲突——例如同一公司员工互相批准对方 PR 的情况。贡献指南 docs/contributing.md 也要求如果你的雇主付费无论是否直接付给你让你贡献 Jujutsu请确保你的 GitHub 用户名被记录在该列表中同时不要合并仅由同一组织的人批准的 PR。配套治理机制临时投票流程temporary-voting在正式治理文档之外仓库还提供了一份配套的临时投票流程用于在永久治理政策落地之前为社区如何批准治理政策提供过渡性办法。背景与目标治理工作组由 Martin von Zweigbergk 推荐任命成员包括 Austin Seipp、Waleed Khan、Martin von Zweigbergk、Emily Shaffer由 jj 原作者任命并未经社区广泛推荐。为避免被社区视为过度控制工作组需要先获得社区批准再为整个项目制定政策。该流程的要点用于批准governance.md、技术设计审批流程、代码审查流程等永久性制度是临时流程永久政策落地后即停止使用是普通社区成员影响治理政策的主要途径投票面向投入型社区成员代码提交者、评审者、提供用户支持者、提供文档者、jj 兼容工具/插件开发者、提供设计反馈者等目标不是全员一致而是广泛认可社区成员可在 GitHub 与 Discord 上参与。四阶段流程阶段名称关键时限核心动作Stage 1提前告知Advance Notice of Effort至少提前 1 周进入 Stage 3 之前工作组说明政策必要性、目标、拟议实现细节创建 GitHub 讨论帖作为全程规范讨论帖Stage 2提案评审期Proposal Review Period发布后至少72 小时才可开始投票通常至少 1 周以 GitHub PR 形式公开提案全文链接到讨论帖说明如何满足 Stage 1 目标社区给出建设性修改建议或致命关切Stage 3提案投票期Proposal Voting Period至少 1 周最长 2 周在 GitHub 用 poll 功能投票Discord 广泛宣传支持/反对2/3 及以上支持票即通过Stage 4实施Implementation—合并政策文档进代码库并在后续讨论中遵循必要时提名个人进入小组或委员会Stage 3 的细节值得展开无法使用 GitHub 的社区成员可联系指定工作组唯一成员代为计入投票只列一人以避免重复计票投反对票的成员应在帖子下评论说明原因以及需要怎样修改才会改投弃权或支持投票结果可能公开或被后续公开参与者应默认如此投票截止日期必须在投票开始时公布一旦开始不可更改工作组可延长投票期以覆盖两个周末利于工作日参与、应对不紧急或更复杂的提案、或覆盖节假日。投票结束后有三种走向通过则实施被拒则可能修订后回到 Stage 2或直接放弃。是否修订或放弃由工作组酌情决定且工作组被期望在提案被拒后重新审视提案要达成的目标本身是否值得追求。Stage 4 强调若实施中发现政策实际行不通可能性低工作组应对社区保持透明并可复用本流程的部分或全部来寻找前进方案。治理如何落地到日常协作治理文档之外仓库的配套文档共同构成了 jj 社区的协作规范贡献规范docs/contributing.mdCLA贡献必须伴随贡献者许可协议Contributor License Agreement版权归贡献者或其雇主所有协议仅授权项目使用与再分发Google CLA 一次签署、跨项目通用提交规范相比 PR 的整体内容项目更关注每个 commit 的内容——逐 commit 评审、不做 squash-merge每个 commit 尽量只做一件事可用jj split拆分commit message 以topic:开头如next/prev: ...、conflicts: ...不用 Conventional Commits 风格的chore:/feat:/fix:代码审查所有提交包括项目成员都需评审项目存在评审者短缺问题文档建议贡献者通过评审他人 PR、为评审者提供充分上下文功能为何有用、用户视角如何工作、设计如何、局限是什么来加速评审废弃与移除策略删除或重命名命令/配置项时应先实现弃用警告并保留到jj vcurrent 6月更节奏下约 6 个月仓库格式.jj/内变更需保持至少一年12 个发布向后兼容付费贡献者透明化如前文所述见 docs/paid_contributors.md。行为准则docs/code-of-conduct.md治理文档中遵循 Community Guidelines的要求对应到仓库的 Contributor Covenant 2.1 行为准则定义了社区行为标准与四级处理阶梯纠正、警告、临时封禁、永久封禁。治理文档中Maintainers 被要求遵循更高行为标准的条款与行为准则中社区领袖负责澄清和执行标准的规定互为表里。设计文档流程docs/design_docs.md大型功能需要先写设计文档Design Doc并经过多方利益相关者的架构评审才能开始接受功能 PR。仓库提供了设计文档蓝图模板含 Summary、State of the Feature、Prior work、Goals and non-goals、Overview/Detailed Design、Alternatives、Issues addressed、Related Work、Future Possibilities 等章节并已在 docs/design 目录沉淀了如 copy-tracking.md、git-submodules.md、jj-converge-command.md、sparse-v2.md 等实际设计文档。这正是治理文档所述参与设计讨论职责的落地载体。社区渠道项目通过 Discord、Libera Chat IRC#jujutsu与 Discord 桥接和 GitHub Discussion 开展日常开发与支持讨论参见 README.md 的相关说明。治理文档所依赖的社区参与正是建立在这些渠道之上。治理与代码库的对应关系从仓库结构可以进一步印证治理机制的落地方式文档与代码同步演进治理文档同时在传统docs/目录与 Astro Starlight 驱动的web/docs/站点源码中维护前者面向通用阅读后者通过 web/docs/src/content.config.ts 的docsLoader作为正式文档集合发布体现了治理信息的公开透明原则治理文档版本化网站支持版本切换prerelease / latest / 历史版本治理规则也随文档版本一同留档便于追溯制度沿革仓库即真相的组织原则docs/core_tenets.md 列出的核心宗旨如仓库是真相来源Git 互操作难以丢失工作为治理讨论提供了技术方向上的共同语言设计决策投票并非凭空进行而是围绕这些宗旨展开。结语Jujutsu 的治理体系在开源项目中颇具代表性它用正式的 Maintainer 角色 非正式的 Contributor 角色区分参与深度用**支持/反对/弃权一票制与简单多数解决日常决策用2/3 多数约束 Maintainer 的加入与移除并用单一公司付费 Maintainer 不超过 1/3** 的硬性比例防范资本对项目方向的垄断——再辅以付费贡献者公开名单、行为准则、设计文档评审与临时投票流程构成了一套环环相扣、可审计、可迭代的社区自治框架。对想要参与 jj 的开发者而言这份治理文档就是你的入场须知从活跃贡献到自我提名从参与设计文档评审到在投票中表达意见每一步都有明确的规则可循。而对研究开源治理的读者而言jj 的案例提供了如何在不牺牲开放性的前提下建立有效决策结构的完整样本。【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Jujutsu（jj）开源治理指南：项目角色、决策投票流程与单一公司影响限制
Jujutsujj开源治理指南项目角色、决策投票流程与单一公司影响限制【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jjJujutsu命令行工具为jj是一个面向全球社区的开源版本控制系统其治理模型定义了 Maintainer 与 Contributor 两类角色、一套基于投票的决策机制以及防止单一公司控制项目方向的制度约束。本文以仓库中的治理文档GOVERNANCE.md为骨架结合配套的临时投票流程、贡献指南等仓库资料完整解读 jj 项目的治理体系——读完本文你将了解项目的权力结构、提案如何被批准、Maintainer 如何进出、以及社区如何制衡商业资本的影响无论你是想深度参与 jj 的贡献者还是想研究开源项目治理模式的开发者都能从中获得可直接对照的参考。治理概述面向全球社区的开源项目Jujutsu 是一个开源项目由一个面向全球社区的团队领导、维护和设计。任何感兴趣的人都可以加入、贡献并参与决策过程。治理文档的存在正是为了帮助社区成员理解如何参与决策。这一治理框架在仓库中有多个副本服务于不同的文档站点与目录结构官方文档站点的治理页web/docs/src/content/docs/governance/GOVERNANCE.md由 Astro Starlight 构建通过 web/docs/src/content.config.ts 中的docsLoader加载发布通用 Markdown 文档docs/governance/GOVERNANCE.md仓库根目录的同步副本GOVERNANCE.md。值得注意的是治理文档本身也处于治理流程的管辖之下——本文档自身的修改同样要遵循下文所述的决策流程由现任 Maintainer 集体投票决定。这是一个元治理设计规则本身也必须按规则修改避免了少数人单方面改写制度。项目角色体系Maintainers 与 Contributors项目参与者被划分为两个特殊角色Maintainers维护者与Contributors贡献者。其中 Maintainer 的角色是正式定义的他们被授权就项目的大多数方面集体做出最终决策并需要认真对待社区意见、以整个社区的利益为出发点。Contributor 的角色则相对非正式——当意见众多且存在争议时Maintainer 可以给予更资深的 Contributors 更多话语权。Maintainers项目的对外守护者Maintainers是那些贡献、评审、引导并集体决定项目方向与范围的人。他们并非仅靠提交过大型补丁获得资格而是展现了对项目及其社区的持续承诺。文档列出的预期职责包括并非穷尽列举也非要求每位 Maintainer 均摊承担展现高度承诺并成为榜样对项目与社区保持高投入为他人树立行为标杆大量撰写补丁尤其是胶水代码体力活和日常家务——修复 bug、保证文档质量、一致的 UX 设计、改进流程、评估依赖、处理安全漏洞等评审他人代码以可维护性、性能、代码质量和风格与项目契合为评审视角参与设计讨论特别是架构与长期愿景层面的讨论维护社区氛围确保社区对新老成员都保持温暖、欢迎的态度践行透明度适时沟通决策及其背后的理由。文档特别强调这不是一份要求每位 Maintainer 平均完成所有任务的清单而是一份概念性的行为指引。简而言之Maintainers 是项目对外可见的守护者stewards。现任 Maintainers 名单依据治理文档当前 Maintainers 名单如下Austin SeippthoughtpoliceBenjamin Tanbnjmnt4nIlya GrigorievilyagrMartin von ZweigbergkmartinvonzWaleed KhanarxanasYuya Nishiharayuja注名单会随投票结果动态变化具体以最新治理文档为准。Contributors何为活跃参与Contributors 被定义为积极参与项目与社区、但并非 Maintainer 的人。典型的贡献者行为包括帮助用户解答问题参与各渠道积极且相互尊重的讨论提交高质量的 bug 报告、复现他人报告的 bug、验证修复提交补丁或 Pull Request为他人 PR 提供评审意见与输入协助测试与质量保障就规划中的功能、使用场景或 bug 提交反馈。文档同时明确列出了哪些行为不算贡献者提交过一次 bug 报告后便不再出现撰写博客文章或其他宣传行为在生产环境中使用该软件Fork 项目并维护自己的版本编写第三方工具或插件。这些行为虽然通常很有价值但文档明确它们不构成对代码库或项目本身的持续贡献单凭这些行为不被视为活跃参与。决策流程Decision-Making治理文档为跨项目的决策定义了明确流程提案与期限提出决策的人无论是技术决策还是项目方向决策提交提案并附带2 至 4 周的讨论截止期限。投票选项讨论期间Maintainers 可以投出三种票之一A支持SupportB反对RejectC弃权Abstain计票规则每位 Maintainer 拥有一票参与投票数等于非弃权票的总数当支持票超过参与投票数的一半时提案获得通过。提前达成若在设定时间线之前即达成决策提案可以立即推进并被接受。未达共识若未达成共识提案可以在之后重新提交。这一机制是典型的简单多数 弃权不计入分母设计弃权既不影响通过门槛也避免了少数反对票因分母计算而放大权重。同时提案可稍后重新提交为争议较大的决策保留了迭代空间。Maintainer 的加入与移除机制治理文档对 Maintainer 的增删给出了明确且可操作的规定。加入提名与选举任何活跃的 Contributor 都可以随时提名自己或另一位 Contributor成为 Maintainer该过程纯属自愿无人被强制要求参与但文档鼓励活跃参与者自我提名最终结果由现任 Maintainers 投票与讨论决定。文档同时给出了两个重要的现实提示成为 Maintainer 需要持续参与的高标准且 Maintainer 数量上限在实际上是有界的因此被拒绝是真实可能发生的结果随着项目范围变化该上限可以增加但本质上是动态流动的。如果你不确定当前是否有空缺可以先私下询问现任 Maintainers。退出主动卸任与被动移除主动卸任Maintainer 可以随时放弃职责并退出无需投票被动移除其他 Maintainers 可以通过投票移除某位 Maintainer要求是现任 Maintainer 群体中至少 2/3 多数同意不含被移除者本人的票。原因包括缺乏参与、行为违规等。文档特别强调Maintainers 被要求遵循比普通贡献者或参与者更高的行为与沟通标准。这与 docs/code-of-conduct.md 中社区领袖负有澄清与执行行为标准责任的定位相互呼应。单一公司影响限制防止资本垄断方向治理文档中一项极具特色的制度是单一公司影响限制Single-Company Influence至多 1/3 的 Maintainer 可以由同一家公司付费贡献以降低单一公司控制项目方向的风险若因现有 Maintainer 被同一家公司雇用而导致 1/3 上限被超出Maintainers 必须协商决定如何解决该局面例外条款被雇用的当事 Maintainer 仍有权投票只要这不意味着该公司掌握半数票通常意味着 Maintainer 总数至少为 5 人。这一制度与仓库中的 docs/paid_contributors.md 形成配套该文件公开列出了为 jj 贡献付费的公司及其雇员名单如 East River Source Control、Alphabet/Google、IMC Trading 等其目的正是便于识别利益冲突——例如同一公司员工互相批准对方 PR 的情况。贡献指南 docs/contributing.md 也要求如果你的雇主付费无论是否直接付给你让你贡献 Jujutsu请确保你的 GitHub 用户名被记录在该列表中同时不要合并仅由同一组织的人批准的 PR。配套治理机制临时投票流程temporary-voting在正式治理文档之外仓库还提供了一份配套的临时投票流程用于在永久治理政策落地之前为社区如何批准治理政策提供过渡性办法。背景与目标治理工作组由 Martin von Zweigbergk 推荐任命成员包括 Austin Seipp、Waleed Khan、Martin von Zweigbergk、Emily Shaffer由 jj 原作者任命并未经社区广泛推荐。为避免被社区视为过度控制工作组需要先获得社区批准再为整个项目制定政策。该流程的要点用于批准governance.md、技术设计审批流程、代码审查流程等永久性制度是临时流程永久政策落地后即停止使用是普通社区成员影响治理政策的主要途径投票面向投入型社区成员代码提交者、评审者、提供用户支持者、提供文档者、jj 兼容工具/插件开发者、提供设计反馈者等目标不是全员一致而是广泛认可社区成员可在 GitHub 与 Discord 上参与。四阶段流程阶段名称关键时限核心动作Stage 1提前告知Advance Notice of Effort至少提前 1 周进入 Stage 3 之前工作组说明政策必要性、目标、拟议实现细节创建 GitHub 讨论帖作为全程规范讨论帖Stage 2提案评审期Proposal Review Period发布后至少72 小时才可开始投票通常至少 1 周以 GitHub PR 形式公开提案全文链接到讨论帖说明如何满足 Stage 1 目标社区给出建设性修改建议或致命关切Stage 3提案投票期Proposal Voting Period至少 1 周最长 2 周在 GitHub 用 poll 功能投票Discord 广泛宣传支持/反对2/3 及以上支持票即通过Stage 4实施Implementation—合并政策文档进代码库并在后续讨论中遵循必要时提名个人进入小组或委员会Stage 3 的细节值得展开无法使用 GitHub 的社区成员可联系指定工作组唯一成员代为计入投票只列一人以避免重复计票投反对票的成员应在帖子下评论说明原因以及需要怎样修改才会改投弃权或支持投票结果可能公开或被后续公开参与者应默认如此投票截止日期必须在投票开始时公布一旦开始不可更改工作组可延长投票期以覆盖两个周末利于工作日参与、应对不紧急或更复杂的提案、或覆盖节假日。投票结束后有三种走向通过则实施被拒则可能修订后回到 Stage 2或直接放弃。是否修订或放弃由工作组酌情决定且工作组被期望在提案被拒后重新审视提案要达成的目标本身是否值得追求。Stage 4 强调若实施中发现政策实际行不通可能性低工作组应对社区保持透明并可复用本流程的部分或全部来寻找前进方案。治理如何落地到日常协作治理文档之外仓库的配套文档共同构成了 jj 社区的协作规范贡献规范docs/contributing.mdCLA贡献必须伴随贡献者许可协议Contributor License Agreement版权归贡献者或其雇主所有协议仅授权项目使用与再分发Google CLA 一次签署、跨项目通用提交规范相比 PR 的整体内容项目更关注每个 commit 的内容——逐 commit 评审、不做 squash-merge每个 commit 尽量只做一件事可用jj split拆分commit message 以topic:开头如next/prev: ...、conflicts: ...不用 Conventional Commits 风格的chore:/feat:/fix:代码审查所有提交包括项目成员都需评审项目存在评审者短缺问题文档建议贡献者通过评审他人 PR、为评审者提供充分上下文功能为何有用、用户视角如何工作、设计如何、局限是什么来加速评审废弃与移除策略删除或重命名命令/配置项时应先实现弃用警告并保留到jj vcurrent 6月更节奏下约 6 个月仓库格式.jj/内变更需保持至少一年12 个发布向后兼容付费贡献者透明化如前文所述见 docs/paid_contributors.md。行为准则docs/code-of-conduct.md治理文档中遵循 Community Guidelines的要求对应到仓库的 Contributor Covenant 2.1 行为准则定义了社区行为标准与四级处理阶梯纠正、警告、临时封禁、永久封禁。治理文档中Maintainers 被要求遵循更高行为标准的条款与行为准则中社区领袖负责澄清和执行标准的规定互为表里。设计文档流程docs/design_docs.md大型功能需要先写设计文档Design Doc并经过多方利益相关者的架构评审才能开始接受功能 PR。仓库提供了设计文档蓝图模板含 Summary、State of the Feature、Prior work、Goals and non-goals、Overview/Detailed Design、Alternatives、Issues addressed、Related Work、Future Possibilities 等章节并已在 docs/design 目录沉淀了如 copy-tracking.md、git-submodules.md、jj-converge-command.md、sparse-v2.md 等实际设计文档。这正是治理文档所述参与设计讨论职责的落地载体。社区渠道项目通过 Discord、Libera Chat IRC#jujutsu与 Discord 桥接和 GitHub Discussion 开展日常开发与支持讨论参见 README.md 的相关说明。治理文档所依赖的社区参与正是建立在这些渠道之上。治理与代码库的对应关系从仓库结构可以进一步印证治理机制的落地方式文档与代码同步演进治理文档同时在传统docs/目录与 Astro Starlight 驱动的web/docs/站点源码中维护前者面向通用阅读后者通过 web/docs/src/content.config.ts 的docsLoader作为正式文档集合发布体现了治理信息的公开透明原则治理文档版本化网站支持版本切换prerelease / latest / 历史版本治理规则也随文档版本一同留档便于追溯制度沿革仓库即真相的组织原则docs/core_tenets.md 列出的核心宗旨如仓库是真相来源Git 互操作难以丢失工作为治理讨论提供了技术方向上的共同语言设计决策投票并非凭空进行而是围绕这些宗旨展开。结语Jujutsu 的治理体系在开源项目中颇具代表性它用正式的 Maintainer 角色 非正式的 Contributor 角色区分参与深度用**支持/反对/弃权一票制与简单多数解决日常决策用2/3 多数约束 Maintainer 的加入与移除并用单一公司付费 Maintainer 不超过 1/3** 的硬性比例防范资本对项目方向的垄断——再辅以付费贡献者公开名单、行为准则、设计文档评审与临时投票流程构成了一套环环相扣、可审计、可迭代的社区自治框架。对想要参与 jj 的开发者而言这份治理文档就是你的入场须知从活跃贡献到自我提名从参与设计文档评审到在投票中表达意见每一步都有明确的规则可循。而对研究开源治理的读者而言jj 的案例提供了如何在不牺牲开放性的前提下建立有效决策结构的完整样本。【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考