AIO 公开 RFC 流程

1) 目的与范围

本文档定义了 AIO 的公开 Request For Comment (RFC) 流程，用于提出标准、规范和流程变更。涵盖 RFC 类型、进程阶段、提交与编号约定、许可、审查职责以及相关治理实践。

RFC 流程旨在创建一个开放且可审计的技术与流程提案记录，生态系统内的利益相关者可以对此进行审阅与实施。

2) 文档类型

• Standards Track：规范性规范，定义格式、行为或 API（示例：RBP JSON、BYOR API）。
• Informational：指引、背景信息、用例或说明性材料。
• Process：改变组织或程序规则的提案。

3) 状态进展

RFC 按照以下生命周期推进：Idea → Draft → Candidate (CR) → Final (STD) → Deprecated。

• Draft：公开评审期开始（最低 14 天）。
• Candidate：实现与互操作性验证；准备就绪评审（最低 30 天）。
• Final：在达成共识并获得适用治理批准后成为最终版本。
• Deprecated：在被替代或从推荐使用中移除时标记为弃用。

4) 编号与元数据

• RFC 标识：AIO-RFC-YYYY-NNN（例如：AIO-RFC-2025-001）。
• 必需元数据：标题、摘要、动机、规范、理由、兼容性考虑、安全/隐私考虑、实现说明、IPR/许可、引用文档、变更日志与作者列表。
• 许可：文档正文采用 CC BY 4.0；代码示例采用 Apache-2.0 或 MIT。

5) 提交与发布

• 提交方式：GitHub issue/PR 或 AIO 指定的官方提交机制（优先公开）。
• 所有构件（文本、参考实现、测试向量）应在可行时发布到公共仓库以支持审查与可重复性。

6) 审查与决策角色

• 审稿人：主题专家与工作组提供技术审查并验证主张。
• 工作组 (WG)：负责引导提案至 Candidate 阶段并提供实现指南。
• 社区：公开讨论渠道与 issue 线程为开展开放审查的主要场所。

7) 审查期限与修订

• Draft：至少 14 天的公开审查。
• Candidate：至少 30 天以进行实现验证（经批准可例外）。
• 修订以后缀追踪（例如：-rev1、-rev2）。小幅更正以 Errata 形式发布。

8) IPR 与许可

• 作者授予 AIO 在 CC BY 4.0 下发布文档文本的权利，并在 Apache-2.0 或 MIT 下发布任何参考代码的权利，除非另有说明。
• 贡献者应披露任何专利负担；许可承诺应在 RFC 中明确。

9) 编辑与监管角色

• 总编辑 (Editor-in-Chief)：对 RFC 的整体编辑负责并拥有发布权限。
• RFC 编辑：负责格式、元数据与 RFC 索引维护。
• 工作组：在需要时提供技术审查、测试套件与参考实现。

10) 时间表与变更管理

• 标准时间表（Draft 14 天、Candidate 30 天）为默认；例外需有书面理由。
• 重大更改以版本与变更日志管理；紧急修复可通过 Errata 处理。

11) IPR 与披露

• 贡献者必须申明所贡献材料的权利与许可。如存在第三方权利，须说明状态与许可情况。

12) 附件与 WG 提交

• RFC 可由 WG、委员会或个别贡献者起草或赞助。WG 应在适用时提供审查产物与参考实现。

13) 修订

• 修订记录在文档变更日志中。重大修订应包含变更摘要与动机说明。

14) 与治理的集成

• 涉及组织规则或章程的 RFC 可能需要相应治理机构（例如：大会、董事会）的审查与批准。

15) 利益冲突与回避

• 贡献者与审稿人必须披露利益冲突。如冲突影响决策，应适用回避或其他缓解措施。

16) 数据保护与隐私

• 若 RFC 涉及个人数据，应进行并记录隐私影响评估（DPIA）。

17) 发布规范

• RFC 公开发布；元数据与版本历史保留以确保可追溯性。

18) 许可

• 文档正文：CC BY 4.0。
• 源代码与测试工件：Apache-2.0 或 MIT。

19) 执行与合规

• AIO 员工与相关工作组负责确保发布与存档实践得到遵循。

20) 治理决策

• 治理级决策（例如：将 RFC 采纳为正式标准）遵循章程中规定的表决规则，可能需要合格多数票。

21) 采用与实施

• 工作组或赞助机构负责协调实施与监测采用情况；重大决策应记录并公布。

---

_{Final v1.0}