也许只有Python之父才能救得了Rust_热门看点

2023-06-21 20:18:41 来源：互联网

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

本月初，我们发布《Rust 内部大乱斗不休止》一文，提到了 Rust 团队内部的混乱治理，以及一些和技术无关的激烈“政治斗争”事件。许多人对 Rust 社区这种无休止的“混乱无序”状态感到担忧，认为这会损害 Rust 语言的声誉和发展。

(资料图片)

相信 Rust 团队内部也感受了危机，以及目前社区治理的各种弊端。今天，他们宣布再度对组织结构进行重大调整。

Rust 项目宣布成立新的顶级治理机构：领导委员会（Rust Leadership Council）。该领导委员会的成立，标志着此前老是闹幺蛾子的 Rust 核心团队和临时领导者职位都将被取消，此后将由 Rust 理事承担顶级治理问题的责任。

背景提要

Rust 诞生于 Mozilla ，并在其中演变多年，最初的 Rust 项目治理结构也是从 Mozilla 演变而来。在 2017 年前后， Rust 项目创建了大约六个团队，包括 core、language、mod、library 和 cargo 团队。其中核心（core）团队主要负责监督其他 Rust 团队出现的问题。

但随着语言本身的发展和社区的壮大，Rust 核心团队的权限变得越来越高，因为他们对 Rust 语言的动态拥有最高决策权，其他团队无法影响他们。此前我们就报道过Rust 审核团队为了抗议 Rust 核心团队 (Core Team) 而集体辞职。据审核团队所言，Rust 核心团队并没有和其他成员遵循同样的行为准则 (CoC)，Coc 似乎变成了核心团队 “严于律人” 的工具，特别是核心团队中的女性成员 Ashley Williams 使用 CoC 作为 “武器” 来对付男性贡献者，但自己却不遵守。

另一方面，除了权限过高，Rust 核心团队的事务又过多且杂。前文提到， Rust 核心团队的主要工作是负责监督其他 Rust 团队，但核心团队既不受其他团队的管理，也没有管理其他团队的权力。这就导致他们既要发现问题，也要自己解决问题，既当裁判又当运动员当然是忙不过来的。

总而言之，旧的治理模型 “并不是一个非常精确的文件”；其粗略的权力划分，也正是导致 Rust 管理团队治理危机的原因之一。

新的治理模式

在经历了多次治理风波后， Rust 各团队成员合力创建了一份新的、名为 “ Rust 领导理事会” 的 RFC 草案，这份草案决定重塑 Rust 的领导者和治理模式。

草案主要确立了以下内容：移除 Rust 核心团队，然后由各团队出一个代表，成立一个顶级的治理团队 “领导委员会”。

“领导委员会” 不会亲自下场干活，而是负责一些职责不清的工作安排及其优先次序，然后对这些工作进行精确到子团队或成员的委托。

其次，“领导委员会” 还要以跨团队工作、规划和项目的长期成功等为目标，成为团队之间的协调、组织和问责机构。领导委员会还需要协调因项目而导致的团队、结构或流程的变化，确保顶层团队负起责任，并负责展示 Rust 项目的官方态度。

该 RFC 由 @jntrnr（核心团队成员）、@joshtriplett（语言团队负责人）、@khionu（调解团队成员）、@Mark-Simulacrum（基金会核心项目主管，发布团队负责人）、@rylev（基金会核心项目主管）、@technetos（调解团队成员）和 @yaahc（基金会合作项目主管）共同撰写。

而 Rust 项目的大部分发展和维护工作（例如编译器和核心工具的维护、语言和标准库的发展、基础设施的管理等）仍由九个顶级团队负责。

第一期 Rust 领导委员会由九个顶级团队的代表组成：

Compiler（编译器团队）: Eric Holk

Crates.io（Crates.io 团队）: Carol (Nichols || Goulding)

Dev Tools（开发工具团队）: Eric Huss

Infrastructure（基础设施团队）: Ryan Levick

Language（语言团队）: Jack Huey

Launching Pad（一个新团队，还没正式成立）: Jonathan Pallant

Library（库管理团队）: Mara Bos

Moderation（审核团队）: Khionu Sybiern

Release（发布团队）: Mark Rousskov

目前 Rust 核心团队已被解散，团队成员主动或被动地 “离开了”。接下来的几周内，Rust 团队的主要工作是为新的领导委员会建立基本的基础设施，包括制定定期会议计划、提出议程项目的流程，建立团队存储库，并完成从前 Rust 领导结构的过渡。