上个月，核心团队、所有顶级团队负责人、审核员以及在 Rust 基金会董事会的项目代表共同向所有 Rust 项目成员发送了一份更新，内容涉及对改进 Rust 项目治理进行的调查。

正如更新中所详述的，这份报告是在与项目内许多人进行了广泛交流后发布的，并且随着我们鼓励项目中的其他人就反馈或参与方式与我们联系，这项工作还将继续进行。

由于 Rust 项目的妥善治理影响所有 Rust 用户，我们认为公开这份摘要是合适的。尽管自原文发布以来进行了一些拼写和语法修正，但文本内容未作其他修改。 ¹

正如摘要中所述，下一步是将我们迄今为止的调查结果付诸实践，并开始起草关于未来 Rust 项目如何治理的提案。这最终将以 RFC 或类似文档的形式呈现具体提案。

发件人：Ryan Levick
收件人：Rust 项目所有成员
日期：2022年4月11日 18:27:00 UTC
主题：Rust 治理更新

大家好，

我们希望向大家提供关于我们十二月份邮件的更新，该邮件涉及十一月份导致审核团队辞职的问题。在那封邮件中，我们提到了我们有三个高层目标：

• 改进我们处理复杂审核问题的方式。
• 妥善解决分歧核心的具体审核问题。
• 调整 Rust 的治理结构，以更好地满足我们不断壮大的项目的需求。

为实现这些目标，我们采取了以下行动：

• 我们已经建立了核心团队、审核团队、Rust 基金会项目代表以及所有顶级团队负责人之间更好的沟通渠道。具体来说，我们为这些群组建立了 Zulip 聊天，以便我们可以快速且自信地就如何处理与项目管理和治理相关的敏感事项达成共识。这促进了围绕项目管理问题的更好沟通，并允许所有项目负责人在健康、富有成效和真诚的基础上进行协作。虽然我们在 Rust 项目中改进项目管理的方式有很多，并且将来也会继续改进，但重要的是我们首先要达到一个健康且富有成效的稳定状态，我们相信我们已经做到了。
• 我们已开始探索改进复杂审核案例（包括正在讨论的具体审核问题）处理方式的可能途径。虽然我们在这封邮件中不会深入细节讨论这个话题，但在更好地理解此问题的复杂性方面已取得一些早期进展。我们期望审核团队与项目负责人联合在未来提出具体提案，尽管这项工作一定程度上被下一点所阻碍。
• 为了设计和实施修订后的 Rust 治理结构的最终目标，我们一直在与项目成员交流，试图深入了解任何此类治理结构的要求。这一过程始于与来自项目各地的许多人进行的各种对话，包括对项目领导者就 Rust 项目治理需求进行的 20 多次正式访谈。这封邮件的剩余部分将尝试概述我们的初步发现，以及下一步行动和感兴趣人士更深入参与的机会。

您的参与机会

首先，虽然我们相信正在对 Rust 治理的需求形成清晰的理解，但讨论并未结束（也可能永远不会结束）。如果您想亲自参与，您可以在这里找到我们使用的访谈问题。以任何您喜欢的方式写下您的回答，并将它们发送给 Mara 或我，以便将它们纳入我们的笔记中。请注意，您的回答不会与任何人分享，只会反映在试图总结项目成员总体反馈的文件中。

我们鼓励任何感兴趣的参与者在阅读以下我们的初步发现总结之前完成访谈。虽然每次访谈都使我们更接近于对 Rust 项目管理需求的全面理解，但目前一切尚未最终确定，所有项目成员将有机会对提出的任何具体提案（很可能以 RFC 的形式）提供反馈。

要求

以下是 Rust 治理的要求列表。现有治理结构已满足其中一些要求。

