工作流程

功能/改进的来源

功能或改进的想法通常源于以下几种方式

• 产品工作组收集的用户反馈。
• IRC 或邮件列表的讨论。
• 项目中一个补丁，被认为对其他项目也有益。

如何在 OpenStack 中提出功能/改进

蓝图 (Blueprints)

要正式向 OpenStack 项目提出功能或改进，您需要创建一个蓝图。蓝图允许社区跟踪计划，并可能将其标记到正在开发的发布版本中。跟踪的一些信息包括谁在实施它、当前进度以及 更多

阅读整个流程

项目规范 (Project Specifications)

一些项目在蓝图的基础上更进一步，要求提前提供一组信息，以了解某个计划是否是一个好主意。这些信息可以包括技术信息，例如

• 应用程序编程接口 (API) 影响
• 数据库影响
• 升级影响
• 用户影响

规范信息在不同的 OpenStack 项目中并非标准化的，但您可以访问 https://github.com/openstack/<项目>-specs 来查看项目是否使用规范，并找到其模板文件以了解您需要回答的问题。

请记住，并非所有想法都需要规范，因此请从项目成员处了解某个想法是否需要完整的规范，或者只需要一个蓝图。

阅读整个流程

跨项目规范 (Cross-Project Specifications)

如果一个想法涉及多个项目，则应在 OpenStack Specs 仓库 中提出，而不是项目特定的规范。

参与规范的每个项目都应注册一个蓝图，并且蓝图 URL 应包含在 OpenStack 规范中。

产品工作组联络员的角色 (Product Working Group Liaisons Role)

提出功能/改进 (Introducing A Feature/Improvement)

假设提出功能/改进，取决于可用资源和其他优先级，可能需要在发布一个或两个版本后，与项目团队进行沟通才能开始任何工作。因此，规划和讨论应尽快进行。将分配一名联络员来跨项目监督一个想法，并承担以下责任

1. 创建或让某人创建技术 OpenStack 规范。
2. 抄送参与规范的项目联络员，以引起他们的注意。如有必要，可以通过电子邮件抄送跨项目规范联络员以引起他们的注意。
3. 如果任何规范需要额外的关注，您可以将项目添加到 跨项目会议议程 中，并进行实时讨论。
4. 在跨项目规范中指定 主题分支，用于进行工作。这将允许在 gerrit 中轻松找到所有开发工作，并使用主题过滤器跨不同项目进行筛选。
5. 一旦跨项目规范联络员达成足够的共识，规范将被传递给技术委员会进行批准。

跟踪功能/改进 (Tracking Feature/Improvement)

1. 产品工作组联络员应与参与的每个项目确定谁将实际实施该功能/改进。
2. 在同一版本中与每个实施该功能/改进的项目保持一致是理想的。一些项目可以提前开始，但应将其视为不完整，直到所有必要项目完成实施为止。
3. 产品工作组联络员应继续与每个项目的实施者沟通，以跟踪进度。联络员有责任识别何时出现停滞，并与项目团队合作寻找可以继续工作的人。如果实施者没有回应，应召开与项目团队的会议以寻找新的实施者。