文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载导读本文深入解析 Rust RFC 仓库中的治理提案 RFC 3595该提案将当时规模最小的顶级团队 Crates.io 并入 Dev tools 团队使其成为子团队subteam。你将了解 Rust 领导委员会Leadership Council基于顶级团队top-level team身份分配代表的机制、判定顶级团队的五条标准、本提案的动机与落地细节以及它与此前 RFC 3533Release 并入 Infrastructure之间的治理演进脉络并对照仓库内其他文档理解 Crates.io 团队的实际职责范畴。1. 提案概要一次纯粹的委员会代表权调整RFC 3595Feature Name: move-crates-io-team-under-dev-tools起始日期 2024-03-25的核心提议非常明确将 Crates.io 团队并入 Dev tools 团队作为其子团队。两个团队本身的成员构成保持不变。这里需要特别澄清一个容易误解的细节原文档脚注 [^subteam] 专门作了说明子团队的成员并不会自动成为父团队的直属成员。因此合并之后Crates.io 成员属于更广的 Dev tools 团队家族team family但不是Dev tools 团队 proper即父团队本体的直接成员实际影响之一是Crates.io 成员不拥有与 Dev tools 直属成员身份绑定的勾选权限checkbox authority例如 RFC 决策投票权限但 Crates.io 成员可以担任 Dev tools 在领导委员会中的代表。换言之这是一次纯粹的委员会代表权调整而不是职权或人事的重新洗牌——这正是理解全文的关键。2. 动机顶级团队身份在领导委员会时代变得重要2.1 从核心团队到领导委员会要理解本提案必须先理解其制度背景。在 Rust 的早期治理中核心团队core team承担最终决策职责其演进过程记录在 RFC 10682015 年提出以 subteam 补充核心团队。而 RFC 3392leadership-council 于 2022 年确立了领导委员会作为核心团队的继承者委员会由每个顶级团队各委派一名代表组成顶级团队及其子团队共享该代表的发言权。RFC 3392 同时明确规定了顶级团队应满足的通用标准见 text/3392-leadership-council.md拥有对 Rust 项目具有基础性foundational的职权范围purview是该项职权范围内所有事务的最终决策者职权范围不是其他团队职权范围的子集即不能是子团队或类似治理结构职权范围是开放的、预期无限期持续是当前活跃的 Rust 项目组成部分。RFC 3392 还规定顶级团队数量须在 49 个之间宜 58 个以平衡结构多样且扁平与能够高效对话和达成共识两个诉求并明确呼吁重新审视哪些团队应当保持顶级团队身份。RFC 3595 正是这一审视的第二次尝试——第一次是 RFC 3533它把 Release 团队并入 Infrastructure 团队。2.2 数据信号Crates.io 是唯一没有子团队的顶级团队RFC 3595 用 2024-03-19 的数据展示了各顶级团队的规模对比| 团队 | 顶级成员数 | 子团队/WG/项目组数量 | |--|--|--| | Crates.io | 8 | 0 | | Compiler | 15 | 31 | | Dev tools | 6 | 11 | | Infrastructure | 6 | 4 | | Language | 5 | 19 | | Library | 6 | 7 | | Moderation | 2 | 2 |数据统计方式在 rust-lang/team 仓库中检索subteam-of team-id。作者强调Crates.io 是唯一一个没有子团队的顶级团队。需要说明的是本提案并不主张顶级团队必须有子团队这类硬性要求是否提出此类要求留给未来的 RFC 去论证而是把没有子团队作为Crates.io 与其他顶级团队不可比的一个信号。Moderation 团队虽然也小但属于特例——它的工作天然要求高社区信任且永远需要在领导委员会中保有一席原文档脚注 [^mods]。2.3 对照标准Crates.io 为何不完全符合顶级团队定义对照 RFC 3392 的标准作者承认 Crates.io 大体上符合条件但有两点不那么贴合第一点职权范围并非完全独立。标准要求职权范围不是其他团队职权范围的子集。虽然多数团队的职权边界并不清晰但可以论证 Crates.io 的职权范围是多个团队职权范围的子集详见下文备选方案一节对这一点展开的讨论。第二点并非其职权范围内的最终决策者。许多涉及 crates.io 的决策最终落在以下类别法律决策或资金工作——由 Rust 基金会Rust Foundation处理托管决策——由 Infrastructure 团队处理与 Cargo 对接的能力——由 Dev tools / Cargo 团队处理。Crates.io 团队当然参与这些决策并负责执行但很难说它是运行 crates.io 所有事务的最终决策者。2.4 直接的现实痛点代表负担既不高效也不公平在过去是否顶级团队影响不大但 RFC 3392 让顶级团队身份直接决定领导委员会席位后问题凸显负担不成比例Crates.io 团队规模小集体时间中用于担任委员会代表的比例反而更高代表性不公平Crates.io 的代表为更少的人代言——其代表的分母远小于其他团队代表人选稀缺为数不多的成员中许多人没有时间精力服务领导委员会或存在被感知的利益冲突——特别是受雇于 Rust 基金会的成员他们并非委员会代表的最佳人选基金会与 Rust 项目之间需要保持适当的独立性。2.5 关键承诺决策权不转移RFC 3595 特别澄清在实际决策层面Crates.io 子团队保留所有与 crates.io 相关事务的决策权。本提案不改变谁来做某个决策纯粹是委员会代表层面的调整。只有当 Dev tools 团队未来选择以不同方式组织自身结构时这种格局才可能随时间变化。3. 落地细节Practicalities合并后会发生什么3.1 合并动作本身提案被接受后Crates.io 团队移动为Dev tools 的子团队Dev tools 团队保持其顶级团队形态不变Dev tools 的委员会代表继续在委员会任职Crates.io 的代表立即停止在一切用途上被计入代表。3.2 代表交接计划原文档脚注 [^plan] 记录了一个提案当时的非正式计划Carol Nichols 将卸任 Crates.io 代表由 Eric Huss 接任但这一交接会在合并之后通过 Dev tools 团队内部流程正式确定。3.3 子团队身份在委员会机制中的位置结合 RFC 3392 的制度细节可以更完整地理解这次合并的后果每个顶级团队恰好委派一名代表该代表同时代表其顶级团队和全部子团队见 text/3392-leadership-council.md顶级团队或其任何子团队的成员均可被选为代表委员会代表的任期为一年同一委派有连续三届的软上限代表可配置候补代表alternate在主力缺席时代行职责若代表与候补连续 3 周不参与委员会议事该团队的代表将不计入决策法定人数移除某个团队的顶级身份需要除该团队代表之外全体委员会代表的一致同意且该团队代表仍须被邀请参与相关讨论见 text/3392-leadership-council.md。合并之后crates.io 相关议题在委员会中的发言权由 Dev tools 代表承接Crates.io 团队作为子团队仍可经由其顶级团队在委员会中获得代表性。4. 备选方案为什么是 Dev tools而不是其他选项RFC 3595 用一节专门讨论被否决的方案这是理解为什么并入 Dev tools的关键。4.1 备选一并入 Infrastructure理由支持点crates.io 使用了大量由 Infrastructure 团队管理的服务——Fastly、CloudFront、S3、Heroku、GitHub 等。否决理由docs.rs 团队处境类似而它已经是 Dev tools 的子团队——既然 docs.rs 挂在 Dev tools 下把同样依赖外部托管服务的 crates.io 并入 Dev tools 也顺理成章。4.2 备选二同时作为 Dev tools 和 Infra 的子团队理由支持点Types 团队有先例——它在技术上同时是 Compiler 和 Lang 两个团队的子团队RFC 3392 的脚注也提醒过这种菱形结构应避免代表性失衡。否决理由rust-lang/team 仓库并不真正支持多重继承multiple inheritanceCrates.io 团队尤其希望与Cargo 团队同样位于 Dev tools 家族建立更紧密的关系与 Infra 团队的合作可以沿用现状继续。4.3 备选三新建一个政策团队设想内容Crates.io 的职权中有一部分更像政策决策而非实现细节例如crates.io 应向外界展示每个 crate 的哪些信息如何处理不同的 crate 所有权情况网站应支持哪些浏览器。可以想象一个专职负责此类政策问题的新团队喜欢思考与讨论政策的人加入其中而不必负责实现负责实现的人也不必承担制定政策的职责——这类问题如今往往会上升到领导委员会。否决理由政策团队是否可行、是否可取尚不明确。但本 RFC 并不排除未来做这种拆分——如果可行可以留作未来的增强项。5. 先例与治理演进脉络RFC 3595 明确承认其大量内容借鉴自 Ryan Levick 的 RFC 3533将 Release 团队并入 Infrastructure 团队并致谢了这份复制粘贴的基础文本。两个提案共享相同的骨架同样的子团队脚注说明子团队成员不自动成为父团队直属成员、没有勾选权限、但可担任委员会代表同样的不再重大 → 重大论证RFC 3392 引入以顶级团队身份为基础的委员会代表制后顶级团队身份的认定变得关键同样的决策权保留条款合并不改变任何具体决策的归属。RFC 3533 中还有一个 RFC 3595 未重复的细节值得一提作为合并的一部分wg-triage 从 Release 团队移出暂时挂靠到 Launching Pad直到找到更合适的归属。这展示了顶级团队被重组时其子团队去向的处理方式——Launching Pad 正是 RFC 3392 设立的、用于临时收容无处挂靠子团队的伞形顶级团队每 6 个月复核一次子团队归属进展。另外RFC 3533 的 Future Possibilities 一节就预告过将 crates.io 的一部分并入 Infrastructure并指出 crates.io 是除 Release 外职权范围最小的团队——这为 RFC 3595 的出现埋下了伏笔。6. 从仓库佐证Crates.io 团队的实际职责范围虽然本提案是治理结构层面的调整仓库中其他文档可以帮助理解crates.io 团队到底做什么从而更准确地评估合并的合理性。政策与支持请求RFC 3660crates-io-crate-deletions 展示了 crates.io 团队的日常职责之一——处理 crate 删除类请求。该 RFC 提议将团队的非正式规则固化为正式政策允许 crate 作者在满足条件时自行删除 cratecrate 发布不足 72 小时或同时满足仅有一个所有者、无反向依赖、每月下载量不足 100 次。并新增 API 端点DELETE /api/v1/crates/:crate_id。文档明确写道为了给用户简化流程并减轻 crates.io 团队处理此类支持请求的工作量——这正是该团队同时处理实现与政策问题的实证删除条件属于政策设计API 端点属于实现二者都在 crates.io 团队职权内。这也印证了 RFC 3595 备选方案三政策团队设想的现实背景。生态位置README.md 明确将 Crates.io 列为需要走 RFC 流程的三大对象之一substantial changes to Rust, Cargo, Crates.io, or the RFC process itself说明 crates.io 与 Cargo、Rust 语言并列为生态核心组件其团队与 Cargo/Dev tools 的协作关系紧密——这是选择 Dev tools 作为新父团队的重要现实基础。子团队形态子团队在 Rust 治理中是一种成熟的组织形式。项目组Project Group机制在 RFC 2856project-groups 中形式化项目组依附于某个团队通过团队共识如 RFC创建有章程charter、shepherd、团队联络人liaison和专属仓库工作完成后归档。docs.rs 团队作为 Dev tools 子团队的先例为 crates.io 并入后如何运作提供了参照模板。7. 总结与影响评估RFC 3595 是 Rust 在领导委员会时代对顶级团队名单的一次务实收敛制度意义延续了 RFC 3392 确立的审视义务是继 RFC 3533 之后的第二次顶级团队再平衡组织意义Crates.io 团队从唯一没有子团队的顶级团队变为 Dev tools 家族的一员获得与 Cargo、docs.rs 等团队更紧密的协作关系决策意义决策权归属不变变化仅限于委员会代表——Dev tools 代表继续任职Crates.io 代表立即不再计入保留空间不排除未来将 crates.io 的政策性职责拆分给专门团队。这一提案的边界非常克制它不要求顶级团队必须有子团队不改变具体决策归属也不排除未来演进。对关注 Rust 治理的人来说它提供了一个如何基于明确的制度标准重组团队的完整案例对 crates.io 用户而言团队结构变化并不影响任何功能与政策。延伸阅读仓库内路径RFC 3595 原文RFC 3392 领导委员会顶级团队标准与代表机制RFC 3533 Release 并入 Infrastructure直接先例RFC 2856 项目组机制子团队组织形式RFC 3660 crates.io crate 删除政策crates.io 团队职责实证RFC 1068 Rust 治理结构早期 subteam 制度演进RFC 流程总览README赞分享文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载相关推荐Rust 项目治理重组解析RFC 3533 将 Release 团队并入 Infrastructure 团队Rust 项目治理重组解析RFC 3533 将 Release 团队并入 Infrastructure 团队 导读 本文以 text/3533 combine文档Rust 治理架构演进RFC 1068「核心团队 子团队」双层治理模型深度解析Rust 治理架构演进RFC 1068「核心团队 子团队」双层治理模型深度解析 本文以 RFC 1068《Rust 治理结构》 https://link.文档NetSonar深度解析从ping测试到DNS配置的全方位网络监控方案NetSonar深度解析从ping测试到DNS配置的全方位网络监控方案 NetSonar是一款功能强大的网络诊断工具专为管理员和开发者打造提供轻量级、跨平网络桌面应用运维上一篇MonSter论文精读CVPR 2025 Highlight背后的核心创新点解析下一篇nlp_chinese_corpus社区问答专家识别高价值回复者挖掘模型创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考