Specs 流程和截止日期¶
Manila spec 仓库是在 Newton 版本中创建的，但没有得到有效利用。许多 specs 没有经过评审，更少的 specs 在发布期间被合并，并且一些具有合并 specs 的功能没有获得代码评审的优先级。
为了确保 specs 能够得到评审，并帮助评审人员集中精力，我建议增加一些官方的截止日期和 specs 处理规则。
问题描述¶
我们有一些具体的问题，有些是 Newton 版本中出现的新问题，有些则随着时间的推移变得更加严重
一些 specs 得到的评审很少，或者根本没有得到评审。
没有理由合并一个 spec，因为我们没有赋予合并 spec 这个动作任何意义，所以大多数 specs 没有被合并。
核心评审团队资源不足，无法评审发布中提出的所有功能。
代码评审发现了架构问题，这些问题本可以在 spec 评审期间发现，并且问题是在发布周期后期才被发现的。
贡献者很难知道他们的更改是否会被合并，直到特性冻结之前，因为我们很少对任何事情说“不”，除非它错过了截止日期。
用例¶
拟议更改的目的是让核心评审团队专注于更少的功能，并让贡献者更早地获得他们的提案反馈。与其有很多成功几率很小的事情，我们更希望有少数成功几率大的事情。
提议的变更¶
首先，我建议定义合并 spec 的含义。在发布期间合并 spec 将意味着
我们对拟议的功能定义感到满意，并且它符合项目的方向和当前发布的目标。
该功能将针对当前发布版本，并将获得代码评审关注和测试。
如果提交者完成了代码并对反馈做出响应，团队打算在特性冻结之前合并完成的功能。
请注意，合并 spec 并不能保证功能的代码会被合并，只是我们会尽力。更重要的是，不合并 spec 意味着我们不打算处理该功能，它将在下一个版本中重新考虑。
接下来，我建议一个 specs 截止日期
低优先级 specs 必须在 milestone-1 日期之前合并。未被认为是高优先级的并且未在 milestone-1 之前合并的 specs 将被从发布考虑范围中排除，以帮助团队集中精力。
高优先级 specs 必须在 milestone-2 日期之前合并。任何未在 milestone-2 日期之前合并的 spec 都将被从发布考虑范围中排除，以帮助团队集中精力。
specs 必须在 milestone-1 之前由团队确定为高优先级。在许多情况下，高优先级 specs 将更早确定，但 milestone-1 将是最终截止日期，以便我们可以开始缩小发布范围。
高优先级 specs 将通过将它们添加到 specs 树中相应发布目录中的名为 high_priority.rst 的索引文件中来指定。对该文件的修改将由 gerrit 控制。
由于合并 spec 将意味着团队将花费足够的时间来评审该功能，因此团队需要限制合并的 specs 数量，即使 specs 满足所有其他合并要求。团队需要优先处理拟议的功能，首先合并优先级较高的功能，并在没有更多可用评审带宽时停止合并 specs。
由于拟议的 specs 数量可能超过整个团队在第一个 milestone 之前合理评审的数量，团队应指定一部分 specs 作为“评审重点”specs，每个人都应评审这些 specs，而其余 specs 将由志愿者进行评审。评审重点 specs 将列在核心评审团队同意的 etherpad 上。
最后，我建议对任何具有广泛影响的更改都需要 specs。在深入实施之前达成设计一致更好。
新的驱动程序和对驱动程序的更改不应需要 specs，因此驱动程序更改不受这些截止日期影响。例外情况是驱动程序中的更改实现了不寻常或有争议的内容，从而需要社区讨论。
决策¶
此 specs 流程需要做出几个决定
specs 的评审重点指定
specs 的优先级排序，包括堆叠排序和低/高优先级指定
合并 specs 的界限
单个 specs 的合并决策
重要的是，参与 Manila 的贡献者对项目方向有影响力，所以我建议 PTL 不要单独做出这些决定，并且决策应尽可能民主地进行（PTL 解决僵局）。
整个社区应就哪些 specs 应该重点评审以及 specs 的优先级提供意见。我们希望致力于对大多数人有价值的事情，因此我们将每周会议和 etherpad 上收集意见，以确定我们应该关注什么。
核心评审团队必须确定界限，因为对评审新功能承诺来自核心评审人员，并且此更改的目标是避免过度承诺。
如果 spec 优先级较低，则单个 specs 的合并应像往常一样进行，需要来自不同公司的两个核心评审人员的 +2 批准；如果 spec 优先级较高，则需要来自大多数核心评审人员的 +2 批准。
将 spec 指定为“高优先级”，从而将合并截止日期从 milestone-1 更改为 milestone-2，应由核心评审团队达成一致，因为此决定会带来额外的评审承诺和增加的风险。
给予“高优先级”specs 更多时间而不是“低优先级”specs 的目的是不是要转移对高优先级事项的注意力，而是要尽早做出将事项从发布中排除的决定。这个过程不能让人们更早地评审 specs 如果他们不倾向于这样做，但我们可以通过在早期划定界限来减少需要评审的 specs 数量，并希望这能更有效地利用我们有限的评审时间。
