• 开始日期: 2018-06-28
• RFC PR: (请留空)
• 跟踪问题: (请留空)

在 Rust 和 WebAssembly 领域工作组中采用 Rust RFC 流程的简化版本。RFC 流程将为所有利益相关者提供一个统一的平台，以决定整个生态系统中的重大变更和新增内容。

有一些决策会对 Rust 和 WebAssembly 生态系统产生广泛的影响，因此有许多利益相关者应该参与决策并对提案和设计提供反馈。目前，这些决策往往是在本地仓库的 pull request 或问题跟踪器中进行的。这使得利益相关者难以跟上这些决策，因为他们需要关注许多不同的位置。对于仓库所有者或团队来说，也很难确定生态系统是否支持某个功能。

在采用此 RFC 流程后，利益相关者应该更容易跟上生态系统中的重大变更和功能。此外，Rust 和 WebAssembly 生态系统中特定仓库的维护者应该确信，他们在经过 RFC 流程后，已经从所有相关人员那里征求了反馈，并且不会收到来自认为没有被咨询的用户发来的愤怒的错误报告。每个人都应该对生态系统的发展方向充满信心。

目前，rustwasm 组织内仓库的治理 遵循这些规则，描述了合并 pull request 的策略。

除非另有说明，每个 rustwasm/* 仓库都有以下一般策略。

• 所有 pull request 必须由至少一位相关团队成员或仓库合作者审查并批准，才能合并。

• 关于设计、架构、重大变更、权衡取舍等方面更大、更细致的决策由相关团队和/或仓库合作者达成共识。换句话说，对那些不是对项目中已存在的事物的直接改进或错误修复的决策。

此策略将 pull request 分为两种类型：更大、更细致的变更或非此类变更（我们将在后面使用“重大”一词）。当变更不重大时，只需要一位团队成员批准即可。当变更更大、更重大时，相关团队将就如何进行达成共识。

此 RFC 旨在进一步细化重大变更，将其分为仅影响仓库本身维护的变更（因此仅对维护者而言是重大的），以及对外部用户和更广泛的 Rust 和 WebAssembly 社区产生影响的重大变更。对于内部重大变更，我们不打算改变当前策略。对于对外部产生影响的重大变更，我们将采用 Rust RFC 流程的轻量级版本。

如果您打算对 rustwasm 组织 中的任何仓库或 RFC 流程本身进行外部重大变更，则需要遵循 RFC 流程。什么是“重大”变更，是根据社区规范不断发展的，并且根据您提议更改的生态系统部分而有所不同，但可能包括以下内容。

• 删除或对广泛使用的公共 API 进行重大变更。
• 以新方式扩展公共 API 的公共 API 新增内容（即不仅仅是“我们为 ThisThing 实现 SomeTrait，所以也为 RelatedThing 实现 SomeTrait”）。

有些变更不需要 RFC。

• 改写、重组、重构或其他“改变形式不改变意义”的变更。
• 严格提高客观、数值质量标准的添加（警告消除、加速、更好的平台覆盖范围、更多并行性、捕获更多错误等）。
• 仅可能被其他维护者注意到的添加，并且对用户保持不可见。

如果您提交 pull request 来实现新功能，但没有经过 RFC 流程，它可能会被关闭，并礼貌地要求您先提交 RFC。

• Fork RFC 仓库。
• 将 000-template.md 复制到 text/000-my-feature.md（其中“my-feature”是描述性的。不要先分配 RFC 编号）。
• 填写 RFC。仔细考虑细节：没有提供令人信服的动机、没有证明对设计影响的理解、或对缺点或替代方案不诚实的 RFC 往往会不受欢迎。
• 提交 pull request。作为 pull request，RFC 将从更广泛的社区获得设计反馈，作者应该准备好根据反馈进行修改。
• 每个新的 RFC pull request 都将在下一个 Rust 和 WebAssembly 领域工作组会议中进行分类，并分配给一个或多个 @rustwasm/* 团队。
• 达成共识并整合反馈。得到广泛支持的 RFC 比没有收到任何评论的 RFC 更有可能取得进展。请随时联系 RFC 分配者，以获得帮助识别利益相关者和障碍。
• 团队将讨论 RFC pull request，尽可能地在 pull request 本身的评论线程中进行讨论。线下讨论将在 pull request 评论线程中进行总结。
• RFC 很少会在这个过程中保持不变，尤其是在展示了替代方案和缺点之后。您可以对 RFC 进行大小不同的编辑，以澄清或更改设计，但将更改作为 pull request 的新提交，并在 pull request 上留下评论解释您的更改。具体来说，在提交在 pull request 上可见后，不要压缩或变基提交。
• 在某个时候，子团队的成员将提出“最终评论期（FCP）动议”，以及 RFC 的处置（合并、关闭或推迟）。
  • 当已经讨论了足够多的权衡取舍，团队能够做出决策时，将采取此步骤。这并不需要 RFC 线程中所有参与者达成共识（这可能是不可能的）。但是，支持 RFC 处置的论点需要已经明确阐述，并且在团队之外，不应该存在强烈反对该立场的一致意见。团队成员在采取此步骤时会运用自己的最佳判断，而 FCP 本身确保了利益相关者有足够的时间和通知，如果 FCP 过早提出，他们可以进行反驳。
  • 对于讨论时间较长的 RFC，提出 FCP 动议之前应该有一个总结评论，试图阐述当前讨论的状态以及主要的权衡取舍/分歧点。
  • 在真正进入 FCP 之前，所有团队成员都必须签字；这通常是许多团队成员第一次全面审查 RFC 的时候。
• FCP 持续七个日历日。它也会在广泛的范围内进行宣传，例如在 "Rust 和 WebAssembly 周报" 的 Rust 和 WebAssembly 博客 中。这样，所有利益相关者都有机会在做出决定之前提出任何最终异议。
• 在大多数情况下，FCP 期间是安静的，RFC 也会被合并或关闭。但是，有时会提出重大的新论点或想法，FCP 会被取消，RFC 会重新进入开发模式。

一旦 RFC 被合并，它就成为“活跃的”，然后作者就可以实现它，并将功能作为 pull request 提交到相关仓库。成为“活跃的”并不意味着盖章批准，特别是并不意味着功能最终会被合并；它意味着原则上所有主要利益相关者都同意该功能，并且愿意合并它。

此外，某个 RFC 被接受并且是“活跃的”这一事实，并不意味着对其实现分配了优先级，也不意味着是否已分配开发人员来执行该功能。虽然作者不需要也编写实现，但这是让 RFC 完成的最有效方式：作者不应该期望其他项目开发人员承担实现他们已接受的功能的责任。

对“活跃的”RFC 的修改可以在后续的 pull request 中进行。我们努力以反映功能最终设计的方式编写每个 RFC；但流程的本质意味着我们不能期望每个合并的 RFC 在下一个主要版本发布时都能真正反映最终结果。

一般来说，一旦被接受，RFC 不应该被大幅更改。只有非常小的更改应该作为修正案提交。更重大的更改应该作为新的 RFC 提交，并在原始 RFC 中添加注释。

决策的设计空间非常大，从民主到专制，不一而足。

Fork 和简化 Rust 的 RFC 流程是切实可行的。与其从头开始设计决策流程，不如采用一个现有的、运作良好的流程，并根据我们的需要进行调整。许多 Rust 和 WebAssembly 利益相关者已经熟悉它。

与 Rust RFC 流程的主要区别在于

• FCP 持续七个日历日，而不是十个。这反映了我们希望采用更轻量级的流程，比 Rust 的 RFC 流程更快地进行。
• RFC 模板更短，并将 Rust RFC 模板中原本独立的部分合并到单个部分中。同样，这反映了我们希望采用更轻量级的流程，我们不需要像 Rust RFC 有时那样进行如此细致的描述（也许除了这个 RFC）。

RFC 开发和 RFC 后实现的阶段与 Rust RFC 流程基本相同。我们发现，Rust RFC 流程中几乎每个阶段的动机对于 Rust 和 WebAssembly 领域来说同样具有激励作用。我们预计会大幅简化阶段，例如，我们最初考虑删除 FCP，直接进入签署接受 RFC 或不接受 RFC 的阶段。但是，FCP 作为一种方式，可以 (1) 允许利益相关者表达尚未提出的任何最终担忧，以及 (2) 帮助执行“没有新理由”规则。这两点同样适用于 Rust 和 WebAssembly 领域工作组和生态系统，就像它们适用于 Rust 本身一样。

我们也可以避免采用 RFC 流程，通过允许每个仓库的团队或所有者成为他们生态系统角落的独裁者，从而更快地进行。但是，这会导致有价值的反馈、意见和见解得不到表达，并导致做出狭隘的决策。

• 我们会使用 @rfcbot 吗？如果可以，我们可能应该使用，但这可以与是否接受此 RFC 分开决定。

• 如何最好地宣传新的 RFC 和 FCP？我们应该让“本周 Rust 和 WebAssembly”真正成为每周一次，而不是每两周一次吗？FCP 长度和 TWiRaWA 帖子频率之间的互动似乎很重要。