Bugzilla's Future. Much of this is the present, now.

Those who use Bugzilla frequently are probably used to notification spam - unwanted or unnecessary notifications. A number of proposals have been put forward to attempt to reduce this. 1. Reduce CC Spam Some of you probably know me as that guy who CCs on heaps and heaps of bugs. Just as you get a lot of CC changes from me, so do I get a lot from others. Why should CC changes send out email notifications? It's not necessarily the best idea to just remove the CC spam, there are other issues too, like the difficulty of adding to large CC fields. For these reasons and more, an RFE for a per user "BCC" facility exists that people could use to silently and privately track bugs, in a similar way to voting today, but applying to an unlimited number of bugs. See "http://bugzilla.mozilla.org/show_bug.cgi?id=7345". 2. Bulk Changes You know the drill - a large milestone change, a component movement, whatever, and lots of notifications are generated. If there's enough maybe you'll just go delete, delete, delete, whoops, there goes another notification that wasn't from the bulk change you missed. Shouldn't bulk changes send out one notification? A proposal for this is at "http://bugzilla.mozilla.org/show_bug.cgi?id=26943". 3. Configurable Notification Criteria It would be good if you could choose what you want to receive. There are two parts to this. (a) Choose a selection of bugs you're interested in. This would be similar to CC except you let the set be computed from selection criteria rather than limited to the bugs your name is on. There is currently a limited version of this in the bugzilla preferences, ie "all qualifying bugs"/"all qualifying bugs except the ones I change"/"only those bugs which I am listed on the cc line". (b) Choose what changes will trigger a notification for the bugs you are watching. With this, you could choose whether you want to receive cc, dependency and keyword changes, for example. Both of these proposals live at "http://bugzilla.mozilla.org/show_bug.cgi?id=14137". Note that they also live at "http://bugzilla.mozilla.org/show_bug.cgi?id=17464", and the change has been checked in. This is fixed with Bugzilla 2.12 and is no longer an issue. Woo-Hoo!

Current searching tools in Bugzilla include the querying mechanism, special summary reports and dependency trees. This message is about new facilities. 1. General Summary Reports For some time now it has been apparent to me that the query bug list leaves a little to be desired in its linear nature. There is a need to have categorised subsets, and counts of each category. If you don't believe me, how about these facilities already in place or which people have asked for: Most Doomed Reports - Categorised On Assignee, Shows and Counts Number of Bugs For Each Assignee Bug #15806 (Most Voted For Bugs) - Categorised On Product, Shows Bugs Voters Most Want Fixed Bug #9789 (BugAThon Tracking Page) - Categorised On Developer (Subset), Counts Number of Bugs Bug #9409 and #9411 - The desire to be able to report on more subsets. Hopefully you can see the gist of what is desired here. It's a general reporting mechanism. This mechanism lets you choose the subset of bugs to operate on (like query), let's you categorise them, possibly along with subcategories and counts the number of bugs within each category. It might or might not show the actual bugs themselves, and it might limit the number of bugs within a category, or categories to report on. I'm further sure that many applications of this mechanism would only be recognised once it was implemented. The general summary reports bug is at "http://bugzilla.mozilla.org/show_bug.cgi?id=12282". 2. Related Bugs It would be nice to have a field where you could enter other bugs related to the current bug - it would be handy for navigation and possibly even finding duplicates. See "http://bugzilla.mozilla.org/show_bug.cgi?id=12286". 3. Column Specification Support Currently query seems to get what columns to report on from whatever the user last used. This doesn't work well for "prepackaged queries", where you followed a link. You can probably add a column by specifying a sort column, but this is difficult and suboptimal. Furthermore, I find that when I want to add a column to a query, it's usually a one off and I would prefer it to go away for the next query. Hence, it would be nice to specify the columns that appear on the query (and general summary report) pages. The default query mechanism should be able to let you specify your default columns. This proposal lives at "http://bugzilla.mozilla.org/show_bug.cgi?id=12284".

Since I last posted on this issue, we now have "keywords" that solve many of the issues of description and status whiteboard keywords. We have seen a migration towards keywords, but there is still further to go. Description ( + Status Whiteboard ) Keywords -------------------------------------------- Some description keywords remain. I'd like to hear what reasons, other than time, there are for these staying as they are. I'm suspecting many are not really being used. Hopefully we can totally remove these eventually. Tracking Bugs ------------- When I suggested keywords, I did so to get rid of tracking bugs too, though we've had less success on that front. There are many disadvantages to tracking bugs. - They can pollute bugs counts, and you must make sure you exclude them. I believe the meta keyword might be used for this purpose. - They have an assignee but there is nothing to fix, and that person can get whined at by Bugzilla. - It would be better to craft your own "dependency tree" rather than rely on a fixed hierachy in the bug system. - In creating a nice little hierachy, many bugs duplicate information that should be available in other ways, eg "http://bugzilla.mozilla.org/show_bug.cgi?id=12833" which is about beta 1 networking issues. These could fall behind the actual data. What tracking bugs are good for, ad hoc lists, is what keywords are better for. - An automatically generated dependency structure between one "tracking bug" and another would be better than a manual one, since it gives exact rather than manually set up classifications. Probably the only feature preventing tracking bugs being replaced is the dependency tree. The quintessential tracking bug seems to be bug #7229 "chofmann's watch list", which probably has about a couple of hundred bugs at various levels, which allows a nice visualisation. Before keywords can replace tracking bugs better visualisation is going to be required. General summary reports and dependency forests of a bug list ("http://bugzilla.mozilla.org/show_bug.cgi?id=12992") could both help, but neither solves the problem totally. Perhaps keywords within keywords would help here. In any case, I'm still thinking about this one. Some tracking bugs could definitely be turned into keywords immediately though, and I'll point the finger at "http://bugzilla.mozilla.org/show_bug.cgi?id=7954" here since that's what came to mind first.

