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

正如更新中详细说明的那样，这份报告是在与项目内部许多人进行广泛对话后得出的，并且当我们鼓励项目中的其他人提出反馈或参与其中时，对话将继续进行。

由于 Rust 项目的适当治理会影响所有 Rust 用户，我们认为也应该公开这份摘要。虽然自原始帖子以来已经进行了排版和语法修正，但文本在其他方面没有改变。¹

正如摘要中指出的，接下来的步骤是根据我们目前为止的发现，开始制定关于未来 Rust 项目如何治理的提案。这将最终导致 RFC 或类似的包含具体提案的文件。

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

@all，大家好！

我们想向您提供关于我们 12 月份电子邮件的更新，该邮件内容是关于导致 11 月份版主团队辞职的问题。在那封邮件中，我们指出我们有三个高层目标

• 改进我们处理复杂版主问题的方式。
• 将争议中心的具体版主问题达成充分的解决方案。
• 调整 Rust 的治理结构，以更好地满足我们不断增长的项目的需求。

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

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

您的参与机会

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

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

要求

以下是 Rust 治理的要求列表。当前治理结构已经满足了其中一些要求。

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

资源不足的工作

以下是未获得应有投资的工作列表。我们的治理结构应确保这项工作获得适当的关注。

• 政策制定：各个团队在确保他们有适当的政策方面做得不错，但存在一些问题
  • 在缺乏政策可能导致问题时缺乏问责制
  • 在编写政策方面缺乏支持
• 项目结构文档：项目的结构具有实际意义。例如，领导层中的代表、权限、纳入项目沟通等。没有团队负责确保此结构得到正确记录
• 多元化努力：虽然一些团队可能会自行承担多元化工作，但没有人负责在项目层面执行此项工作
• 识别差距：团队在满足自身现有需求方面做得很好，但有时缺乏了解其职权范围之外的其他需求是否得到满足的背景。
• 贡献者管道改进：团队通常在改进自己的工作流程方面做得很好，但这假设贡献者能够找到他们想要贡献的团队。
• 冲突解决：项目成员并非总能达成一致，在某些情况下，如果没有冲突之外的人的参与，就无法达成积极的结果。
• 支持团队负责人：一些负责人可能刚担任领导职务，在没有他人支持的情况下进行领导是困难的。团队负责人不应该依赖个人、私人关系来获得他们需要的支持。
• 项目自我反思：治理结构应该具有自动自我纠正的机制（即，更定期地进行 Mara 和 Ryan 现在正在做的工作），而不是等待危机发生才解决问题
• 报告进展：Rust 项目中发生了很多事情，其中很多事情没有被报道。拥有某种机制可以更好地确保每个人都对项目中发生的事情有一个良好的概述。
• 积极的社区管理：积极培养 Rust 项目的文化
• 市场营销：该项目之前曾围绕 Rust 的使用进行更多的市场营销 - 这项工作已基本转移到由个人单独执行
• 公共关系：Rust 项目有义务与外界沟通（即媒体、公司、教育机构、其他开源项目等）
• 用户拓展：虽然公关是一种推的机制，但该项目还需要某种拉的机制，以便与用户互动并了解他们的需求，而不仅仅依靠贡献者带来的个人见解。
• 愿景工作：建立跨越团队界限的高级项目范围目标。

失败模式

以下是已识别的失败模式列表，我们在讨论新的治理结构时希望确保避免这些模式

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

我想借此机会感谢您阅读这封非常长的电子邮件。再次强调，如果您想以任何形式参与或提供反馈，请随时联系。

干杯，
Ryan