path: root/docs/sgml/future.sgml

<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.1//EN" > -->

<chapter id="future">
  <title>The Future of Bugzilla</title>
  <synopsis>Bugzilla's Future.  Much of this is the present, now.</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".
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!
</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:
-->