# 关于Rust项目、国际社区和发展动向的一些笔记

笔记内容更新于：2025-05-20

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

- [**Rust Foundation**][rust-foundation] （Rust 基金会）是一个非盈利社会组织。基金会为Rust语言的发展而服务，主要提供类如基础设施、赞助，以及和产业、生态的合作等，还有法律方面的支持（例如商标、版权等）。
- [**Rust Project**][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*](https://borrowed.dev/p/on-ongoing-work-in-the-rust-compiler-team)

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

相关讨论：

- [Rust Project and the Rust Foundation](https://hackmd.io/xGLUBwyARDez--36661Pxg)
- [Add initial onboarding notes](https://github.com/rust-lang/rust-forge/pull/846)

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

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

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

> **例子**
>
> [编译器（Compiler）团队][compiler-team]下的副团队之一[rust-analyzer团队][rust-analyzer-team]，但是：
>
> - 成员上：两个团队成员并非子集关系
> - 决策上：编译器团队不能代替rust-anlyzer团队做rust-analyzer的决策，rust-analyzer团队也不能代替编译器团队做rustc的决策。
>
> 而[rust-analyzer团队][rust-analyzer-team]又自己有一个贡献者团队[rust-analyzer contributors team][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*][rfc-3599]。

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

- [all-hands-2025 > Meeting notes!](https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/Meeting.20notes!/with/518703083)
- [all-hands-2025 > team processes and policies session](https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/team.20processes.20and.20policies.20session/with/518411326) 和 [All Hands - Team Processes and Policies](https://hackmd.io/s-Fba-nISB25llCLBvt-gw)
- David Wood: [*On team processes and policies*](https://borrowed.dev/p/on-team-processes-and-policies)
- [Rust Project and the Rust Foundation](https://hackmd.io/xGLUBwyARDez--36661Pxg)
- [Lang / Compiler: Understanding and improving collaboration](https://hackmd.io/@rust-compiler-team/S1vUItVWgg)
- [all-hands-2025 > Project scope MCP?](https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/Project-scope.20MCP/with/503576755)

相关讨论：

- [lang > Lang MCPs?](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Lang.20MCPs/with/518125060)

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

### 领导议会（Leadership Council）

领队议会团队主要负责审议决定涉及多个团队的决策（特别是事由超出单一团队职责范围的情况）以及解决团队之间可能有的分歧。详见 [RFC 3392: *形成领队议会 Leadership Council*](https://rust-lang.github.io/rfcs/3392-leadership-council.html#modifying-and-tuning-the-decision-making-process)。

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

> 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 语言及其工具链的具体部分。


#### 对于部分团队的描述

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

##### 社区管理员团队（Mods Team）

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

- 确保所有参与贡献、讨论的人遵循[Rust 行为准则（Code of Conduct）](https://www.rust-lang.org/policies/code-of-conduct)。
- 负责维护社区、仓库等秩序。

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

维护范围：

- Mods 主团队维护Rust zulip、各个 `rust-lang/*` 仓库的秩序，以及线下官方活动的秩序。
- Discord Mods Team 负责维护 Rust。
- Discourse Mods Team 负责维护Rust Discord、[Rust Internals](https://internals.rust-lang.org/) 以及 [Rust Users Forum](https://users.rust-lang.org/)。

##### 标准库团队（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）][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）或者移至其他顶层团队下或者解散。

相关讨论：

- <https://github.com/rust-lang/leadership-council/issues/159>
- <https://github.com/rust-lang/leadership-council/issues/118>
- <https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/.22Rust.20Society.22.20Session/with/518467911>

##### 编译器团队（Compiler Team）

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

- 编译器主团队也负责审议“编译重大改动动议”（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] 的团队。bors主要负责实现review权限管理、[rollup]等功能。
- 发布团队（release）：专门维护[发布流程][release-process]的团队。特别要提到的是发布团队负责维护向后移植（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][ucg]）以及协助维护[Rust语言标准（Reference）][reference]。
- 语言标准团队（Spec）：负责维护[Rust语言标准（Reference）][reference]、确保新的语言功能稳定化之前在Reference中有所描述、Reference描述的语言功能有对应的rustc测试。
- 语言风格团队（Style)：设计并维护Rust语言的官方风格标准，并与rustfmt团队协调实现。

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

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

- 领导议会决定[逐渐废除工作组（Working Groups）这一形式](https://github.com/rust-lang/leadership-council/issues/91)
- 项目组（Project Groups）概念目前不明确，未来可能和项目目标（Project Goals）联系在一起，但目前一般都是一个团队（Team）中小部分团队成员组成的
- 此外，领导议会[计划重构 Launching Pad这个“给不知道放哪里的团队、项目组、工作组一个临时的家”的顶层团队](https://github.com/rust-lang/leadership-council/issues/170)。

其中：

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

完整的Rust 组织关系图：


### 额外相关讨论

- David Wood: [*On the shape of the Rust project*](https://borrowed.dev/p/on-the-shape-of-the-rust-project)
- David Wood: [*On team processes and policies*](https://borrowed.dev/p/on-team-processes-and-policies)

## 一些Rust相关国际社区团体

- [嵌入式设备工作组 Embedded Devices Working Group][rust-embedded]
- [Rust for Linux](https://rust-for-linux.com/): 在linux内核外围驱动中实验性地使用Rust语言，并且协调上游参与语言、编译器、工具链功能方面的设计与实现工作
- 实验性的GCC代码代码生成后端: <https://github.com/rust-lang/rustc_codegen_gcc>
- 实验性的Cranelift代码生成后端：<https://github.com/rust-lang/rustc_codegen_cranelift>
- 谷歌的Fuchsia团队: <https://fuchsia.dev/>
- 模型检测：[kani](https://github.com/model-checking/kani), [verify-rust-std](https://github.com/model-checking/verify-rust-std)
- 以及今年的[contracts和标准库模型检测](https://rust-lang.github.io/rust-project-goals/2025h1/std-contracts.html) 项目目标
- Rust GPU: <https://rust-gpu.github.io/>，以及相关[autodiff 和 offloading](https://rust-lang.github.io/rust-project-goals/2025h1/GPU-Offload.html) 项目目标
- Bevy 引擎：<https://bevyengine.org/>
- [Max Planck Institute](https://www.mpi-sws.org/research-areas/programming-languages-and-verification/) 有相关研究团队（RustBelt等）
- [cargo-semver-checks](https://github.com/obi1kenobi/cargo-semver-checks)
- 但是rustdoc团队已经正式邀请其主要维护者加入维护团队，所以理论上不太算项目外的社区项目了
- 我们和C++标准委员会有协作，比如[Rust和C++的跨语言交互](https://rust-lang.github.io/rust-project-goals/2025h1/seamless-rust-cpp.html)的项目目标
- 适合工具分析的稳定MIR(StableMIR)相关团体，参考[StableMIR](https://rust-lang.github.io/rust-project-goals/2025h1/stable-mir.html)项目目标
- [RustSec](https://rustsec.org/)、[cargo-audit](https://github.com/rust-secure-code/cargo-auditable)
- 谷歌开源之夏(Google Summer of Code): <https://summerofcode.withgoogle.com/programs/2025/organizations/the-rust-foundation>

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

- 编译器、标准库方向：[rust-lang/rust]有标有`E-easy`或者专门有维护者愿意提供指导`E-mentor`的issues。此外，很多设计面向用户的文档issues也是适合初学者的贡献。
- 可以参考<https://rustc-dev-guide.rust-lang.org/#easy-or-mentored-issues>.
- <https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20label%3AE-easy>
- 部分 <https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20label%3AE-mentor>
- 部分 <https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20label%3AE-help-wanted>
- cargo：<https://github.com/rust-lang/cargo/issues?q=is%3Aissue%20state%3Aopen%20label%3AE-easy>
- rustfmt: <https://github.com/rust-lang/rustfmt/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22>
- clippy: <https://github.com/rust-lang/rust-clippy/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22>
- bors: <https://github.com/rust-lang/bors/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22>
- triagebot: <https://github.com/rust-lang/triagebot/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22>
- rust-analyzer:
- <https://github.com/rust-lang/rust-analyzer/issues?q=is%3Aissue%20state%3Aopen%20label%3AE-easy>
- <https://github.com/rust-lang/rust-analyzer/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22>

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

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

- [rust-lang/rust] 里有多个编译器、语言功能因为种种原因造成实际实现与一开始的设计有较大出入，但是其Tracking Issue有很多讨论但是没有现状的概括。社区贡献者可以帮助概括目前现状，以及自起初设计以来的设计、实现改动。特别是缺乏共识的相关设计、实现问题。
- <https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20label%3AS-tracking-needs-summary>
- 协助测试非稳定功能（语言、工具、编译器、标准库等等）并提供有关错误报告
- （如有能力）帮助撰写语言功能的Reference文档
- （如有能力）改进相关功能的错误报告
- 参与相关功能的讨论
- （如有能力）撰写语言、编译器功能[稳定化报告（Stabilization report）](https://github.com/rust-lang/rustc-dev-guide/pull/2219)
- 编译器功能稳定化报告样例：[使稳定版编译器在`x86_64-unknown-linux-gnu`目标平台上默认使用`lld`](https://github.com/rust-lang/rust/pull/140525)
- 语言功能稳定化报告样例：[Stabilize `cfg_boolean_literals`](https://github.com/rust-lang/rust/pull/138632#issue-2926765646)
- 类型系统+语言功能稳定化报告样例：[Stabilize `#![feature(precise_capturing_in_traits)]`](https://github.com/rust-lang/rust/pull/138128#issue-2901424863)
- （如有能力）实现已经批准稳定的API稳定化
- 标准库API样例：[Stabilize `const_vec_string_slice`](https://github.com/rust-lang/rust/pull/137319)
- 标准库API保证更改样例：[Promise `array::from_fn` is generated in order of increasing indices](https://github.com/rust-lang/rust/pull/139099)

请注意：我们还在[改进语言功能的标准化流程、健壮性评估](https://github.com/rust-lang/rustc-dev-guide/pull/2219)。

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

## Rust 项目目标（Project Goals）

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

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

详见<https://github.com/rust-lang/rust-project-goals>以及[2025H1的项目目标](https://rust-lang.github.io/rust-project-goals/2025h1/index.html)。

### 旗舰项目目标简介

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

1. 减少async Rust和sync Rust之间的开发舒适度差距：特别是async fn in traits、改进Pin的舒适度、支持同异步生成器（generators）语言功能
- <https://rust-lang.github.io/rust-project-goals/2025h1/async.html>
2. 为Rust for Linux推进一些语言、编译器、工具功能的稳定化工作
- <https://rust-lang.github.io/rust-project-goals/2025h1/rfl.html>
- [Target Modifiers](https://github.com/rust-lang/rust/issues/136966)
- [在特定Tier 1平台稳定化部分Sanitiziers](https://github.com/rust-lang/rust/pull/123617)
- [`arbitrary_self_types`](https://github.com/rust-lang/rust/issues/44874)

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

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

## Rust项目相关文档

- <https://www.rust-lang.org/learn>
- [Rust语言手册](https://rust-lang.org/book/)
- [Rustlings](https://github.com/rust-lang/rustlings/)
- [rust-by-examples](https://doc.rust-lang.org/rust-by-example/)
- [标准库文档](https://doc.rust-lang.org/std/index.html)：
- 稳定版：<https://doc.rust-lang.org/std/index.html>
- beta：<https://doc.rust-lang.org/beta/std/index.html>
- nightly：<https://doc.rust-lang.org/nightly/std/index.html>
- [编译器错误代码序列](https://doc.rust-lang.org/error_codes/error-index.html)
- [rustc 手册](https://doc.rust-lang.org/rustc/what-is-rustc.html)
- [Rust 语言标准（Reference）](https://doc.rust-lang.org/reference/index.html)
- [Rustonomicon](https://doc.rust-lang.org/nomicon/)
- [Edition 指南](https://doc.rust-lang.org/edition-guide/index.html)
- [cargo 手册](https://doc.rust-lang.org/cargo/index.html)
- [cargo 代码文档](https://doc.rust-lang.org/nightly/nightly-rustc/cargo/)
- [cargo 贡献指南](https://doc.crates.io/contrib/)
- [clippy lints序列](https://rust-lang.github.io/rust-clippy/)
- [clippy 贡献指南](https://github.com/rust-lang/rust-clippy/blob/master/CONTRIBUTING.md)
- [rustdoc 手册](https://doc.rust-lang.org/rustdoc/)
- [rustdoc 贡献指南](https://rustc-dev-guide.rust-lang.org/rustdoc.html)
- [rustfmt 手册](https://rust-lang.github.io/rustfmt/?version=v1.8.0&search=)
- [rustfmt 贡献指南](https://github.com/rust-lang/rustfmt/blob/master/Contributing.md)
- [rustup 手册](https://rust-lang.github.io/rustup/)
- [rustup 贡献指南](https://rust-lang.github.io/rustup/dev-guide/)
- [非稳定功能文档（Unstable book)](https://doc.rust-lang.org/nightly/unstable-book/index.html)
- [标准库开发指南（std-dev-guide）][std-dev-guide]
- [编译器开发指南（rustc-dev-guide）][rustc-dev-guide]
- [编译器、部分工具、支持库的内部文档](https://doc.rust-lang.org/nightly/nightly-rustc/index.html)
- 注：这个没有具体维护的人，只是rustdoc自动生成的内部含`--document-private-items`的文档

## 机器人和集成测试

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

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

#### rust-lang/rust的机器人

有两个社区贡献者会使用到的机器人；具体请参考[rustc-dev-guide 编译器贡献指南](https://rustc-dev-guide.rust-lang.org/contributing.html)。

- [triagebot](https://forge.rust-lang.org/triagebot/index.html)：使用方法参考<https://forge.rust-lang.org/triagebot/index.html>。这个机器人负责标签管理（使得社区贡献者也能调整大部分标签）、自动PR reviewer分配等等、重新分配reviewer（例如`r? compiler`） 等
- [bors](https://forge.rust-lang.org/infra/docs/bors.html)：使用方法参考<https://forge.rust-lang.org/infra/docs/bors.html>。这个机器人负责权限管理(r+)、[rollup](https://rustc-dev-guide.rust-lang.org/tests/ci.html?highlight=rollup#rollups)等

#### rust-lang/rust的集成测试

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

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

详见[rustc-dev-guide关于测试的部分](https://rustc-dev-guide.rust-lang.org/tests/intro.html)。

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

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

- 一部分库、工具、文档仓库使用[josh](https://github.com/josh-project/josh)同步，由相关工具、文档团队负责用`josh`进行的同步。例如：`rustc-dev-guide`、`miri`等。
- 还有一部分库、工具、文档仓库仍然使用git submodules，如[Reference](https://github.com/rust-lang/reference)等。

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

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

相关讨论：

- [*Rust project stuff that kinda sucks*](https://hackmd.io/5n97FexORfiOjhFShK9HpA?view)

[^team-consensus]: 取决于某个决策是否重大、是否影响稳定版本、是否可逆，又可分为”简单支持“（如Compiler Major Change Proposal "Second"并没有反对或担忧）或“团队共识”（一般为Final Comment Period形式）
[^open-source-governance]: 这部分是“开源社区治理”（Open-Source Governance)
[^team-tool]: https://github.com/jieyouxu/rust-project-structure
[^edition]: 我不确定适合Edition的翻译

[rust-foundation]: https://rustfoundation.org/#initiatives
[rust-project]: https://www.rust-lang.org/governance
[rust-embedded]: https://github.com/rust-embedded/wg
[top-level-teams]: https://www.rust-lang.org/governance
[compiler-team]: https://www.rust-lang.org/governance/teams/compiler#team-compiler
[rust-analyzer-team]: https://www.rust-lang.org/governance/teams/compiler#team-rust-analyzer
[rust-analyzer-contributors-team]: https://www.rust-lang.org/governance/teams/compiler#team-rust-analyzer-contributors
[rfc-3599]: https://github.com/rust-lang/rfcs/pull/3599
[rust-lang/team]: https://github.com/rust-lang/team/
[std-dev-guide]: https://std-dev-guide.rust-lang.org/
[rustc-dev-guide]: https://rustc-dev-guide.rust-lang.org/
[rust-lang/rust]: https://github.com/rust-lang/rust
[bors]: https://forge.rust-lang.org/infra/docs/bors.html
[rollup]: https://forge.rust-lang.org/release/rollups.html
[release-process]: https://forge.rust-lang.org/release/process.html
[triagebot]: https://github.com/rust-lang/triagebot
[ucg]: https://github.com/rust-lang/unsafe-code-guidelines/
[reference]: https://doc.rust-lang.org/reference/introduction.html
[gsoc]: https://summerofcode.withgoogle.com/