1. Inline Bug Changes Why do I see so many "moving to M5" and "reassigning to blahblah" messages, and in other circumstances none are entered? Why aren't these automatically generated? A comment should be only necessary when there is something to add, and if I'm not interested in this sort of information, I should be able to hide it. At the moment we're in a hybrid world where we don't get everything, but we can't get rid of the bug change "messages" either. Furthermore, "View Bug Activity" requires me to manually cross reference events on another page, rather than being able to visually see the chronological order. Shouldn't I be able to see all the information on one page? A proposal to allow bugs to be shown either way is at "http://bugzilla.mozilla.org/show_bug.cgi?id=11368". 2. Hard Wrapping Comments One thing that annoys me is the fact that comments are "hard wrapped" to a certain column width. This is a mistake Internet Mail and News has made, unlike every word processor in existence, and as a consequence, Usenet suffers to this day from bad software. Why has Bugzilla repeated the problem? Hard wrapping to a certain column width is open to abuse (see old Mozilla browsers that didn't wrap properly, resulting in many ugly bug reports we have to read to this day), and furthermore doesn't expand to fill greater screen sizes. I'm also under the impression the current hard wrap uses a non-standard HTML facility. See "http://bugzilla.mozilla.org/show_bug.cgi?id=11901". 3. REMIND and LATER Are Evil I really hate REMIND and LATER. Not because they mean something won't be implemented, but because they aren't the best solutions. Why are they bad? Well, basically because they are not resolved, yet they are marked as such. Hence queries have to be well crafted to include them. LATER, according to Bugzilla, means it won't be done this release. There is a better mechanism of doing this, that is assigning to nobody@mozilla.org and making the milestone blank. It's more likely to appear in a casual query, and it doesn't resolve the bug. REMIND, according to Bugzilla, means it might still be implemented this release. Well, why not just move it to a later milestone then? You're a lot less likely to forget it. If it's really needed, a keyword would be better. Some people can't use blank milestones to mean an untargetted milestone, since they use this to assess new bugs that have no target. Hence, it would be nice to distinguish between bugs that have not yet been considered, and those that really are not assigned to any milestone in the future (assumedly beyond). All this is covered at "http://bugzilla.mozilla.org/show_bug.cgi?id=13534". 4. Create An Enhancement Field Currently enhancement is an option in severity. This means that important enhancements (like for example, POP3 support) are not properly distinguished as such, because they need a proper severity. This dilutes the meaning of enhancement. If enhancement was separated, we could properly see what was an enhancement. See "http://bugzilla.mozilla.org/show_bug.cgi?id=9412". I see keywords like [RFE] and [FEATURE] that seem to be compensating for this problem.

Bugzilla could be more proactive in detecting suboptimal situations and prevent them or whine about them. 1. Bugzilla Crime #1: Marking A Bug Fixed With Unresolved Dependencies It can't be marked fixed with unresolved dependencies. Either mark it INVALID (tracking bugs), fix the dependencies at the same time, or resolve the blockers. See "http://bugzilla.mozilla.org/show_bug.cgi?id=24496". 2. Keyword Restrictions Some keywords should only apply in certain circumstances, eg beta1 => Milestone < M14, css1 => Component = Style System are possibilities. See "http://bugzilla.mozilla.org/show_bug.cgi?id=26940". 3. Whine About Old Votes Old votes can just sit on resolved bugs. This is problematic with duplicates especially. Automatic transferral/removal is not appropriate since bugs can be reopened, but a whining solution might work. See "http://bugzilla.mozilla.org/show_bug.cgi?id=27553". 4. Whine And Warn About Milestone Mismatches Here's a fun one. Bug X (M17) depends on Bug Y (M15). Bug Y gets moved out to M19. The notification to the assignee of Bug X gets ignored (of course) and Bug X is now due to be fixed before one of its blockers. Warnings about this when it is detected as well as whining about it in email would help bring these issues to the attention of people sooner. Note that this would be less of a problem if we didn't have so many tracking bugs since they aren't updated that often and often have this problem. See "http://bugzilla.mozilla.org/show_bug.cgi?id=16743".

One day, Bugzilla 3.0 will have lots of cool stuff.