• 独立自主的团队：几乎所有决策都应在团队层面做出。团队应有能力决定自己的方向，并对其各自的项目部分拥有最终权力。
• 跨团队协作：团队之间的协作应非常密切。这确保团队能够在整个项目的背景下做出决策，而不仅仅是在自己的孤岛中。
• 负责任的团队：团队应对其工作互相负责。应有机制确保团队满足其他团队的期望，并履行对其他团队的义务。
• 集中领导：虽然大多数决策由独立团队拥有并做出，但一些决策会影响整个项目。任何不属于一个或多个特定团队职权范围的此类决策，应由一个集中且负责的领导机构做出。
• 负责任的领导层：领导机构的结构应能代表所有项目团队并获得他们的支持。此外，该团体的成员资格应透明地选出，应获得其他项目成员的广泛支持，并应至少相对频繁地得到确认。最后，成为领导团体成员需要参与更广泛的项目，因此成为领导层成员不能成为个人参与项目的唯一途径。
• 明确且定义清晰的结构：项目的结构、决策者是谁以及决策是如何做出的，对于项目参与者和外部人士都应相对透明。虽然存在非正式关系和其他软权力机制，但大多数协作都是透明公开的。
• 项目管理和行政结构：应有独立于决策的机制来履行项目管理和行政职能。
• 项目负责人不一定总是技术负责人：虽然对一些负责技术事务的人来说，担任项目管理领导职位可能更好，但担任项目领导职位不应要求同时担任技术领导角色。换句话说，最优秀的语言设计者不一定能成为最优秀的开源项目负责人。
• 灵活性：项目结构应足够灵活，以考虑到项目成员始终是志愿贡献（即使他们是由他人为其志愿工作支付报酬），这意味着他们可以自由离开项目，并随时改变他们投入时间的方向。
• 相对较少的官僚主义：重要的是，项目治理开销和官僚主义程度应尽可能少。
• 外部人士易于接触：许多 Rust 项目外部人士（例如用户、潜在用户、其他项目、媒体、合作伙伴等）可能出于各种原因希望参与 Rust 项目。这个过程应该清晰明了。

资源不足的工作

以下列出了未获得应有投入的工作。我们的治理结构应确保这些工作得到适当关注。

• 政策制定：各个团队在确保制定适当政策方面做得不错，但这存在一些问题：
  • 缺乏政策可能导致问题时的问责机制。
  • 编写政策方面缺乏支持。
• 项目结构文档：项目结构具有实际意义。例如，领导层中的代表性、权限、纳入项目沟通等。没有团队负责确保这一结构得到妥善记录。
• 多元化努力：虽然一些团队可能会自行承担多元化工作，但在项目层面没有人对此负责。
• 识别差距：团队在满足自身现有需求方面做得很好，但有时缺乏了解其职权范围之外的其他需求是否得到满足的背景信息。
• 贡献者渠道改进：团队通常在改进自身工作流程方面做得很好，但这假设贡献者能够找到他们想要贡献的团队。
• 冲突解决：项目成员不总是意见一致，在某些情况下，在没有冲突之外人士参与的情况下，无法达成积极结果。
• 支持团队负责人：一些负责人可能对领导工作不熟悉，在没有他人支持的情况下真空式领导是很困难的。团队负责人不应需要依赖个人私下关系来获得所需的支持。
• 项目自我反思：治理结构应具备自动纠正的机制（即更定期地完成 Mara 和 Ryan 当前正在做的工作），而不是等到危机发生后再处理问题。
• 进度报告：Rust 项目发生了很多事情，其中许多并未被报告。应有一些机制来更好地确保每个人对项目进展有一个清晰的了解。
• 积极的社区管理：积极培育 Rust 项目的文化。
• 市场推广：项目之前做过更多 Rust 用途的市场推广——这项工作很大程度上已转由个人独立执行。
• 公共关系：Rust 项目有义务与外部世界交流（即媒体、公司、教育机构、其他开源项目等）。
• 用户外联：虽然公关是一种推送机制，但项目也需要某种拉取机制，以便与用户互动并了解他们的需求，而不是仅依赖贡献者带来的个人见解。
• 愿景工作：制定跨团队的、高层级的项目整体目标。

失败模式

以下列出了已识别的失败模式，我们在讨论新治理结构时需要确保避免这些问题：

