diff options
Diffstat (limited to 'docs/sgml/future.sgml')
| -rw-r--r-- | docs/sgml/future.sgml | 324 |
1 files changed, 324 insertions, 0 deletions
diff --git a/docs/sgml/future.sgml b/docs/sgml/future.sgml new file mode 100644 index 000000000..db3c071b2 --- /dev/null +++ b/docs/sgml/future.sgml @@ -0,0 +1,324 @@ +<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.1//EN" > --> + +<chapter id="future"> + <title>The Future of Bugzilla</title> + <synopsis>This section largely contributed by Matthew Tuck</synopsis> + <section id="spamlite"> + <title>Reducing Spam</title> + <para><literallayout> +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". +</literallayout></para> + </section> + + <section id="searching"> + <title>Better Searching</title> + <para><literallayout> +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". +</literallayout></para> + </section> + + <section id="trackingbugs"> + <title>Description Flags and Tracking Bugs</title> + <para><literallayout> +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. +</literallayout></para> + </section> + + <section id="bugprobs"> + <title>Bug Issues</title> + <para><literallayout> +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. +</literallayout></para> + </section> + + <section id="dbaseintegrity"> + <title>Database Integrity</title> + <para><literallayout> +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". +</literallayout></para> + </section> + + <section id="bz30"> + <title>Bugzilla 3.0</title> + <para>One day, Bugzilla 3.0 will have lots of cool stuff.</para> + </section> + +</chapter> + +<!-- Keep this comment at the end of the file +Local variables: +mode: sgml +sgml-omittag:t +sgml-shorttag:t +sgml-namecase-general:t +sgml-general-insert-case:lower +sgml-minimize-attributes:nil +sgml-always-quote-attributes:t +sgml-indent-step:2 +sgml-indent-data:t +sgml-parent-document:nil +sgml-exposed-tags:nil +sgml-local-catalogs:nil +sgml-local-ecat-files:nil +End: +--> |