Documentation update; added docs/sgml, docs/html, docs/txt.

No text version of The Bugzilla Guide availabe yet, however.

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:
+-->