版本：20240205 更新 说明：此版本为试运行版本，有任何意见欢迎留言或联系我们反馈
SecretFlow 的每一项新功能都从征求意见 (RFC) 开始。 RFC (Request for Comments) 是描述需求与解决需求的建议更改的文档。具体来说，RFC 将：
- 根据 RFC 模板进行格式化。
- 作为拉取请求提交到 secretflow/community/rfcs 目录。
- 在接受之前要经过讨论和审查会议。
SecretFlow 征求意见 (RFC) 的目的是通过从社区成员和专家处获得反馈，并广泛地交流设计变更，从而促进 SecretFlow 社区成员得意见能够更容易被看到以及社区成员们更积极参与感兴趣的开发工作。
- 书写您的 RFC
- 遵循 RFC 模板
- 将您的 RFC 文件命名为 YYYYMMDD-descriptive-name.md，其中 YYYYMMDD 是提交日期，而 descriptive-name 与您的 RFC 标题相关。（例如，如果您的 RFC 标题为 Implement two-party split DCN algorithm，则可以使用文件名 20240104-Implement-two-party-split-DCN-algorithm.md）。
- 如果要提交图像或其他辅助文件，请创建格式为 YYYYMMDD-descriptive-name 的目录来存储这些文件。
- RFC 主要是为了展现设计思路并为讨论提供想法，不需要编写实现代码。
- 将您的 RFC 以 PR 形式提交到 secretflow/community/rfcs
- 文件需使用 Markdown 格式，包括模板中的头部表格和目标部分的内容，包括RFC 作者、实现贡献者、Reviewer 的 GitHub ID，以及评论时间期限，期限应为自 PR 发布后至少两周。
- 发起人将在 RFC PR 发布后的两周内请求召开审查委员会会议。如果讨论过程积极踊跃地提出了问题，请等到问题解决后再进行审查。审查会议的目的是解决小问题；应提前在重大问题上取得共识。
- 会议可以批准或拒绝 RFC，也可以待更改后重新审查。批准的 RFC 将合并到 secretflow/community/rfcs 中， 而 RFC 被拒的 PR 则会被关闭。
- 招募 RFC 实现贡献者
- 您可以在没有 实现贡献者 的情况下发布 RFC，但是如果在发布 PR 的一个月后仍然没有 实现贡献者，则该 PR 将被关闭。
- 您也可以自己作为 RFC 的实现贡献者。
RFC 流程涉及到许多人员：
- RFC 作者：编写 RFC 并致力于在整个流程中推进 RFC 实现的一名或多名社区成员
- RFC 实现贡献者：为 RFC 实现的提供代码贡献的一名名或多名社区成员
- RFC Reviewer：对 RFC 实现的代码内容进行提供审查支持的 Maintainer
- 审查委员会：负责建议是否采纳 RFC 的 Maintainer 与社区成员
- 任何社区成员都可以通过提供有关 RFC 是否满足其需求的反馈来参与该流程
RFC 的目的是确保来自社区关于 SecretFlow 想法（新变更、新功能需求等）更清晰得被表达。社区成员可以参与对其结果感兴趣的 RFC 审查工作。 对 RFC 感兴趣的社区成员应：
- 尽早提供反馈，以留出足够的考虑时间。
- 先通读 RFC，然后再提供反馈。
- 以文明且具有建设性的方式提供反馈。
RFC 一经批准，即可开始实现 RFC。 如果您正在编写用于实现 RFC 的新代码：
- 确保您了解 RFC 中批准的功能和设计。在开始工作之前，提出问题并讨论方法。
- 新功能必须包括新的单元测试，以验证该功能是否按预期工作。建议在编写代码之前先编写这些测试。
- 遵循SecretFlow 代码规范。
- 添加或更新相关的 API 文档。在新文档中引用 RFC。
- 遵循您正在贡献的项目仓库内的 CONTRIBUTING.md 文件所列的任何其他准则。
- 先运行单元测试，然后再提交代码。
- 与 RFC 发起人合作以成功落实新代码。
我们鼓励和感谢每一位贡献者的贡献，但也同时有意地保持着较高的 RFC 接受门槛。在以下任何一个阶段，新功能都可能会被拒绝或要求重大修改：
- 未能招募到实现贡献者。
- 反馈阶段存在重大异议。
- 在设计审查期间未能达成共识。
- 在实现过程中出现问题（例如：无法实现向后兼容性、在维护方面存在疑虑）。
如果流程运行得当，则 RFC 失败情况应发生在早期而非后期。RFC 经批准不能作为承诺实现的保证，并且是否接受建议的 RFC 实现仍受常规代码审查流程的约束。 如果您对此流程有任何疑问，请随时通过在 secretflow/community 中提交问题。