TensorFlow RFC 流程

每一个新的 TensorFlow 特性都始于“意见征求”（Request for Comment，简称 RFC）。

RFC 是一份描述需求及解决该需求所需提议变更的文档。具体来说，RFC 应当：

  • 按照 RFC 模板进行格式化。
  • 以拉取请求（Pull Request）的形式提交至 community/rfcs 目录。
  • 在被接受之前，需经过讨论和审查会议。

TensorFlow 意见征求（RFC）的目的是通过获取利益相关者和专家的反馈，并广泛传达设计变更，从而让 TensorFlow 社区参与到开发过程中来。

如何提交 RFC

  1. 在提交 RFC 之前，请与项目贡献者和维护者讨论您的目标，并尽早获得反馈。请使用相关项目的开发者邮件列表（developers@tensorflow.org，或相关 SIG 的邮件列表）。

  2. 起草您的 RFC。

    • 阅读 设计审查标准。
    • 遵循 RFC 模板。
    • 将您的 RFC 文件命名为 YYYYMMDD-descriptive-name.md，其中 YYYYMMDD 为提交日期，descriptive-name 与 RFC 的标题相关。（例如，如果您的 RFC 标题为 Parallel Widgets API，您可以使用文件名 20180531-parallel-widgets.md。）
    • 如果您有图片或其他辅助文件，请创建一个 YYYYMMDD-descriptive-name 形式的目录来存储这些文件。

    在完成 RFC 草案后，请在提交前先从维护者和贡献者那里获取反馈。

    编写实现代码不是必须的，但它有助于设计讨论。

  3. 招募一名发起人（Sponsor）。

    • 发起人必须是该项目的维护者。
    • 在发布 PR 之前，请在 RFC 中明确注明发起人。

    您可以在没有发起人的情况下发布 RFC，但如果在发布 PR 后一个月内仍没有发起人，该 PR 将被关闭。

  4. 将您的 RFC 作为拉取请求提交至 tensorflow/community/rfcs。

    在拉取请求的评论中，使用 Markdown 格式包含头部表格和目标（Objective）部分的内容。有关示例，请参阅 此 RFC 示例。包含合著者、审查者和发起人的 GitHub 用户名。

    在 PR 的顶部说明评论期持续多长时间。这应该是从发布 PR 起至少两周的时间。

  5. 向开发者邮件列表发送电子邮件，包含简要描述、PR 链接以及审查请求。请遵循之前邮件的格式，如您在 此示例 中所见。

  6. 发起人将在 RFC PR 发布至少两周后请求召开审查委员会会议。如果讨论非常热烈，请等待讨论平息后再进行审查。审查会议的目的是解决次要问题；主要问题应事先达成共识。

  7. 会议可能会批准、拒绝 RFC，或要求在重新考虑前进行修改。批准的 RFC 将被合并到 community/rfcs 中，被拒绝的 RFC 的 PR 将被关闭。

RFC 参与者

许多人参与了 RFC 流程：

  • RFC 作者 — 一位或多位编写 RFC 并致力于推动其完成整个流程的社区成员。

  • RFC 发起人 — 一位支持该 RFC 并将在 RFC 审查过程中引导其进行的维护者。

  • 审查委员会 — 一组负责建议采纳该 RFC 的维护者。

  • 任何社区成员都可以通过就 RFC 是否满足其需求提供反馈来提供帮助。

RFC 发起人

发起人是负责确保 RFC 流程取得最佳结果的项目维护者。这包括：

  • 倡导所提议的设计。
  • 引导 RFC 遵循现有的设计和风格规范。
  • 引导审查委员会达成富有成效的共识。
  • 如果审查委员会要求更改，确保这些更改得到执行，并寻求委员会成员的后续批准。
  • 如果 RFC 进入实施阶段：
    • 确保提议的实施符合设计要求。
    • 与相关方协调，成功完成实施。

RFC 审查委员会

审查委员会以共识为基础决定是否批准、拒绝或要求更改。他们负责：

  • 确保公众反馈中的实质性意见已得到考虑。
  • 将会议纪要作为评论添加到 PR 中。
  • 为其决定提供理由。

审查委员会的构成可能根据每个项目的治理风格和领导层而改变。对于核心 TensorFlow，委员会将由在相关领域拥有专业知识的 TensorFlow 项目贡献者组成。

社区成员与 RFC 流程

RFC 的目的是确保社区的利益在 TensorFlow 的新变更中得到充分代表和服务。社区成员有责任参与审查他们感兴趣的 RFC。

对某项 RFC 感兴趣的社区成员应当：

  • 尽快提供反馈，以便有充足的时间进行考虑。
  • 在提供反馈之前彻底阅读 RFC。
  • 保持文明和建设性。

实施新特性

一旦 RFC 获得批准，即可开始实施。

如果您正在编写代码来实现 RFC：

  • 确保您理解该特性以及 RFC 中批准的设计。在开始工作前，请提问并讨论实现方案。
  • 新特性必须包含验证其按预期工作的单元测试。在编写代码之前先编写这些测试是个好主意。
  • 遵循 TensorFlow 代码风格指南。
  • 添加或更新相关的 API 文档。在新的文档中引用该 RFC。
  • 遵循您所贡献的项目仓库中 CONTRIBUTING.md 文件中列出的任何其他指南。
  • 在提交代码之前运行单元测试。
  • 与 RFC 发起人合作，成功落地新代码。

保持高标准

虽然我们鼓励并赞赏每一位贡献者，但 RFC 被接受的标准被刻意设定得很高。新特性可能会在以下任何阶段被拒绝或需要进行重大修改：

  • 在相关邮件列表上进行初步设计讨论时。
  • 未能招募到发起人。
  • 在反馈阶段出现严重反对意见。
  • 在设计审查期间未能达成共识。
  • 在实施期间提出的担忧（例如：无法实现向后兼容，关于维护的担忧）。

如果此流程运行良好，预计 RFC 会在较早阶段而非较晚阶段被否决。已批准的 RFC 并不保证一定会实施，已提议的 RFC 实现在接受前仍需经过常规的代码审查流程。

如果您对该流程有任何疑问，请随时在开发者邮件列表上提问，或在 tensorflow/community 中提交 issue。