如何为Bugzilla 3.0.x中的错误/功能建模状态“需要讨论”

Question

在我们的小组中，我们必须为Bugzilla建立状态“需求讨论”。

因此，引入了自定义已解决 - 待讨论状态。相应的一组人员会搜索具有此类“解决方案”状态的问题，并讨论这些离线。

在我看来，这是不正确的方法，因为如果仍然需要讨论，错误/功能显然无法解决。这也反映在standard life cycle of a bug中。这有点误导，因为“需要讨论”项目会显示在已解决的错误列表中。

我能想到的一种方法是制作一种“虚拟用户”，代表必须参与讨论的小组。这样做的好处是，人们可以轻松地搜索错误。还可以设置邮件列表来通知用户。

我想知道如何在Bugzilla 3.0.x中对这个需要讨论错误状态进行适当的建模。 （而且：什么是Mozilla方式的解决方案？）

Answer 1

与任何软件系统一样，有多种方法可以满足您的需求。

在开始使用机制之前，最好考虑一下需求。

您是否希望将需要讨论的错误视为“开放”，或者您认为它们“已解决”。你甚至收集这些类型的指标吗？

我从您的问题中得出的要求是

1. 不希望在正常搜索中看到它们
2. 希望能够在明确地看到它们时看到它们
3. 需要能够完成讨论，并“将错误恢复正常”
4. 想通知人们有讨论要举行
5. 希望这些错误看起来不会得到解决

如果这些是真正的要求，并且您不关心“讨论”错误是否已经显示为已经解决了指标等问题，那么我认为您所拥有的内容可能已经足够好了，除了第5点。

其他一些替代方案

1. 创建“讨论”产品（或组件）。
2. 创建自定义生命周期（我不建议这样做。）
3. 分配给“讨论我”组/用户
4. 使用“超级错误”，并将错误标记为阻止“讨论超级错误”
5. 创建一个“讨论此问题”错误，并将错误标记为讨论阻止（这反映了最接近的现实，但这并不是最佳选择）。

但是，正如我所说的那样，考虑一下你想要实现的目标，然后选择基于此的机制。为了让它们全部工作，你需要做些不同的权衡： - ）。