Monasca 项目计划¶
优先级¶
在每个发布周期开始时，我们都会确定整个社区希望关注的下一个发布版本的内容。这是这些讨论的结果
规范¶
您可以在这里找到每个版本的规格和规格模板
还有一些已批准的积压规范，正在寻找负责人
流程¶
规范的生命周期¶
提出规范的开发者应在 approved 目录中提出一个新文件。monasca-specs-core 将以 OpenStack 项目的常用方式审查该更改，并最终在达成共识后合并。作为已批准规范的开发者，您有责任为您的故事分配任务。开发者随后可以提出代码审查以实现他们的规范。为了跟踪目的，这些审查应确保在提交消息中引用 Storyboard 故事和任务。
一旦功能的全部代码合并到 Monasca 中，Storyboard 故事将被标记为完成。
定期地，monasca-specs-core 的某人会将已实现规范从 approved 目录移动到 implemented 目录。虽然各个开发者可以提出将他们已实现的规范移动到该目录，但我们通常在发布周期结束时批量执行此操作。在执行此操作时，创建重定向非常重要，这样可以防止现有链接到已批准规范的链接中断。重定向不是符号链接，它们是在 sphinx 消耗的文件中定义的。
这种目录结构允许您查看我们考虑过要做什么、决定要做什么以及实际完成什么。对给定发布版本的功能感兴趣的用户应仅参考 implemented 目录。
示例规范¶
您可以在 specs/<release_name>-template.rst 中找到一个示例规范。
积压规范¶
此外，我们允许提出没有分配开发者的规范。这些规范以与上述相同的方式进行审查，但被添加到
specs/backlog/approved
此目录中的规范表明原始作者要么无法联系，要么表示他们将不会实现该规范。这里找到的规范可作为人们参与 Monasca 项目的途径。如果您有兴趣认领一个规范，请首先发布一个规范审查，将其从该目录移动到下一个活动发布版本。请将自己设置为新的 主要负责人，并将原始作者保留在 其他贡献者 列表中。
使用 gerrit 和规范单元测试¶
有关使用 gerrit 的更多信息，请参阅 https://docs.openstack.org/infra/manual/developers.html#development-workflow
为了验证规范在语法上是否正确（即，获得更多 Jenkins 结果的信心），请执行以下命令
$ tox
运行 tox 后，文档将以 HTML 格式在 doc/build/ 目录中提供以供查看。
规范审查策略¶
monasca-specs-core 在审查提出的规范时将应用许多审查策略。它们是
琐碎的规范¶
提出的更改非常琐碎（少量代码）并且不更改任何公共 API，有时不需要提供规范。在这种情况下，Storyboard 故事被认为是足够的。这些提案在每周 Monasca IRC 会议的 开放讨论 部分中获得批准。如果您认为您提出的功能是琐碎的并且符合这些要求，我们建议您在编写完整的规范之前将其带到那里进行讨论。
先前批准的规范¶
规范仅被批准用于单个发布版本。如果您的规范先前已被批准但未实现（或未完全实现），则必须重新申请规范的批准。您可以通过以下方式重新提出您的规范
将您的规范复制（不要移动）到当前版本的正确目录。
更新文档以符合新的模板。
如果规范没有功能更改（只有模板更改），则将 Previously-approved: <release> 标签添加到您的提交消息中。
发送进行审查。
monasca-specs-core 将合并满足这些要求的规范，并获得 +2 票。
依赖于合并其他 OpenStack 项目代码的规范¶
对于 依赖于其他 OpenStack 项目合并代码 的规范，我们不会批准 Monasca 规范，直到其他项目中的代码合并。要指示您的规范处于这种状态，请使用 Depends-On git 提交消息标签。正确的格式是 Depends-On: <其他工作的变更 ID>。monasca-specs-core 可以在任何时候批准规范，但它不会合并，直到我们需要在其他项目中着陆的代码也合并为止。
