<HTML ><HEAD ><TITLE >Bug Issues</TITLE ><META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.61 "><LINK REL="HOME" TITLE="The Bugzilla Guide" HREF="index.html"><LINK REL="UP" TITLE="The Future of Bugzilla" HREF="future.html"><LINK REL="PREVIOUS" TITLE="Description Flags and Tracking Bugs" HREF="trackingbugs.html"><LINK REL="NEXT" TITLE="Database Integrity" HREF="dbaseintegrity.html"></HEAD ><BODY CLASS="SECTION" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#840084" ALINK="#0000FF" ><DIV CLASS="NAVHEADER" ><TABLE WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="3" ALIGN="center" >The Bugzilla Guide</TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="bottom" ><A HREF="trackingbugs.html" >Prev</A ></TD ><TD WIDTH="80%" ALIGN="center" VALIGN="bottom" >Chapter 6. The Future of Bugzilla</TD ><TD WIDTH="10%" ALIGN="right" VALIGN="bottom" ><A HREF="dbaseintegrity.html" >Next</A ></TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="SECTION" ><H1 CLASS="SECTION" ><A NAME="BUGPROBS" >6.4. Bug Issues</A ></H1 ><P ><P CLASS="LITERALLAYOUT" >1. Inline Bug Changes<br> <br> Why do I see so many "moving to M5" and "reassigning to blahblah"<br> messages, and in other circumstances none are entered? Why aren't these<br> automatically generated? A comment should be only necessary when there<br> is something to add, and if I'm not interested in this sort of<br> information, I should be able to hide it.<br> <br> At the moment we're in a hybrid world where we don't get everything, but<br> we can't get rid of the bug change "messages" either. Furthermore,<br> "View Bug Activity" requires me to manually cross reference events on<br> another page, rather than being able to visually see the chronological<br> order. Shouldn't I be able to see all the information on one page?<br> <br> A proposal to allow bugs to be shown either way is at<br> "http://bugzilla.mozilla.org/show_bug.cgi?id=11368".<br> <br> 2. Hard Wrapping Comments<br> <br> One thing that annoys me is the fact that comments are "hard wrapped" to<br> a certain column width. This is a mistake Internet Mail and News has<br> made, unlike every word processor in existence, and as a consequence,<br> Usenet suffers to this day from bad software. Why has Bugzilla repeated<br> the problem?<br> <br> Hard wrapping to a certain column width is open to abuse (see old<br> Mozilla browsers that didn't wrap properly, resulting in many ugly bug<br> reports we have to read to this day), and furthermore doesn't expand to<br> fill greater screen sizes. I'm also under the impression the current<br> hard wrap uses a non-standard HTML facility. See<br> "http://bugzilla.mozilla.org/show_bug.cgi?id=11901".<br> <br> 3. REMIND and LATER Are Evil<br> <br> I really hate REMIND and LATER. Not because they mean something<br> won't be implemented, but because they aren't the best solutions.<br> <br> Why are they bad? Well, basically because they are not resolved, yet<br> they are marked as such. Hence queries have to be well crafted to<br> include them.<br> <br> LATER, according to Bugzilla, means it won't be done this release. <br> There is a better mechanism of doing this, that is assigning to<br> nobody@mozilla.org and making the milestone blank. It's more likely to<br> appear in a casual query, and it doesn't resolve the bug.<br> <br> REMIND, according to Bugzilla, means it might still be implemented this<br> release. Well, why not just move it to a later milestone then? You're<br> a lot less likely to forget it. If it's really needed, a keyword would<br> be better.<br> <br> Some people can't use blank milestones to mean an untargetted milestone,<br> since they use this to assess new bugs that have no target. Hence, it<br> would be nice to distinguish between bugs that have not yet been<br> considered, and those that really are not assigned to any milestone in<br> the future (assumedly beyond).<br> <br> All this is covered at<br> "http://bugzilla.mozilla.org/show_bug.cgi?id=13534".<br> <br> 4. Create An Enhancement Field<br> <br> Currently enhancement is an option in severity. This means that<br> important enhancements (like for example, POP3 support) are not properly<br> distinguished as such, because they need a proper severity. This<br> dilutes the meaning of enhancement.<br> <br> If enhancement was separated, we could properly see what was an<br> enhancement. See "http://bugzilla.mozilla.org/show_bug.cgi?id=9412". I<br> see keywords like [RFE] and [FEATURE] that seem to be compensating for<br> this problem.</P ></P ></DIV ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="trackingbugs.html" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="index.html" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" ><A HREF="dbaseintegrity.html" >Next</A ></TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >Description Flags and Tracking Bugs</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="future.html" >Up</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" >Database Integrity</TD ></TR ></TABLE ></DIV ></BODY ></HTML >