< 返回版块

关于 Rust 项目、国际社区和发展动向

苦瓜小仔 发表于 2025-05-21 20:15

该文章由 Rust compiler、bootstrap、infra 团队成员许杰友 ( https://github.com/jieyouxu ) 撰写。

Rust Foundation 基金会、Rust 项目以及 Rust 社区的关系

  • Rust Foundation （Rust 基金会）是一个非盈利社会组织。基金会为Rust语言的发展而服务，主要提供类如基础设施、赞助，以及和产业、生态的合作等，还有法律方面的支持（例如商标、版权等）。
  • Rust Project （Rust 项目）由几百个贡献者组成的多个项目团队组成，每个团队负责围绕Rust语言的具体部分，如标准库、编译器、工具链等等。
  • Rust Community 泛指使用Rust的群体。有些群体为他们感兴趣的目标形成了他们自己的组织，比如Rust for Linux （RfL）等。

需要重点指出的是，Rust 项目的贡献者主导语言及其官方维护的工具链发展，Rust基金会不参与日常项目运作和决策。当然，两者属于相辅相成的关系，比如如果Rust项目贡献者有版权方面的问题，我们会去问基金会雇佣的法律顾问。

Rust 项目的组织架构

前言：开源组织和商业组织的重大区别

如果要理解目前Rust项目组织结构是如何演变成现在这样的，我们首先要考虑到 Rust 项目自2010年左右从完全由Mozilla工程团队维护逐渐演变为主要由志愿开源贡献者维护。目前，各个Rust团队中有不同公司雇佣的全职或部分工时为开源工作的成员，但是团队决策中需要团队统一共识，其中大部分为志愿贡献者。这意味着Rust的各个团队以及项目层面在管理方法不能简单的像商业管理（例如领队发布任务、队员执行任务等，或简单设置优先级），而更像是一种自下而上的支持（Support）组织关系

团队组织结构支持团队成员和社区贡献者去实现他们想要实现的改动

可以参考编译器团队领队David Wood关于这种“自下而上”的组织结构关系的思考：On ongoing work in the Rust compiler team

一般团队领队负责确认或否决重要决策，但是团队决策依然要求团队成员共识[^team-consensus]。

相关讨论：

顶层团队、主副团队之间的结构关系以及决策关系

在前言我们讲到现在的Rust 项目基本由志愿贡献者组成而没有简单的“上下级”关系，在 Rust 项目主团队与副团队也并非简单的上下级关系：

  • "Top-level team"（顶层团队）意义主要体现在一个顶层团队以及其多个副团队在领导议会（Leadership Council）中共同有一个议会代表（Council Representative）。目前顶层团队有：Compiler, Dev Tools, Infrastructure, Language, Launching Pad, Library, Moderation。
  • 主团队及副团队（rust-lang/team 里的结构）也不是上下级关系

例子

编译器（Compiler）团队下的副团队之一rust-analyzer团队，但是：

  • 成员上：两个团队成员并非子集关系
  • 决策上：编译器团队不能代替rust-anlyzer团队做rust-analyzer的决策，rust-analyzer团队也不能代替编译器团队做rustc的决策。

而rust-analyzer团队又自己有一个贡献者团队rust-analyzer contributors team，区别在于贡献者团队不参与rust-analyzer的重大决策（可以视为“实习”队员）。

编译器（Compiler）团队本身又不太一样，编译器团队所有队员都参与Major Change Proposal（重大改动请求）、向后移植（back port）申请的审议，但是又分为：

  • Maintainers（维护者）身份（普通队员持续贡献一年以上、积极维护某个或多个方向的）
  • FCP决策副团队：自愿、能够及时审阅涉及编译器的 Request for Comments (RFC) 以及涉及编译器团队的Final Comment Period （FCP）团队决策的部分维护者

关于编译器团队目前这个组织结构，详见 RFC 3599 Re-organize the compiler team。

在今年的 All Hands，大家也讨论了这些不同团队之间决策方法、组织架构不一致对于不同社区贡献者造成的疑惑，相关讨论：

相关讨论：

相关组织结构仍会随着项目贡献者的需求演化[^open-source-governance]。

领导议会（Leadership Council）

领队议会团队主要负责审议决定涉及多个团队的决策（特别是事由超出单一团队职责范围的情况）以及解决团队之间可能有的分歧。详见 RFC 3392: 形成领队议会 Leadership Council。

领导议会团队成员（称为“议会代表”）由每个顶层团队的一名成员经团队内选举产生作为“议会代表”，每届领导议会任期一年。

Council representatives’ terms are one year in length. Each representative has a soft limit of three consecutive full terms for any given representative delegation (the delegation from a particular top-level team).

Rust 项目现有团队以及对于部分团队的描述

Rust 项目现有团队

以下为根据 rust-lang/team 权限配置仓库生成的关系图^team-tool，列出了Rust 项目现有团队（Team），不包括项目组（Project Group）或者工作组（Working Group）。每个团队负责维护Rust 语言及其工具链的具体部分。

Rust项目目前有的团队

对于部分团队的描述

请悉知：这部分仅限于我有大概了解的部分团队，并非覆盖所有团队。这些描述也不一定完整、具体，只能提供个大概。具体请参考相关团队自己维护的文档、或可询问相关团队。

社区管理员团队（Mods Team）

社区管理员团队；主团队和其副团队主要负责：

可参考https://github.com/rust-lang/moderation-team.

维护范围：

  • Mods 主团队维护Rust zulip、各个 rust-lang/* 仓库的秩序，以及线下官方活动的秩序。
  • Discord Mods Team 负责维护 Rust。
  • Discourse Mods Team 负责维护Rust Discord、Rust Internals 以及 Rust Users Forum。
标准库团队（Libs Team）

标准库团队负责维护标准库的API（设计、稳定承诺、演化、保证等）、稳定承诺、平台支持、可靠性、测试、实现等等。

维护范围：

  • 标准库主团队（Library team）：涉及标准库的重大改动以及实现方面的决策；标准库文档以及实现的审阅。
  • 标准库API团队（Library API team）：涉及标准库API的设计、提供的保证（其实现以及文档）、新稳定/非稳定API带来的regression（例如类型推断regression）评估以及补救措施。
  • 标准库贡献值团队（Library contributors team）：给标准库持续贡献一定时间后经标准库主团队题名后的贡献者；标准库文档以及实现的审阅
  • regex 和 crate-maintainers 团队：维护的一些官方GitHub组织下的仓库crates（例如regex、libc等）。

可参考https://github.com/rust-lang/libs-team/以及标准库开发指南（std-dev-guide）.

Launching Pad（《不知道放哪里所以临时放这里》的备用顶层团队）

没其他合适的顶层团队所以把一些团队、PGs、WGs临时放这里的备用顶层团队。这个顶层团队只是为了确保有个议会代表，并不做日常中的决定（由其副团队做其负责的相关方面的决策）。

副团队维护范围：

  • 各个社区（Community）团队：负责维护特定的官方通讯方式、媒体存在、年度调查、线下活动组织等等
  • Edition 团队^edition：专门维护各个Edition的区别、对下一个Edition的相关lints、需要的改动、Edition迁移辅助、迁移文档等等，审议决定某个语言改动是否能进入下一个Edition版本。
  • Goals 团队：维护Rust 项目目标（Project Goals）相关程序
  • Mentorship 团队：维护管理Rust项目参加的开源指导项目（例如谷歌开源之夏、中科院开源之夏等）
  • 其他团队我接触不多，故在此不做描述

注意：部分Launching Pad下的团队、WGs、PGs以后可能衍化成一个“Rust 社区”（Rust Society）或者移至其他顶层团队下或者解散。

相关讨论：

编译器团队（Compiler Team）

编译器主团队负责维护 rustc 编译器的设计、实现，以及rustc 开发指南。其副团队中：

  • 编译器主团队也负责审议“编译重大改动动议”（Major Change Proposals (MCP)）。详见https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#proposals.
  • 编译器运维 （compiler-ops） 团队：主要负责编译相关issues的“分诊”（triage）、每周分诊会议日程准备、评估regression严重级、确保涉及编译器改动的PR被即使审阅、确保涉及编译器的提名问题和PR（nominated issues/PR）被团队注意到并且及时讨论等等。详见https://forge.rust-lang.org/compiler/operations.html。
  • 编译器重大动议审议团队（compiler-fcp）：由编译器主团队的部分想要参与的维护者（Maintainers）组成，审议需要编译器团队决策的、需要Final Comment Period（FCP；10天的最终评论时期并且无显著反对才能通过的动议）的动议。
    • 例如稳定化编译器的选项、有显著编译器支持部分的语言功能稳定化进程
    • 审议并且通过、拒绝或决定延迟涉及编译器的 Request For Comments（RFC）
    • 审议并且通过、拒绝或决定延迟提升或降级某个编译器支持的目标平台（例如原本是第一维护等级（Tier 1）目标平台的32位Windows MSVC目标平台支持降级为第二维护等级）
  • rust-analyer主团队 （rust-analyzer）以及其副团队 rust-analyzer贡献者团队（rust-analyzer contributors）维护rust-analyzer工具以及审阅涉及rust-analyzer改动的rust-lang/rust PR。两者主要区别是主队进行涉及rust-analyzer的决策。
  • 类型系统（types）团队和类型系统重大动议团队（types-fcp）类似编译器主团队和编译器重大动议审议团队的区别。类型系统团队专门负责维护编译器的 trait solver 的设计以及其实现、以及审阅涉及类型系统的重大改动请求（Types MCP）、RFC。
    • 类型系统团队更像是编译器团队和语言团队两个团队维护范围的并集但专注于类型系统。

编译器团队相关决策过程、批准过程等等可以在https://forge.rust-lang.org/compiler/proposals-and-stabilization.html找到。

开发工具团队（Dev Tools）

开发工具主团队（Dev Tools）主要负责协调不同官方维护的Rust开发工具（如cargo、clippy、rustfmt等）之间的合作。其副团队中：

  • 每个clippy、cargo、rustfmt、rustup等官方维护的工具有其专门维护副团队
  • 文档生成器rustdoc的维护团队分为rustdoc主团队（负责维护rustdoc本身以及其rustdoc-json）和rustdoc前端副团队（rustdoc-frontend）
  • 测试开发者体验团队（testing-devex）负责维护、设计、实现Rust工具链中测试相关工具和库，例如涉及libtest的设计、以及新一代的测试框架
基础设施团队（Infra）

基础设施团队负责维护Rust语言相关基础设施，比如持续集成测试、发布、网站基建维护等等。Infra主团队主要负责rust-lang/rust本身和Rust工具链的持续集成测试、发布。副团队中：

  • 搭建系统团队（bootstrap）：专门负责rust-lang/rust本身搭建编译器、标准库、工具链、文档等等的搭建系统。
  • infra-bors：专门维护rust-lang/rust和其他少数rust-lang/*组织下使用 bors 机器人 的团队。bors主要负责实现review权限管理、rollup等功能。
  • 发布团队（release）：专门维护发布流程的团队。特别要提到的是发布团队负责维护向后移植（backport）的流程。
  • triagebot团队：专门负责维护triagebot机器人。triagebot帮助实现标签管理、reviewer自动分配、改动提醒等功能。具体功能用法详见https://forge.rust-lang.org/triagebot/index.html.
语言团队（Lang）

语言团队负责维护Rust语言的设计与标准化。主团队负责审阅涉及语言功能、语言相关保证、语言功能稳定化相关的改动的PR和RFC等，以及评估并管理相关语言实验（Lang Experiments）。其副团队中：

  • 语言文档团队（lang-docs）：负责协调语言相关文档的统一性、涉及语言文档的相关决策。
  • 语言建议团队（lang-advisors）：专精某些语言方面、给语言主团队提供语言设计、实现相关建议的团队
  • 语言运维团队（lang-ops）：类似编译器运维团队，但专门服务语言主团队，负责准备语言主团队的设计、triage会议日程、评估涉及语言设计方面的问题、评估涉及语言方面的regressions、协调给语言主团队提名的PR/问题的优先级。
  • 形式化的操作语义团队（opsem）：负责设计、维护Rust语言的形式化的操作语义标准（以及rustc对于其的实现）。特别是维护围绕unsafe的语义定义（例如维护Unsafe Code Guidelines）以及协助维护Rust语言标准（Reference）。
  • 语言标准团队（Spec）：负责维护Rust语言标准（Reference）、确保新的语言功能稳定化之前在Reference中有所描述、Reference描述的语言功能有对应的rustc测试。
  • 语言风格团队（Style)：设计并维护Rust语言的官方风格标准，并与rustfmt团队协调实现。

可参考https://lang-team.rust-lang.org/.

非团队（Team）组织：工作组（Working Groups）和项目组（Project Groups）？

其中：

  • Triage 工作组 (WG-triage)：参与issues和PR的“分诊” —— 帮助把issues和PR分给对的人或团队、调整issue标签、以二分法找到一个regression是由什么改动造成的、寻找到最小完整可复现的样本（Minimal, Complete and Verifiable Example (MCVE)）等等。
    • 对于社区贡献者来说，参与”分诊“（triage）工作是容易入手的方向之一

完整的Rust 组织关系图：

Rust 组织关系图

额外相关讨论

一些Rust相关国际社区团体

如何寻找到适合初学者的贡献？

如何帮助语言、编译器、工具等功能的稳定化？

有多项社区贡献者可以帮助的工作项：

请注意：我们还在改进语言功能的标准化流程、健壮性评估。

  • 其中，如果有语言、编译器功能目前设计上、实现健壮性状态不清的，撰写标准化报告之前应询问语言团队/编译器团队以确保相关功能维护者认为其设计、实现、测试、工具链支持足够健壮。

Rust 项目目标（Project Goals）

每半年一轮的项目目标。由项目内或社区贡献者提出希望相关团队支持的项目目标。其中：

  • 项目目标提出者（或提出团队）列出需要相关团队支持的具体事项（例如专门的reviewer或需要相关团队做决定的）
  • 相关团队经评估通过后向相关项目目标提供优先审阅、决策支持
  • 项目目标提出者可向基金会（Foundation）申请半年期的项目目标赞助（Project Goal Grants）
  • 项目目标提出者可向基础设施团队（Infra）申请远程开发桌面（Dev Desktops）使用权限
  • 请注意：项目目标通过后不一定会实现！项目目标旨在为项目提出者/团体提供相关团队的支持以及优先，但相关团队不能代替实现（除非有相关成员愿意自行帮助实现）。具体实现依然需要项目提出者/团体自己（或者委托的社区实现者）进行。

详见https://github.com/rust-lang/rust-project-goals以及2025H1的项目目标。

旗舰项目目标简介

这里主要描述两个旗舰项目

  1. 减少async Rust和sync Rust之间的开发舒适度差距：特别是async fn in traits、改进Pin的舒适度、支持同异步生成器（generators）语言功能
  2. 为Rust for Linux推进一些语言、编译器、工具功能的稳定化工作

谷歌开源之夏 (Google Summer of Code)

Rust项目连续两年参加了谷歌开源之夏 (Google Summer of Code (GSoC))。GSoC 2025项目：https://summerofcode.withgoogle.com/programs/2025/organizations/the-rust-foundation。

Rust项目相关文档

机器人和集成测试

具体使用哪些机器人和具体集成测试取决于哪个rust-lang/*仓库。

rust-lang/rust的机器人和集成测试

rust-lang/rust的机器人

有两个社区贡献者会使用到的机器人；具体请参考rustc-dev-guide 编译器贡献指南。

rust-lang/rust的集成测试

rust-lang/rust中的集成测试分为两个：PR检查和完全合并前检查:

  • PR检查：代码风格、小部分快速测试等
  • 完全合并前检查：对于所有一级支持等级（Tier 1）宿主平台（host platform）的全套标准库、编译器测试，大部分工具链的测试；对于部分二等支持等级（Tier 2）目标平台（target platform）的跨平台测试

详见rustc-dev-guide关于测试的部分。

josh, rust-lang/rust 与其他 rust-lang/* 仓库之间的同步

有些库、工具、文档仓库（例如cargo、clippy、rustfmt、miri、rustc-dev-guide等）需要与主仓库（rust-lang/rust）间隔性同步：

  • 一部分库、工具、文档仓库使用josh同步，由相关工具、文档团队负责用josh进行的同步。例如：rustc-dev-guide、miri等。
  • 还有一部分库、工具、文档仓库仍然使用git submodules，如Reference等。

具体是否使用josh还是git submodules由相关团队自行决定，Rust项目层面没有推荐使用josh的决策。

贡献时容易遇到的一些令人不愉快的障碍

相关讨论：

[^team-consensus]: 取决于某个决策是否重大、是否影响稳定版本、是否可逆，又可分为”简单支持“（如Compiler Major Change Proposal "Second"并没有反对或担忧）或“团队共识”（一般为Final Comment Period形式）

[^open-source-governance]: 这部分是“开源社区治理”（Open-Source Governance)


Ext Link: https://hackmd.io/@jieyouxu/S12xbnVWle

评论区

写评论

还没有评论

1 共 0 条评论, 1 页