Specification Repository Backlog Refactor¶
https://blueprints.launchpad.net/sahara/+spec/add-backlog-to-specs
本文档提出重构 sahara-specs 仓库，以支持新的积压功能工作流。新的工作流将提高已批准但需要实施的规格文档的可见性。
问题描述¶
目前，sahara-specs 仓库建议为每个发布版本创建“已实施”和“已批准”子目录。这种模式可能会创建重复和/或空目录，因为为先前版本批准但尚未完成的计划会被根据需要移动和复制。
此外，这种模式可能会增加新贡献者寻找可工作功能和项目未来方向的障碍。通过为所有积压的规格文档提供一个统一的位置，将提高对需要关注的项目可见性。并且发布目录可以完全用于在这些周期中实施的规格文档。
提议的变更¶
此更改将在仓库的 specs 目录中添加一个 backlog 目录，并重构 juno 目录，使其仅包含在 juno 中实施的规格文档。
它还将更新文档，以清楚地说明 backlog 目录的使用以及发布目录的状态。此文档将包含在根 readme 文件中，backlog 目录中的一个新文档中，以及主文档中的一个引用。
此更改还提出了一种与仓库更改相伴随的工作流。具体来说，任何在发布周期内预计无法分配人员，或者在发布周期结束时未启动的工作都应移动到 backlog 目录。此过程应由规格文档起草者指导，因为他们很可能是新工作的首要负责人。在起草者认为缺乏足够的资源来创建实施方案时，他们应将已批准的规格文档移动到 backlog 目录。还应在发布周期结束时重新评估此过程，以将所有未分配的规格文档移动到 backlog。
替代方案¶
保持当前目录结构不变。这并不能改善仓库的状态，但可以考虑作为一种选择。如果目录结构保持当前配置，则发布目录需要为每个周期的未完成工作创建额外的结构。
为每个发布目录重构一个 backlog。这与保持现状非常相似，唯一的区别在于它更改了目录中的名称。此更改可能会增加少量说明，但可能性不大，因为当前“已实施”和“已批准”的名称相对容易理解。
数据模型影响¶
无
REST API 影响¶
无
其他最终用户影响¶
无
部署者影响¶
无
开发者影响¶
主要影响在于规格文档起草者需要更加了解实施拟议更改所需的资源。并可能根据这些要求移动他们的规格文档。
Sahara-image-elements impact¶
无
Sahara-dashboard / Horizon 影响¶
无
实现¶
负责人¶
- 主要负责人
mimccune (Michael McCune)
工作项¶
创建 backlog 目录和文档。
清理 juno 目录。
在贡献文档中添加 backlog 引用。
依赖项¶
无
测试¶
无
文档影响¶
应更新“如何参与”文档，以引用 backlog 目录作为寻找新工作的地方。
参考资料¶
Keystone 是另一个使用这种格式进行积压工作的项目示例。Backlog 目录文档[1]和根文档[2]的示例将用作参考，以创建 Sahara 特定的版本。
[1]: https://github.com/openstack/keystone-specs/tree/master/specs/backlog [2]: https://github.com/openstack/keystone-specs
