This bug is to track the discussions from #mozilla about bugzilla status, resolution, assignment, and other bugzilla.mozilla.org behaviors. Each entry in this bug should be an attachment. Discussions will take place in #mozilla and their logs will be attached here. If absolutely necessary we can overflow into the mozilla newsgroups (probably .qa). If people are interested in this bug they should silently cc themselves (voting is not enabled for this product).

someone expressed concern about logs. i'll give people ~12 hours to request redactions before i attach them here), until then they'll be available (unredacted) at the url in the url field.

Timeless asked me to make up a summary to the logs as well. This is my take, and while I like what I was reading, and agree, my little proposal here doesn't feel done yet. Mental has a good start too.

Although I don't wish to throw cold water on what is I believe a fruitful discussion that will likely provide all bugzilla.mozilla.org people and indeed many other Bugzilla people with long-term benefit, a small dose of reality will perhaps be useful to prevent anyone raising their expectations too high. The main problem here is that statuses and resolutions are currently hardcoded into Bugzilla. Bugzilla was designed specifically for mozilla.org and its process, and the need to have something ready reasonably quickly for them. These two factors meant that customisable statuses and resolutions were never going to happen. Of course, nowadays Bugzilla has many many installations, and even mozilla.org is changing its process. It is high time Bugzilla allows this fundamental customisation. That being said various installations can and do customise their Bugzilla software to support different statuses and resolutions, but this is through code forks. Such installations must repeat their changes to each new version of Bugzilla and must be careful the changes don't introduce bugs or miss new places that need to be customised when the code base is rapidly shifting underneath them as it is with Bugzilla. I am not aware of any changes whose scope approaches the proposal of JesusX. It is not an option to change the Bugzilla software to support any proposal and throw out the old way. Many installations are accustomed to the old way and we can't expect to be able to force them to change. It is not an option I believe to ask mozilla.org to fork to such an extensive degree which is much greater than I assume they have in the past and do in the present. Such a process is costly in terms of time, bugs, and the ability to upgrade regularly, and would be far worse than the benefit this proposal would provide. Nor is it a sensible option to provide both systems, new and old - the mozilla.org process will continue to evolve and this would just be a kludge. The only reasonable option, therefore, is to allow Bugzilla to support any set of statuses and resolutions, set up by the administrator. Then existing installations could have the old way preserved (and they could customise it at their leisure), mozilla.org could transition to the new way, and we could even set up the new way as a default for new installations. The effort to do this is non-trivial, and indeed quite substantial. I recognised the need for this some time ago and set out to allow customisation of resolutions (bug #94534). Originally the work seemed easy, but the devil was in the details, and I ended up putting substantial work into this task. I am now, for the most part, complete, and the work is sitting on a branch waiting a couple of prerequisite features and for the 2.16 release to be complete so it can be reviewed and landed for 2.17. I am hopeful it will be in CVS within 3 months. Now customised statuses (bug #101179) are a much more difficult problem. At the time I considered it to be too difficult a problem to attempt. There are statuses, status transitions, permissions to do status transitions, differences between open and non-open statuses, differences between confirmed, unconfirmed and possiblyconfirmed statuses and the bugbear of future automatic transitions to consider (BLOCKED and REMIND statuses and so on). But since then, some of the problem has been discussed, and I have been encouraged by how we have specified the issues, as well as what I have learned through the resolution work. I believe I can do most of what we would like for statuses in not much more time than the resolutions, given that some of the legwork was done for resolutions, plus other bits of Bugzilla work affected how I did resolutions and made it much more of a task, such as templatisation, taint mode and administration refactoring. So, in a nutshell, while I fully expect the ability to do whatever bmo wishes to arrive during this year, there is plenty of time to discuss this before it is feasible. If customised statuses are in CVS by August and ready to go on bmo, I would be reasonably happy with the timeframe. But these things of course can, and do, slip. Please bear this in mind in any discussion that occurs.

*** Bug 328152 has been marked as a duplicate of this bug. ***

We've had more recent discussions about Bugzilla workflow than this (see e.g. http://wiki.mozilla.org/BugzillaWorkflowImprovements) and requirements have changed. Any discussion of this sort should probably be part of that thinking. Gerv