0

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

因此，引入了自定义RESOLVED - 待讨论状态。适当的人群搜索具有这种“解决”状态的问题并离线讨论这些问题。

在我看来，这不是正确的方法，因为如果仍然需要讨论，错误/功能显然没有解决。这也体现在一个bug的标准生命周期中。这有点误导，因为“需要讨论”项目显示在您已解决的错误列表中。

Bugzilla 错误的生命周期

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

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

4

1 回答 1

1

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

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

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

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

  1. 不想在正常搜索中看到它们
  2. 确实希望能够在明确查看时看到它们
  3. 需要能够最终确定讨论，并将错误“恢复”正常
  4. 想通知人们有一个讨论要举行
  5. 希望错误看起来不像已解决

如果这些确实是要求，并且您不在乎“讨论”错误显示为已解决指标等，那么我认为您所拥有的可能已经足够好，除了第 5 点。

其他一些选择

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

但是，正如我所说，请先考虑您要实现的目标，然后根据此选择机制。为了使它们都能正常工作，您必须做的错误摆弄量有不同的权衡:-)。

于 2012-09-13T04:30:07.713 回答