一两个月前，lang 团队启动了一项名为“积压清理”的新举措。这个想法很简单：我们正在举行一系列会议，逐一审查每一个待处理的 RFC，并尝试就如何处理达成某种决定。一旦我们完成这项工作，我们就可以开始对其他形式的积压进行分类，例如跟踪问题。
每个 RFC 的可能结果
当我们查看一个 RFC 时，我们通常会在以下结果之间做出决定
- 关闭 RFC，如果目前看来该问题并非高度优先，或者解决方案似乎与我们想要的目标相去甚远。
- 关闭，但建议项目提案，如果我们认为我们可能希望看到问题得到解决，但不确定 RFC 的设计是否正确，或者不确定谁会是合适的联络人。
- 合并 RFC，如果我们认为 RFC 基本到位，并且我们心中有 lang 团队的联络人。
等等，什么是项目提案？
很高兴你问了！lang 团队正在尝试一种新的语言扩展流程。不是从编写 RFC 开始，而是从项目提案开始。这是一个轻量级的描述，你可以通过在 lang-team 仓库上使用“项目提案”模板打开一个 issue 来完成。这将创建一个 issue 和 Zulip 上的相应流。
在我们的每周分类会议中，我们会审查每一个新的项目提案并尝试提供反馈。项目提案通常会导致以下几种可能的结果之一
- 关闭，如果我们觉得这个想法目前不太合适。
- 建议实施，如果我们觉得这个想法足够简单或显而易见，不需要 RFC。在这种情况下，人们可以直接编写 PR，我们可以使用 fcp 流程来批准 PR。
- 组建项目组，如果我们觉得这个想法不错，但我们希望看到设计被详细阐述。为此，必须有一些 lang-team 的联络人愿意协助完成（尽管该联络人不必是团队成员；作为联络人是更多参与 lang 团队的好方法）。
组建项目组
“项目组”基本上就是一组人一起完成某个想法。项目组通常很小，只有 1 或 2 人，尽管它们可能会变得更大。
创建一个较小的项目组是为了轻量化。我们基本上将项目提案转换为说明总体目标的章程，并创建一个相关的 zulip 流，供人们聊天。每个项目还有一个跟踪 issue，显示在我们的lang 团队项目看板上。（对于较大的项目组，我们可以在 Rust 团队仓库中创建一个专用仓库和一个条目。）
在想法的早期阶段，项目组致力于起草 RFC。然后将此 RFC 提交给 lang 团队征求反馈。一旦 lang 团队基本满意事情的进展方向，我们就会鼓励小组在主 RFC 仓库中打开 RFC，在那里它将获得更广泛的受众的反馈。
一旦 RFC 被接受，希望项目组能够继续存在。如果需要，同一批人可以尝试实现该功能（与编译器团队合作），或者我们可以找到新的人。但是，这样一来，当这些人尝试实现时，他们将成为设计该功能的同一小组的一部分，以便我们可以更轻松地进行迭代。同样的逻辑也适用于交付功能的其他方面，最值得注意的是编写文档。
跟踪项目：lang 团队项目看板
我在上一段中顺便提到了lang 团队项目看板。这是我们跟踪正在进行的工作的尝试。它将各种项目分解为不同的阶段，最接近发布的项目排在前面
- 稳定化 -- 我们准备稳定或正在稳定过程中的项目。
- 评估 -- 已完全实施但我们正在寻求关于设计效果如何的反馈的项目。
- 实施 -- 目前正在进行实施（有时是同步设计迭代）的项目。
- 待定 RFC -- 有待公开评论的 RFC 的项目
- 设计 -- 积极迭代以实现 RFC 的项目
- 入围 -- 一旦我们找到合适的联络人或人们有足够的带宽，我们可能想要进行的潜在项目想法
参与方式
如果您愿意，欢迎您参加积压清理会议。它们对任何人开放，并且在我们每周的大部分设计会议期间举行。但是，我们还没有建立一个很好的流程来宣布我们的设计会议时间表，这是我们需要改进的地方。
或者，如果您有想提出的想法，请随时打开项目提案。