From 6b607da839992bead01d7cba308f216e17eed520 Mon Sep 17 00:00:00 2001 From: "barnboy%trilobyte.net" <> Date: Thu, 8 Mar 2001 13:35:44 +0000 Subject: Documentation update; added docs/sgml, docs/html, docs/txt. No text version of The Bugzilla Guide availabe yet, however. --- docs/html/bugprobs.html | 211 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100644 docs/html/bugprobs.html (limited to 'docs/html/bugprobs.html') diff --git a/docs/html/bugprobs.html b/docs/html/bugprobs.html new file mode 100644 index 000000000..0cec6a90a --- /dev/null +++ b/docs/html/bugprobs.html @@ -0,0 +1,211 @@ +
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.