ProductTeam/Development Proposals
开发提案
产品工作组使用开发提案（以前称为“用户故事”）讨论提案，包括内部和外部讨论。开发提案使用位于 标准模板 创建，该模板位于 产品 WG 仓库。 提案和最终实施开发提案的过程如图 1.1 所示。关于产品 WG 开发提案的主要信息来源是我们的 规范页面。
这个 分类法 详细说明了产品 WG 映射到敏捷术语的情况。
开发提案流程
该流程涵盖开发提案的提案、完善、接受和实施。任何人都可以将开发提案发布到仓库中的 proposed 文件夹 中。
差距和重叠分析
一旦开发提案的概念得到验证，并且与其他提出的开发提案的任何重叠/冲突得到解决，团队必须进行技术差距和重叠分析。开发提案所有者和技术专家将与需要开发提案产生的蓝图/规范的项目中的 CPSL（跨项目规范联络员）安排跨项目概念审查会议。团队将利用这次会议来验证方法/概念，确定是否需要根据项目内部的先前工作推迟任何提出的开发提案，以及根据结果的最佳推进方式。
实施计划
差距分析会议的结果是实施计划。实施计划不是必需的工件，可以通过口头方式传达或捕获在其他工件中（例如开发提案优先级或开发提案跟踪器）。实施计划的目标是就给定开发提案的下一步骤达成一致，无论这些步骤包括创建项目级别的规范/蓝图、跨项目规范或新的 OpenStack 项目。
开发提案的可能状态
Proposed（提议）： 开发提案首先作为补丁提交到仓库的此位置。在此阶段，开发提案将根据模板进行验证（例如，所有强制部分都已正确填写），并且该概念也将使用 gerrit 注释进行讨论。作者/所有者还应提交新的补丁集以根据讨论完善开发提案。在团队认为该概念得到验证后，该更改不会被合并（例如，在 规范页面 上可见）。
Cross Project Spec Created（跨项目规范已创建）： 一旦开发提案准备好供社区讨论，开发提案所有者将提交更改到 跨项目规范仓库，并在“proposed”文件夹中更新开发提案，其中包含指向跨项目规范审查的链接。开发提案所有者还将使用 开发提案跟踪器模板 创建一个初始 开发提案跟踪器，仅完成与开发提案相关的字段。
Cross Project Spec Accepted（跨项目规范已接受）： 这表示开发提案现在已成为一个接受的（合并的）跨项目规范，并准备好进行实施计划（包括组件级别的蓝图以及与项目团队的沟通）。在此阶段，开发提案所有者将在“proposed”中更新开发提案，以包含指向实际跨项目规范的链接（替换之前阶段输入的“review”链接）。开发提案跟踪器也应更新，以包含与跨项目相关的字段以及可用时项目级别的规范/蓝图信息。
开发提案的流转条件
Development Proposal Idea（开发提案想法） -> Proposed Change/Patch（提议的更改/补丁）： 任何人都可以将开发提案提交到此文件夹，这是开发提案的起点。
Review Proposed（审查提议） -> Merge Proposed（合并提议）： 开发提案必须满足模板标准（例如，所有强制部分已完成），并且该概念已通过 gerrit 审查过程由产品 WG 完善。
Merged Proposed（合并提议） -> Cross Project Spec Change/Patch（跨项目规范更改/补丁）： 此时必须确定开发提案所有者，他们负责创建跨项目规范提交。开发提案所有者还将在提议的开发提案的单行更改中将“cross project spec link:”更改为“ready to submit”，这表示产品 WG 该开发提案即将提交给技术社区/跨项目团队进行审查。开发提案所有者还必须创建开发提案的初始跟踪器，以便 OpenStack 社区可以跟踪开发提案的后续状态。
