Re: third bug suggestions - 133772

[Heather Flanagan <heather duke edu>]

On Feb 8, 2004, at 2:49 PM, Andrew Sobala wrote:

> On Sun, 2004-02-08 at 19:08, Heather Flanagan wrote:
> > You know, there a fair bit of documentation on how to handle a bug 
> > that
> > results in a crash, but not much in the way of dealing with a bug that
> > is merely annoying, or even just a feature request.  A suggestion for
> > some other time.
>
> Yes. The reason for that is that crashes are easy to identify - most of
> crash triaging could probably be done by a sufficiently advanced
> script...
>
> otoh, all other bugs end up being value judgements. That's the tricky
> bit. But anything you think is worth adding to the documentation would
> be very useful - it's difficult for us to know which bits are lacking.
>
> > And be that as it may for now, looking at this latest example of
> > bug-ness, the gent isn't reporting a crash, just an annoying 
> > "feature".
> >   Priority and severity are where they should be.  I'd probably add 
> > the
> > keyword "usability", then mark it as either assign or reassign -
> > thoughts on that?
>
> I think this is "minor" because it essentially works, it's an 
> irritation
> not something completely broken.
>
> wrt "usability", this keyword is really for bugs that contain arguments
> over UI design decisions. In a sense a bug is by definition irritating
> which makes it a "usability" bug but that's not what the keyword is
> intended for.

Ah.  So, combining what you and Malcolm and Eunice have pointed out, 
something along the following lines would be about right?

---
Priority - normal
Severity - minor
Status - leave alone
No particular keywords

Thank the submitter for the information on the resizing bug, and ask 
him/her to submit the second request as another bug/feature request, 
that extra bit of work being the only wrist slapping we can really do 
to get users not to put two or more items in one ticket.

----
That sound more appropriate?

-heather f.