如何为 Rust 语言做贡献 | Part 2

作者：CrLF0710（野喵）/ 后期编辑：张汉东

大家好，上次讲了如何利用空闲时间参与Rust Project，做一些技术上的参与。这一次呢，我要讲的是如何更加系统的参与Rust Project，相应的，这里讲的内容也需要参与者相应的投入更多的时间、以及更高的门槛。

在开始正式参与之前，我们有必要了解一下Rust Project的组织架构，也就是Rust Team。

Rust 官方团队

Rust Team 由十个Team 构成。每个Team习惯上称为T-XYZ，比如权限最高的Team是核心团队，习惯上写成T-Core。

十个Team(除T-Core外排名不分先后)分别是T-Core, T-Lang, T-Libs, T-Compiler, T-Devtools, T-Crates.io, T-Infra, T-Release, T-Community 和 T-Moderation。所有团队的成员是常驻人员，其实也都是志愿者，成员的选拔主要来自于同一团队其他已有成员的认同。接下来让我们来逐一对各个团队做个介绍。

首先是核心团队T-Core，它的职责是管理Rust Project的总体方向，管理各个Team的领导职责，管理跨团队事务。它是一个没有团队负责人的团队，而且讨论频道是不对外部公众公开的。它出现最多的地方就是，大家会看到那些刊发重大决策的博文都是以核心团队的名义发表的。它的成员往往是其他团队的团队负责人等。

接下来我想首先介绍的是语言设计团队T-Lang，它的职责是设计Rust这门语言。在Rust RFCs被接受的RFC中，语言设计类的RFC到目前为止是占绝对多数的。他们的职责就是讨论语言的未来更改，并且帮忙参与一部分语言特性的实现（参见稍后提到的“项目组”）。平时大家笑谈的“语言律师”就是这些人——对于你的一个设计想法，他们可以飞快地在脑中与语言其他已有特性进行交叉验证，指出你的设计不足……在我的经验里，多多围观他们的讨论对你更深地理解Rust是非常有好处的。

然后是库设计团队T-Libs，它的职责是设计维护Rust的内置库。要注意内置库不止是标准库std，还有core, alloc, test等等。库设计团队的成员们往往都是一些知名rust库的作者，他们在设计API上都是非常有经验的，关注的是接口的易用性等等。实际上Rust的内置库其实从整体上是已经趋于“收敛”了，很难看到较大块的增加，一般都是在一些已有的类型上增加一些小的接口和辅助函数等等。这些接口的稳定化就是由T-Libs来把关的。

接下来是编译器维护团队T-Compiler，它的职责是维护编译器的主体代码。T-Compiler是所有团队中人员最多的团队，以T-Compiler的名义提交的代码占的比重也是最大的。所有已经实现的语言特性相关的代码都是移交给他们来维护的，而对编译器的各种bug的修复、各种诊断帮助信息的用户体验逻辑维护、对编译器的性能优化等等，都是由T-Compiler来进行。这里的任务从简单的“调整一个内部判断条件”，到困难的“实现一个下一代的借用检查器和特质查询系统”，能做的事情有很多很多。

接下来是开发工具团队T-Devtools，它其实是由一堆小团队组成，职责是负责维护cargo、rustdoc、rustfmt、rustup等各种小的程序。每个程序的维护团队其实是相互独立的。这里其实有非常多的贡献机会。

然后是Crates.io团队T-Crates.io，它负责开发维护crates.io网站的前后端，大家上传的开源Rust包都可以集中放到这个网站里。

接下来是运维团队T-Infra，它负责维护Rust的各个网站、crater、CI、域名解析、CDN连接等等的正常运转。

然后是版本发布团队T-Release。与任务导向的T-Compiler不同，T-Release负责按照Rust的发布周期对各个发布版本执行回归测试，定位回归测试中发现的问题、联系T-Compiler进行评估修复。

然后是社区团队T-Community。负责组织Rust相关的活动和会议、管理网站内容、进行社区投票等等。它基本上就可以看作是最近新成立的 Rust 基金会的前身，区别在于新成立的Rust基金会在原来的基础上增加了财务和法务等等的新的责任。

最后是风纪管理T-Moderation。主要负责维持各种交流频道的秩序，维护《行为准则》，管理必要的账号封禁事项等等。

Rust 官方团队里的非正式成员

虽然听起来团队成员数量还不少，但是实际上要推动rust的健康发展，人员力量很容易捉襟见肘。Rust的策略是吸纳更多的非正式成员进来完成工作。其中活跃的人在某种意义上也可以看作是正式成员的候补。

对非正式成员的组织有三种形式：项目组，工作组和社区组。这个划分是之前讨论的，还在试行阶段没有变成正式决策。

项目组(project group)是临时的。例如某个团队想要完成一个新功能的设计与实现，那么就会由该团队的一个成员发起一个项目组，由这个正式成员来带队。这个正式成员负责组织人手和会议，对相关的功能进行推进。

工作组(working group)是较长期的。例如某个团队决定需要一群人来固定推进一些事情，那么同样也会由该团队的一个成员发起一个工作组。这个正式成员负责组织人手和会议，完成既定的任务。

社区组(community group)之前叫做领域工作组，曾经也是工作组概念里的一部分。领域工作组是2017~2018年左右官方推进的一个概念，希望针对一些比较有前景的领域，各自集合一些人来定期讨论，做一些事情，比如写一些代码之类的。第一批成立了四个：网络、嵌入式、WebAssembly、命令行界面。后来又成立了第五个：游戏开发。实践证明，社区工作组这个想法执行起来并不太好，甚至导致了官方和社区的一些矛盾和摩擦。网络领域工作组解散后，官方的态度倾向于将这些领域工作组改编为社区组，不再属于官方团队的一部分。目前是在向这个方向行动，还没有完成。

在这里我们主要关注项目组和工作组。一般来说门槛都是相当低的，一般只需要你在相应小组的频道里简单自我介绍一下，然后按时去参加会议就可以了。但是由于时区的缘故，例会时间往往在北京时间午夜之后，会议语言也一般都是英语。如果你是比较技术导向的，比如希望推进rust的某个特性工作的进展，不妨找到感兴趣的项目组报名参与一下。

Rust 官方工作交流平台

Rust官方交流平台是用一个叫Zulip的软件，网址是rust-lang.zulipchat.com。可以用github登录。这东西有点介于IM与论坛之间，登录之后它有一些频道（称为Stream）。各个团队一般都至少有一个。很多团队也根据需要会为下面的工作组、领域建多个频道。在每个频道里面，任何人都可以建主题，有点像论坛发帖的感觉，然后大家在感兴趣的主题下讨论。它也有手机端app，但是目前还不是很好用；推荐使用网页版或者桌面App。Stream需要订阅才会显示，刚登录的时候显示不全，记得去所有频道面板中订阅自己想关注的频道。

有的团队喜欢开视频会议，它们一般会选Zoom。如果需要协同编辑，往往用Dropbox Papers或者HackMD。大部分都是可以公开访问的，个别的需要申请权限。

在交流时要稍微注意一点的是，关于称呼。欧美有很多人对性别平权、少数群体之类的比较在意。稍微注意下He/She两个词的使用千万不要用错，如果不确定，就用They就好了。

话说，官方 Zulip 里有一个中文频道 t-community/l10n/zh，不过蛮冷清的。大家感兴趣的话可以来聊关于翻译的话题啊。