Home/ Questions/Q 8565695
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T17:29:09+00:00

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

  • 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?)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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 :-).

    • 0