Rust RFCs - RFC 手册 - 活跃 RFC 列表

“RFC”（请求意见）流程旨在为 Rust 的变更（例如新功能）提供一条一致且受控的路径，以便所有利益相关者都能对项目的发展方向充满信心。

许多变更，包括错误修复和文档改进，可以通过常规的 GitHub 拉取请求（pull request）工作流来实现和审查。

然而，某些变更是“重大”的，我们要求这些变更经过一定的设计流程，并在 Rust 社区和 [sub-team] 之间达成共识。

目录

• Opening
• Table of Contents
• When you need to follow this process
• Sub-team specific guidelines
• Before creating an RFC
• What the process is
• The RFC life-cycle
• Reviewing RFCs
• Implementing an RFC
• RFC Postponement
• Help this is all too informal!
• License
• Contributions

何时需要遵循此流程

如果你打算对 Rust、Cargo、Crates.io 或 RFC 流程本身进行“重大”变更，则需要遵循此流程。什么构成“重大”变更正基于社区规范不断演变，并取决于你提议变更生态系统的哪个部分，但可能包括以下内容。

• 任何对语言的语义或语法上的更改，且不属于错误修复。
  • 移除语言特性，包括那些受特性门控的特性。
  • 对 std 的大量新增。

某些更改不需要 RFC：

• 重新措辞、重新组织、重构，或者“改变形状但不改变含义”的其他更改。
• 严格改进客观数值质量标准的添加 （移除警告、加速、更好的平台覆盖、更多并行性、捕获 更多错误等。）
• 仅可能被 rust 开发者 注意到的添加， 对 rust 用户不可见。
• 对 std 的次要添加：这些只需要一个 ACP。

如果您提交一个拉取请求来实现一个新特性，而没有经过 RFC 流程，它可能会被礼貌地要求先提交一个 RFC 而关闭。

子团队特定指南

有关以下领域何时需要 RFC 的更多详细信息，请参阅 Rust 社区的 [sub-team] 特定指南：

• 语言更改，
• 库更改，
• 编译器更改。

创建 RFC 之前

仓促提出的 RFC 可能会损害其被接受的机会。低质量的提案、针对此前已被拒绝的功能的提案，或者不符合近期路线图的提案，可能会被迅速拒绝，这可能会让未做准备的贡献者感到沮丧。在 RFC 之前做一些准备工作可以使流程更加顺畅。

虽然为提交 RFC 做准备没有唯一的方法，但通常建议在事先寻求其他项目开发者的反馈，以确定该 RFC 可能是受欢迎的；对项目产生一致的影响需要为建立共识付出协同努力。

撰写和提交 RFC 最常见的准备工作包括在我们的 [official Zulip server] 上讨论该想法，在我们的 [developer discussion forum] 上讨论该主题，以及偶尔在开发者论坛上发布“pre-RFC”。你可以在此仓库中提交 issue 进行讨论，但这些 issue 并未被团队积极关注。

作为一般规则，从长期项目开发者那里，特别是相关 [sub-team] 成员那里收到鼓励性的反馈，是 RFC 值得追求的一个良好迹象。

流程是什么

简而言之，要在 Rust 中添加一个主要功能，必须首先将 RFC 作为 markdown 文件合并到 RFC 仓库中。此时，该 RFC 处于“active”状态，并可以朝着最终纳入 Rust 的目标进行实现。

• Fork the RFC repo [RFC repository]
  • 将 0000-template.md 复制到 text/0000-my-feature.md（其中 "my-feature" 应为 描述性名称）。此时不要分配 RFC 编号；这将是 PR 编号，如果 RFC 被接受，我们将相应地重命名该文件。
  • 填写 RFC。务必注重细节：未能提出 令人信服的动机、未能展示对设计影响的理解，或 对缺点或替代方案不诚实的 RFC 往往 会收到较差的反馈。
  • 提交一个 pull request。作为 pull request，RFC 将收到来自 更大社区的设计反馈，作者应准备好 根据反馈进行修订。
  • 现在你的 RFC 有一个开放的 pull request，请使用 PR 的 issue 编号来重命名文件：将你的 0000- 前缀更新为该编号。同时 更新文件顶部的 "RFC PR" 链接。
  • 每个 pull request 都会被标记上最相关的 [sub-team]， 这将导致该团队在未来的会议中对其进行分诊，并分配 给子团队的成员。
  • 建立共识并整合反馈。获得广泛支持的 RFC 比那些未收到任何 评论的 RFC 更有可能取得进展。请随时联系 RFC 负责人， 以获取帮助识别利益相关者和障碍。
  • 子团队将讨论该 RFC pull request，尽可能在 pull request 本身的评论线程中进行。线下讨论将

在拉取请求的评论线程中总结。

• RFC 很少在不经过修改的情况下通过此流程，尤其是当替代方案和缺点被展示时。你可以对 RFC 进行大小不一的编辑，以澄清或更改设计，但请将更改作为新提交添加到拉取请求中，并在拉取请求上留下评论解释你的更改。 具体而言，在提交在拉取请求上可见后，不要压缩或变基这些提交。
• 在某个时间点，子团队的一名成员将提出“最终评论期”（FCP）动议，并附带 RFC 的处置（合并、关闭或推迟）。
  • 当足够的权衡已被讨论，子团队处于可以做出决定的位置时，会采取此步骤。这并不要求 RFC 线程中所有参与者达成共识（这通常是不可能的）。然而，支持 RFC 处置的论点必须已经清晰阐述，并且在子团队之外不应存在强烈反对该立场的共识。子团队成员在采取此步骤时使用其最佳判断，而 FCP 本身确保了利益相关者有充足的时间和通知来反对，如果该步骤过早采取的话。
  • 对于讨论冗长的 RFC，FCP 动议通常由一个总结评论先行，试图概述当前讨论的状态

