0

In our group, we have to model the state "needs discussion" for Bugzilla.

Therefore, a custom RESOLVED - to be discussed status was introduced. The appropriate group of people searches for issues that have this sort of "resolution" status and discusses these offline.

In my opinion, this is not the proper way as the bug/feature clearly is not resolved if there still is need for discussion. This is also reflected in the standard life cycle of a bug. It is sort of misleading, as "needs discussion" items show up in your list of resolved bugs.

Bugzilla Life Cycle of a bug

One way I can think of, would be to make a sort of "virtual user", representing the group that has to be involved in the discussion. This has the advantage, that one can search for the bugs easily. One could also setup a mailing list to notify the users.

I wonder how one can appropriately model this needs discussion state of a bug in Bugzilla 3.0.x. (And: what is the Mozilla-way solution?)

Behe
  • 7,572
  • 3
  • 33
  • 46
  • You are asking about an old version of Bugzilla. I looked at the current lifecycle (Sept 2012) http://www.bugzilla.org/docs/tip/en/html/lifecycle.html and it has changed significantly. – Peter Sep 13 '12 at 04:16
  • I am aware of this. By looking at the newer lifecycle, I have the impression that this question would still hold for the newer version. – Behe Sep 13 '12 at 14:53
  • As an orthogonal point to your actual question, I have found it preferable to assign bugs to email addresses that are archive-only rather than lists, and use the Bugzilla "watch user" feature to get email sent to you if you are interested in those bugs. This prevents the duplicate emails you get if you are CC'd on the bug assigned to a mailing list (I was getting upwards of 3 copies for some bugs being on several mailing lists), and the need to have separate email rules for the mailing list, you get your normal rules as if that address was you. – Peter Jul 21 '19 at 23:58

1 Answers1

1

As with any software system there are a multitude of ways to address your need.

Before you start with mechanism it would be good to think about requirements.

Do you want bugs the need discussion to be counted as "open" still, or do you consider them "resolved". Do you even collect those types of metrics?

The requirements I derive from your question are

  1. Don't want to see them in normal searches
  2. Do want to be able to see them when looking explicitely
  3. Need to be able to finalize the discussion, and "bring the bug back" to normal
  4. Would like to notify people that there is a discussion to be held
  5. Would like the bugs to not look like they are resolved

If those are really the requirements, and you don't care that "for discussion" bugs are showing up as resolved for metrics etc, then I think what you have is probably good enough, except for point 5.

Some other alternatives

  1. Create a "Discussion" product (or component).
  2. Create a custom lifecycle (I wouldn't recommend that though).
  3. Assign to the "Discuss-me" group/user
  4. Use a "super bug", and mark the bugs a blocking the "Discussion super bug"
  5. Create a "discuss this issue" bug, and mark the bug as blocked by the discussion (this reflects reality the closest, but that doesn't make it the best option).

But, as I say, think about what you're trying to achieve first, and then choose the mechanism based on that. There are different trade-offs around the amount of bug-fiddling you have to do to make them all work :-).

Peter
  • 971
  • 8
  • 15
  • I think the main issue with our setup that still bothers me is that a bug is shown as resolved. Using another Product or Component would cause it to disappear from other reports. As you mentioned, I think a solution with a "discuss me" group/user would suit best for this case. – Behe Sep 13 '12 at 14:51