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