From 5bef49c26c5d3c49da84aeddee3217a2fa917e8c Mon Sep 17 00:00:00 2001 From: "barnboy%trilobyte.net" <> Date: Sat, 11 Aug 2001 05:15:12 +0000 Subject: Removal of HTML from docs temporarily due to massive renaming in the latest restructuring of the Bugzilla Guide. --- docs/html/bugprobs.html | 211 ------------------------------------------------ 1 file changed, 211 deletions(-) delete mode 100644 docs/html/bugprobs.html (limited to 'docs/html/bugprobs.html') diff --git a/docs/html/bugprobs.html b/docs/html/bugprobs.html deleted file mode 100644 index 24805ea35..000000000 --- a/docs/html/bugprobs.html +++ /dev/null @@ -1,211 +0,0 @@ -
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.