Re: third bug suggestions - 133772

[Malcolm Tredinnick <malcolm commsecure com au>]

On Mon, 2004-02-09 at 06: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.

Leave them alone, for the most part. Check that the priorities are
correct. True feature requests are "severity: enhancement", for example.

> 
> 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?

A few thoughts:

- this bug has a problem. It is not *a* bug. It is two bug reports in
one, for which the reporter should be beaten severely around the head
and shoulders with a rubber fish. Sadly, we are not allowed to do that.

- The delay after resizing could be a real bug (or indicative of a real
problem) and that is what this bug report is about. So you cannot really
do anything here.

- The comment about changing a string is a whole other bug and should be
filed as such (either do it yourself, or add a comment that the filer
should do it). This new "bug" is an enhancement request.

- As a rule, don't touch the assignments, unless you are assigning a bug
to yourself. Some maintainers (including me) prefer to leave bugs in the
"new" state until they are actively working on them or thinking about
them. Many maintainers don't appear to care, but will object if you
start clicking "assigned".

Malcolm