RFC 最佳实践

本文档提供了有关作者和审核者如何充分利用 RFC 流程的指南。

将 RFC 视为设计文档

Fuchsia 项目根据 RFC 流程做出决策。某些 RFC 包含在整个项目中采用某些政策的决定。例如,RFC-0004 指定存储空间大小应以 IEC 表示法提供(例如KiB,而不是 KB)。该 RFC 被接受后,我们作为一个项目决定遵循该政策。不过,这些政策设置 RFC 相对较少。

大多数 RFC 本质上都是设计文档。如果设计文档 RFC 被接受,则意味着我们作为一个项目决定以某种方式解决问题。可接受的 RFC 是一种历史文档,其中记录了对该设计有利的每个人都可以自如地进行后续处理。

专注于获得用户认可

在撰写 RFC(或任何有关这一点)时,问问自己:“我为什么要写这个?”

假设您之所以编写 RFC,是因为您想要更改某些内容,但您认为您的更改可能会对项目的其他成员产生影响。在继续操作之前,您需要确保用户知道您的计划以及他们不介意执行的操作。可能会受此变更影响的人是您的利益相关方。当他们为您的 RFC +1 并被接受后,系统会为您生成一条书面记录,说明他们对您的更改感到满意。满怀信心地继续!

让此目标引导您 RFC 的内容:

  • 突出设计中需要利益相关方支持的方面。例如,利益相关方使用的接口比实现更重要。
  • 阐明设计的含义。如果您的利益相关方需要努力了解设计对他们的影响,审核将会很慢,并且其中很有可能会在实现过程中与您联系,说“这不是我同意!”
  • 务必清晰说明您的提案。例如,您的 RFC 可以包含有关设计将如何工作的承诺,以及它如何工作的说明示例。它可能会通过按原样描述系统以及完成实现后系统如何运行的要求来提供背景信息。以便利益相关方轻松分辨数据。您不希望利益相关方看到您原本打算要求提供的建议。

提供合适的详细信息

您的 RFC 无需指定设计的所有细节。事实上,过多细节可能会让利益相关方更难以理解设计的基本权衡。另一方面,如果您没有提供足够的详细信息, 不同的读者可能会对您的 RFC 含义得出不同的结论。 找到合适的细节级别是一门艺术。

您的 RFC 应包含对设计的可接受性有重大影响的所有详细信息,而不应包含其他内容。这些内容足以让利益相关方认可您的设计,并方便未来的读者了解设计获批的原因。附带详情只是会使 RFC 难以审核。

审核期间,部分 RFC 会变得越来越详细。这可能会令作者和利益相关方等人员感到沮丧。当利益相关方询问(或反对)设计的某个部分时,您的本能可能是添加更多详细信息作为澄清或理由。在开始之前,请考虑移除详细信息是否更合适。如果他们评论的部分对 RFC 没有实质性影响,您可以删除大量讨论或让讨论更笼统、更抽象,从而缩短大量讨论内容。

为了帮助确定某些细节是否对您的设计具有实质性影响,请考虑以下问题:

  • 如果你更改了这项细节,是否有人会因此而将投票从 +1 改为 -1?
  • 如果此细节的实现方式与所写内容不同,可以吗?您的利益相关方希望了解这一变化吗?
  • 是否有必要立即确定此细节?让实现人员及其代码审核人员进行通话是否更好?

为未来读者着想

利益相关方是 RFC 的主要受众,但不要忘记,未来的读者会尝试在接受您的设计后了解该设计。以下是关于让更多受众访问您的 RFC 的一些提示:

  • 假设利益相关方第一次通过 RFC 听到您的设计。请提供(或链接到具有)足够背景的文档,以便将您的 RFC 说明放在上下文中。
  • 假设利益相关方仅通过 RFC 获知您的设计。您和您的利益相关方可能会通过电子邮件、聊天、会议或至少是代码审核注释来讨论 RFC。未来的读者无法轻松访问这些对话,因此请确保 RFC 的文本包含您在带外模式下得出的所有重要结论。
  • 使用稳定的链接。如果“背景信息”链接出现大幅变化或变为 404 错误,您的 RFC 会更难以理解。请尽可能链接到文档的特定修订版本,以便未来读者能够看到您看到的相同页面。

请勿使用 RFC 作为文档

一旦接受,您的 RFC 就会记录您的利益相关方对您设计的功能感到满意的事实。不过,不应将其用作功能本身的文档。

RFC 和文档的目的不同:

  • 文档需要随着系统的变化而不断更新,但 RFC 被接受后便不应再进行更改(次要修正除外)。
  • RFC 可以向利益相关方证明为什么该设计可靠且比替代方案更可取,这对用户来说可能没有太大帮助。
  • 文档提供了精确的过程示例来说明如何使用该功能,这需要比较详细的信息,对利益相关方没有太大帮助。

请勿在代码或文档中链接到 RFC 说明功能的工作原理。为该功能提供专属文档,并改为提供指向文档的链接。

关于放置此类文档的一些建议:

  • 使用详细的文档注释添加有关特定 API 或代码模块的文档。
  • fuchsia.git 中创建 //src/my_subsystem/docs/ 子目录。fuchsia.git 中托管的文档可以由 Gitiles 呈现,非常适合用于为子系统提供概念性指南。
  • 将您的文档添加到 fuchsia.dev(如果它对更广泛的 Fuchsia 社区有帮助)。

另外,RFC 可以链接到文档。事实上,如果您的 RFC 包含大量背景信息,请考虑将该背景移到文档中并链接到该文档中!

更新以下最佳实践

如果您对最佳做法有建议(或者您认为上述某些建议可能适合使用更新),请联系 eng-council@fuchsia.dev 或将更改发送给 FEC!