• 行政/项目管理工作缺乏资源：行政和项目管理工作通常比技术工作资源少。志愿者通常更倾向于技术工作，而公司倾向于资助技术工作，因为他们更容易看到投资回报。一个正常运行的项目被视为“基本条件”，因此如果没有有目的的资源分配，不太可能获得投资。一种失败模式是行政/项目管理职能得不到资助，最终萎缩，导致这些工作未完成或由已经很忙于其他事务的人来做。
• 项目领导层不负责任：许多团队依赖其他团队的工作才能获得成功。当一个团队觉得另一个团队没有交付他们成功所需的东西时，这可能导致连锁失败甚至公开冲突。追究他人的责任可能很困难，因为它需要明确的期望、提供清晰且可操作反馈的渠道、持续未能达到期望的后果，以及处理冲突的机制。
• 项目领导层脱离项目：随着项目复杂性增加，行政/项目管理开销也随之增加。一个项目整体决策机构可能因处理这些开销而忙碌，失去与项目进展的联系。这可能表现为两种方式：领导机构未能跟上项目进展，和/或项目成员忽略了领导机构，导致权威性下降。一种失败模式是项目领导机构脱离项目，两者实际上开始独立运作。
• 工作过度的领导机构：上述许多要求都假设一个拥有决策权的领导机构。此外，领导机构的权威需要来源于其成员对项目其他部分的参与。一种可能的失败模式是领导机构被赋予越来越多的责任，使其成员更难兼顾机构内外职责。成员越是专注于在领导机构内部的工作，他们从外部工作中获得的权威就越少。此外，权力应主要分散，因此工作过度的领导团队是未能妥善委托权限的迹象。
• 缺乏委托权限：一些行政和项目管理任务需要权威和大量时间的结合才能完成。如果权威只能通过参与项目中的技术事务获得，那么负责该工作的人员可能无法完成工作的风险。例如，在上述资源不足的工作项目中，“识别差距”和“项目自我反思”都需要一定程度的权威，以便发现能产生影响。从事这些工作的团体需要某种方式获得完成工作所需的权限。
• 缺乏透明度：项目治理由性质敏感程度不同的活动组成。一些活动必须保密，因为它直接涉及个人的私事。另一方面，一些活动显然需要整个 Rust 项目从一开始就参与。许多活动介于两者之间。一种潜在的失败模式是未能持续确保本可以公开的信息定期公开。虽然这在实践中可能非常困难，并可能使一些人难以担任领导职位，但不这样做可能导致对领导层的信任下降以及问责制的缺失日益严重。
• 领导层未能持续遵循相同标准：领导层成员至少应遵循与项目其他成员相同的标准。更重要的是，在执行过程中修改政策和程序或解释不明确的政策/程序是诱人的。一种失败模式是领导层给自己设定不同的标准成为常态，导致信任的侵蚀。
• 不明确的流程/政策：假设参与者有相同的假设来编写政策是诱人的。这更灵活，需要的官僚主义少，更容易即时修改。然而，此类流程/政策更容易被滥用（即使没有恶意）。重要的流程应该即使项目所有成员都换了也适用。
• 更改委托的决定：分布式治理结构依赖于委托。然而，真正的委托意味着尊重已被委托决策权的一方的权力。一种可能的失败模式是不断质疑已获得委托权限的团队的决定。问责和监督很重要，但委托方重要的是不仅要尊重其自己也会做出的决定。
• 领导层成为人气竞赛：一些治理体系偏袒那些愿意竞选和/或使自己最显眼的人。然而，最适合领导的人不一定参与这些活动。一种可能的失败模式是将项目领导力直接与某人在社区或项目中的受欢迎/知名程度挂钩。
• 责任扩散：如果没有人明确负责，那么它不一定会被完成，即使未完成的事情明显且明确地造成了损害。如果没有明确的机制来理解项目需求并确保这些需求得到满足，项目很可能继续看到重要工作未被完成。

我想借此机会感谢您阅读这封很长的邮件。再次重申，如果您想参与或提供任何形式的反馈，请随时联系我们。

祝好，
Ryan