每个新的 TensorFlow 功能都从一个请求意见书 (RFC) 开始。
RFC 是一份描述需求和解决该需求的建议更改的文档。具体来说,RFC 将
- 根据 RFC 模板 进行格式化。
- 作为拉取请求提交到 community/rfcs 目录。
- 在被接受之前,将接受讨论和审查会议。
TensorFlow 请求意见书 (RFC) 的目的是通过从利益相关者和专家那里获得反馈并广泛传播设计更改,让 TensorFlow 社区参与开发。
如何提交 RFC
在提交 RFC 之前,请与项目贡献者和维护者讨论您的目标,并尽早获得反馈。使用相关项目的开发者邮件列表([email protected] 或相关 SIG 的邮件列表)。
起草您的 RFC。
- 阅读 设计审查标准
- 遵循 RFC 模板。
- 将您的 RFC 文件命名为
YYYYMMDD-descriptive-name.md
,其中YYYYMMDD
是提交日期,descriptive-name
与您的 RFC 标题相关。(例如,如果您的 RFC 标题为 *并行小部件 API*,您可以使用文件名20180531-parallel-widgets.md
)。 - 如果您有图像或其他辅助文件,请创建一个名为
YYYYMMDD-descriptive-name
的目录来存储这些文件。
完成 RFC 草案后,在提交之前请从维护者和贡献者那里获得反馈。
编写实现代码不是必需的,但它可能有助于设计讨论。
招募赞助商。
- 赞助商必须是项目的维护者。
- 在发布 PR 之前,在 RFC 中确定赞助商。
您 *可以* 在没有赞助商的情况下发布 RFC,但如果在发布 PR 后一个月内仍然没有赞助商,它将被关闭。
将您的 RFC 作为拉取请求提交到 tensorflow/community/rfcs。
在您的拉取请求的评论中,使用 Markdown 包含标题表和 *目标* 部分的内容。例如,请参阅 此示例 RFC。包含共同作者、审阅者和赞助商的 GitHub 句柄。
在 PR 的顶部,说明评论期将持续多长时间。这应该从发布 PR 开始的 *至少两周*。
向开发者邮件列表发送电子邮件,简要说明,提供 PR 的链接,并请求审查。遵循以前的邮件格式,如您在 此示例 中看到的。
赞助商将在 RFC PR 发布后至少两周内请求审查委员会会议。如果讨论很热烈,请等到讨论平息后再进行审查。审查会议的目的是解决次要问题;主要问题应事先达成共识。
会议可能会批准 RFC、拒绝 RFC 或要求在再次考虑之前进行更改。批准的 RFC 将合并到 community/rfcs 中,拒绝的 RFC 将关闭其 PR。
RFC 参与者
许多人参与了 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中提交问题。