一两个月前，lang 团队启动了一项新举措，我们称之为“积压事项清理大会”(Backlog Bonanza)。这个想法很简单：我们将举行一系列会议，逐一审查每一个待处理的 RFC，并尝试确定如何处理它。完成这项工作后，我们就可以开始对其他形式的积压事项进行分类，例如跟踪问题。

每个 RFC 可能的结果

当我们审查一个 RFC 时，通常会决定以下几种结果之一：

• 关闭该 RFC，如果当前问题优先级不高，或者解决方案与我们期望的相差甚远。
• 关闭，但建议提出项目提案，如果我们认为该问题可能值得解决，但不确定 RFC 的设计是否正确，或者不确定谁是合适的联络人。
• 合并该 RFC，如果我们认为 RFC 基本正确无误，并且我们心中有 lang 团队联络人选。

等等，什么是项目提案？

很高兴您提问了！lang 团队正在尝试一种新的语言扩展流程。想法是，与其先写一个 RFC，不如先从一个项目提案开始。这是一种轻量级的描述，您可以通过在 lang-team 仓库上使用“Project proposal”模板开启一个 Issue 来完成。这将创建一个 Issue 和 Zulip 上相应的讨论流。

在我们每周的分诊会议中，我们会审查每个新的项目提案，并尝试提供反馈。项目提案通常会产生以下几种可能的结果之一：

• 关闭，如果我们觉得这个想法目前不合适。
• 建议实现，如果我们觉得这个想法足够简单或显而易见，无需 RFC。在这种情况下，大家可以直接提交 PR，我们可以使用 fcp 流程批准该 PR。
• 成立项目组，如果我们觉得这个想法不错，但希望看到更详细的设计。为此，需要有一位 lang 团队联络人愿意帮助推进（尽管该联络人不必是团队成员；担任联络人是更深入参与 lang 团队的好途径）。

成立项目组

“项目组”基本上就是一群人在一起完成某个想法。项目组通常规模很小，只有一两个人，但也可能显著扩大。

创建小型项目组旨在轻量化。我们基本上将项目提案转化为一份阐明总体目标的章程，并创建一个相关的 Zulip 讨论流供大家交流。每个项目还会获得一个跟踪 Issue，显示在我们的lang 团队项目看板上。（对于大型项目组，我们可以建立一个专门的仓库并在 Rust 团队仓库中添加条目。）

在一个想法的早期阶段，项目组负责起草 RFC。然后将此 RFC 提交给 lang 团队征求反馈。一旦 lang 团队对方向基本满意，我们将鼓励项目组在主要的 RFC 仓库中开放该 RFC，在那里它将获得更广泛受众的反馈。

一旦 RFC 被接受，希望项目组能继续存在。如果愿意，原班人马可以尝试实现该功能（与编译器团队协作），或者我们可以寻找新的人员。但这样一来，当这些人尝试实现时，他们将成为设计该功能的同一团队的一部分，以便我们能够更容易地迭代。同样的逻辑也适用于发布功能的其他方面，最突出的是编写文档。

跟踪项目：lang 团队项目看板

我在上一段中顺带提到了lang 团队项目看板。这是我们跟踪正在进行的工作的尝试。它将各种项目分解为不同的阶段，最接近发布的项目排在前面：

• 稳定化 -- 准备稳定化或正在稳定化过程中的项目。
• 评估 -- 已完全实现，但我们正在寻求关于设计工作效果反馈的项目。
• 实现 -- 当前正在进行实现工作（有时同时进行设计迭代）的项目。
• 待处理 RFC -- 拥有正在等待公开评论的 RFC 的项目。
• 设计 -- 积极迭代以期形成 RFC 的项目。
• 入围 -- 我们可能希望在找到合适的联络人或大家有足够精力时着手进行的项目想法。

参与方式

如果您愿意，欢迎参加积压事项清理大会会议。这些会议对所有人开放，并在我们每周的设计会议期间举行。不过，我们尚未建立一个很好的流程来公布我们的设计会议时间表，这是我们需要改进的地方。

或者，如果您有想提出的想法，请随时开启一个项目提案。