关于编译器团队

rustc 由 Rust 编译器团队 维护。这个团队的成员共同跟踪性能退化问题、实现新特性。 Rust 编译器团队的成员由为 rustc 和它的设计做出重大贡献的人们组成。

讨论

目前编译器团队在两个地方讨论：

• Zulip 实例 的 t-compiler 流
• rust-lang discord 的 compiler 频道

专家地图

如果您有兴趣搞清楚谁可以回答关于编译器某个特定领域的问题，或者您只是想知道谁在做这方面的工作， 来看看我们的 专家目录。 它包含了一份编译器各部分的列表，以及每个部分的专家列表。

Rust 编译器会议

编译器团队每周举办一个周会，我们在会上对问题进行分类，并聚焦在新的 bugs、性能退化和其它一些问题。 会议的总体计划在rust 编译器会议 etherpad。大致如下：

• 评审 P-high bugs： P-high bugs 对我们非常重要，需要积极跟踪进度。 在理想情况下，P-high bugs 总是要分配给一个受托人。
• 检查新的性能退化： 我们接着找出编译器破坏原本可以正常工作代码的案例。 性能退化几乎总是被标记为 P-high；主要的例外是修复 bug（尽管我们经常会首先给出警告）
• 检查 I-nominated 问题： 这些问题需要来自团队的反馈。
• 检查 beta-nominations： 这些是被提名回退到 beta 状态的事情。

会议目前在波士顿时间每周二上午10点举行（通常是UTC-4时区，但是夏时制有时会带来混乱）。

会议通过“聊天媒体”举行，目前在zulip

团队成员资格

Rust 团队的成员资格通常提供给长期为编译器做出重大贡献的人。 成员资格既是一种承认，也是一种义务： 编译器团队成员通常需要帮助进行日常维护，以及进行评审和其它工作。

如果您有兴趣成为编译器团队成员，首先从修复 bug 开始，或者参与一个工作组的工作。 发现 bug 的一个好方法是寻找使用 E-easy 标签的开放问题 或者E-mentor 标签.

r+ 权限

一旦您为 rustc 提交了一些独立的 PRs，我们通常会给您授予 r+ 特权。 这意味着您有权力指导“bors”（管理哪些 PR 合并进入 rustc 的机器人）合并一个 PR （这里是如何与 bors 对话的一些指令）

评审人的指导方针如下：

• 欢迎您随时查看任何 PR，不论它被指派给谁。然而，不包括 r+ 的 PR，除非：
  • 您对那部分代码有自信。
  • 您确信没有人想要首先评审它。
    • 例如，人们有时会表达在合并一个 PR 之前评审的愿望， 可能是因为它和代码中特别敏感的部分有关。
• 在评审的时候始终保持礼貌：您是 Rust 项目的代表， 因此，当涉及到[行为准则]时，人们期望您能做得更好。

[行为准则]： https://www.rust-lang.org/policies/code-of-conduct

high-five

一旦您拥有了 r+ 权限，您也可以被加入到 high-five 的自动流程中。 high-five 是负责分配新的 PR 给评审人的机器人。 如果您已经加入，您将会被随机抽选为评审人。 如果您觉得分配给您的 PR 您不喜欢评审，您可以留下一个评论 r? @某人 来把它分配给别人 - 如果您不知道请求谁，就写 r? @nikomatsakis 来重新分配，@nikomatsakis 会为您指派一个人。

进入 high-five 名单是非常受欢迎的，因为它降低了我们所有人的评审门槛！ 然而，如果您没有时间对人们的 PR 进行及时的反馈，也许您不出现在名单上更好。

完整的团队成员资格

一旦有人长期为 Rust 编译器做出很多贡献，他通常会扩展到完整的团队成员资格， 理想情况（但不一定）是多个领域。有时，这可能是实现一个新特性， 但同样很重要 - 也许更重要的是 - 有时间和意愿帮助进行日常维护， 比如修复 bug，追踪性能退化，和其它不那么有吸引力的工作。