以及主要的权衡/分歧点。 - 在实际进入 FCP 之前，所有 子团队成员都必须签署同意； 这通常是许多子团队成员首次深入审阅 RFC 的时刻。

• FCP 持续十个日历日，因此至少开放 5 个工作日。它还会被广泛宣传， 例如在 This Week in Rust。这样所有 利益相关者都有机会在做出决定之前提出任何最后的反对意见。
• 在大多数情况下，FCP 期间是平静的，RFC 要么被合并，要么 被关闭。然而，有时会出现实质性的新论点或想法， FCP 会被取消，RFC 将回到开发模式。

RFC 生命周期

一旦 RFC 变为“active”（活跃）状态，作者即可实现该特性，并向 Rust 仓库提交一个 pull request（拉取请求）。处于“active”状态并不意味着盖了橡皮图章，特别是这并不意味着该特性最终一定会被合并；它意味着原则上所有主要利益相关者都已同意该特性，并且愿意将其合并。

此外，某个 RFC 被接受并处于“active”状态，并不意味着其实现被赋予了什么优先级，也不意味着已指派某位 Rust 开发者负责实现该特性。虽然 RFC 的作者不必亲自编写实现代码，但让 RFC 最终完成的最有效方式无疑是由作者亲自实现：作者不应期望其他项目开发者会承担起实现其已接受特性的责任。

对“active”RFC 的修改可以通过后续的 pull request 进行。我们力求以能够反映特性最终设计的方式编写每个 RFC；但该流程的性质意味着，我们不能期望每个已合并的 RFC 都能准确反映下一次主要版本发布时的最终结果。

通常，一旦 RFC 被接受，就不应对其进行实质性修改。只有非常微小的变更才应作为修订提交。更重大的变更应作为新的 RFC 提出，并在原始 RFC 中添加说明。究竟什么算作“非常微小的变更”由子团队自行决定；请参阅 Sub-team specific guidelines 以获取更多详细信息。

Reviewing RFCs

在 RFC 拉取请求（pull request）处于开放状态期间，子团队可能会安排与作者和/或相关利益相关者的会议，以更深入地讨论相关问题；在某些情况下，该主题也可能在子团队会议上进行讨论。无论哪种情况，会议的摘要都将发布回 RFC 拉取请求中。

子团队在对 RFC 的利弊有充分了解后，会做出最终决定。这些决定可以在任何时间做出，但子团队会定期发布决定。当做出决定时，RFC 拉取请求将被合并或关闭。无论哪种情况，如果从线程讨论中无法明确看出理由，子团队将添加一条评论，描述该决定的依据。

Implementing an RFC

一些已接受的 RFC 代表了需要立即实现的关键特性。其他已接受的 RFC 可以代表可以等待直到某位开发者愿意做这项工作才实现的功能。每个已接受的 RFC 都有一个关联的 issue，用于在 Rust 仓库中跟踪其实现；因此，该关联 issue 可以通过团队用于 Rust 仓库中所有 issue 的 triage 流程分配优先级。

RFC 的作者没有义务实现它。当然，在 RFC 被接受后，RFC 作者（像任何其他开发者一样）欢迎提交实现以供审查。

如果你有兴趣为某个“active” RFC 的实现工作，但无法确定是否已有人在处理，请随时询问（例如，通过在关联 issue 上留下评论）。

RFC Postponement

一些 RFC pull request 在关闭时（作为拒绝流程的一部分）会被标记为“postponed”标签。一个以“postponed”关闭的 RFC 被如此标记，是因为我们既不想考虑评估该提案，也不想考虑实现所描述的功能，直到未来的某个时候，并且我们认为我们可以等到那时再这样做。历史上，“postponed”用于将功能推迟到 1.0 之后。Postponed pull request 可以在时机成熟时重新打开。我们没有正式的流程来处理此事，你应该询问相关子团队的成员。

通常，标记为“推迟”的 RFC 拉取请求已经通过了一轮非正式的初步评估，即“我们是否有可能考虑进行该 RFC 拉取请求中所述的更改，或其某种显而易见的变体。”（如果后者的答案是“否”，则适当的回应是关闭该 RFC，而不是推迟它。）

这太不正式了！

该流程旨在针对当前情况尽可能保持轻量。一如既往，我们试图让流程由共识和社区规范驱动，而不是施加不必要的结构。

许可证

本仓库目前正在申请以下任一许可证：

• Apache License, Version 2.0, (LICENSE-APACHE 或 https://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT 或 https://opensource.org/licenses/MIT)

供您选择。仓库的部分内容已根据上述条款获得许可。更多详情请参阅 RFC 2044 及其 跟踪问题。

贡献

除非您明确声明其他情况，否则您有意提交以包含在作品中的任何贡献，如 Apache-2.0 许可证所定义，将按照上述方式双重许可，不附加任何额外条款或条件。