Rust团队内部斗争终平息：建立新领导委员会、权力下放、宣布新的治理模型草案

出品 | OSC开源社区（ID：oschina2013)

2021 年 11 月，Rust 审核团队 (Moderation Team) 一封突如其来的“集体辞职公告”让整个社区为之震惊。因为这份辞职声明来得如此突然，措辞又比较严厉，广大程序员看到这则声明后“一脸懵逼”，但又怀着吃瓜的好奇心，彷如在观看一场开源界的政治斗争戏。

当时团队成员 Andrew Gallant 指出此举是为了抗议 Rust 核心团队 (Core team) 不对除自己以外的任何人负责。他们并没有在公告中透露过多的细节。不过，根据审核团队成员 Matthieu M 在 Reddit 上的表述，导致审核团队直接辞职的原因是，其与 Rust 核心团队数月来一直不断恶化的矛盾。

此时，坊间传言，核心团队中的一名女性成员 Ashley Williams 使用 CoC 作为 “武器” 来对付男性贡献者，但自己却没遵守。因此，当 Rust 领导层已经明显被讨厌男性的人员渗透和腐蚀，他们贪图权力却没有改善语言和生态，Rust 审核团队的三名白人男性成员（他们都是非常敬业的 Rust 程序员，与 Rust 核心团队成员相反）决定退出。

到了 2022 年 7 月，Rust 核心团队发布公告称，团队内部备受争议的成员 Aidan Hobson Sayers 和 Ashley Williams 已退出团队。

就在近日，Rust 社区发布了一项有关新治理计划的 RFC：旨在建立领导委员会 (Leadership Council) 以替代原本的核心团队 (Core Team)，委员会将其大部分权力下放给各团队。

此 RFC 由 Rust 团队的@jntrnr (Core)、@joshtriplett (Lang Team Lead)、@khionu (Moderation)、@Mark-Simulacrum (Core Project Director, Release Lead)、@rylev (Core Project Director)、@technetos (Moderation) 以及@yaahc (Collaboration Project Director)共同撰写，目前正处于供 Rust 项目成员发表意见的评论期 (comment period)。该文件必须得到大约 20 个团队领导和前核心团队的批准，这些人需要自愿卸任以支持治理文件创建的新领导层。

Rust 项目由数百名分布在全球的人员组成，他们被组织成具有不同权限的团队。
从历史上看，核心团队既确定了不属于团队权限的重要工作，同时也试图自己完成这些工作。然而，将这两项活动放在同一个团队中并没有提升效率，反而导致了倦怠。

此 RFC 建立的领导委员会工作重点是确定团队权限之外的工作并确定其优先次序。委员会主要是委托这些工作，而不是自己做这些工作。委员会还可以作为团队之间的协调、组织和问责机构，例如跨团队的工作、路线图和项目的长期成功。

此 RFC 还建立了整个委员会、个别委员会成员、审核团队、项目团队和项目成员之间的监督和问责机制。

Rust 语言团队领导人 Josh Triplett 表示，他们希望解决导致领导层危机的潜在结构性问题，结束混乱局面。为此制定了如今这一新的治理模式，他还开玩笑地将撰写新治理模式比作撰写宪法。

“因此，项目内部达成了广泛共识，我们需要创建一个更好的正式治理结构，以消除其中的一些模糊性和冲突；并拥有处理这些问题的机制，确保不会再出现类似的危机。我们不想让事情再次发展到那种地步。”

Rust 诞生于 Mozilla 并在其中演变多年，因此最初的 Rust 项目治理结构也是从 Mozilla 演变而来。Triplett 表示，大约在 2016 年或 2017 年一份征求意见稿出台，确立了 Rust 项目的管理。它创建了大约六个团队，包括 core、language、mod、library 和 cargo 团队。但旧模式的问题之一是，核心团队不仅要负责监督出现的问题，还要负责解决这些问题。“我们不可能身兼这么多职，做这么多事…… 太多的工作无法同时完成，除非你得到全职报酬。”

Triplett 也同意这些工作量全归于一个团队过于繁重。并指出，旧的治理模型 “不是一个非常精确的文件”；而其粗略的权力划分，也正是导致治理危机的原因之一。他解释称，新的治理计划概述了 Rust 项目何时可以创建一个新团队、当一个团队完成其工作并需要收尾时该怎么办、以及如何在项目中重组团队。它创建了一个新的顶级委员会，由来自于各个团队的代表成员组成。它还包括像美国宪法一样的制衡机制，以处理问题。

Triplett称 “这将是一个和平的过渡”。他们已经对新的治理模式内容打磨良久，考量了所有的可能，“不仅仅是考虑了我们将来可能造成冲突的情况，还有项目在未来可能遇到的问题的解决方法”。目前大多数团队成员已经非正式地看过并提出了想法，因此他希望只需对草案进行微小改动即可获得批准。

本文文字及图片出自 OSC开源社区