Re: abandoned bug reports

[Graham Percival]

On Fri, Feb 18, 2011 at 11:24:48AM +0200, Dmytro O. Redchuk wrote:
> On Tue 15 Feb 2011, 18:26 Graham Percival wrote:
> > (and do you have your email setup with the filtering we recommend
> > in the CG?)
> No, actually it looks like this: i am flagging (shift+f in mutt) as important
> another new (which possibly discusses new issue which has not been added to
> the tracker yet) thread, reading all thread's messages thoroughly (for, yes,
> 30 seconds to let's say 90 seconds depending on the topic, the thread, my
> workload, conditions around me etc) and deciding whether i _possibly can_ deal
> with this problem or it is _too hard for me_ ("next time" is possible too).

Hmm.  If you get mail with fetchmail, I recommend adding this to
your .procmailrc.  If you're using imap, then I'm sure that gmail
can do this kind of filtering for you already.

:0
* ^List-ID: LilyPond Bug Reports <bug-lilypond.gnu.org>
* @googlecode.com
0bug-lilypond-ignore

Filtering out all those automatic messages cuts the messages to
bug-lilypond by half, making it much easier to spot new issues.

> If i think i can (so, i am ~60 or more percents sure that i understand this
> issue and it is "valid issue" -- and there is no discussion with opposite
> opinions between people) -- i start to test it (sometimes i've added
> modified snippet, simplified or "enhanced") and then add it to the tracker.
>
> If i think that i don't understand "what's they're talking about" -- i skip
> this thread (have it flagged, with a hope that sometime in the future i'll
> have better mood or conditions).

Hmm.  My hope is that the bug squad members *don't* do this.

If you spend all 15 minutes dealing with "issues that you
understand", that's fine.  But if you spend 5 minutes dealing with
stuff you understand, then please spend 10 minutes dealing with
stuff you *don't* understand.

The way to deal with them is pretty easy!  Look at the checklist:
5. If anything is unclear, ask the user for more information. 


That's it -- you've handled the email.

> After "processing" all threads this way -- i look into "issues to verify".

Please no.  If there are any emails left -- ANY emails at all --
then process them.  Dealing with emails takes COMPLETE priority
over verifying issues.

Remember that "dealing with an email" can just mean hitting
"reply" and writing "I'm sorry, but I do not understand this
report.  Can be please be more specific?  Why do you think that
the current output is incorrect?" or something like that.

> Oh, well, regarding "email setup" in the CG: no, i didn't follow it. I have
> set up (mutt: local delivery + imap/google) a bunch of folders/filters/hooks,
> i don't want to register another google account, i am pretty happy with that
> what i have. I've read some 5 or 7 times that section, found it quite
> reasonable and helpful but decided that my own "layout" is good enough.

ok.  Just please adjust your priorities as mentioned above.
Emails first.  Writing "I don't understand" is a completely
acceptable way to "handle" an email.  Finish all emails before
verifying issues.


Of course, this goes for all the other bug squad members, too.

> And i think "oh well somebody will understand this having spent much less
> effort, probably".

Please don't do this.  I'm asking for 15 minutes, once a week;
nothing more, nothing less.  If you've already spent that time,
then of course don't do any more effort.  But if you have time
remaining, then please spend that remaining time trying to
understand any remaining emails.

(if your 15 minutes end while you're still in the middle of
reading an email, that's fine -- just stop reading the email and
abandon it for the next person!  If you have a stopwatch or
kitchen timer, I encourage you to do that.  Pretend that you're
boiling an egg[1].  Set your timer for 15 minutes, start handling
emails, and when the timer beeps, immediately stop what you're
doing!)

[1]  why yes, I'm a single male who doesn't know how long it takes
to boil an egg.  :)


> Would be great if:
> 
>  * ... bug-lilypond would be for reports, not discussions.
>     Sometimes it's quite difficult to separate, but would be really _great_ if
>     every kind person followed "the rule" (i invented it right now): "If
>     unsure [i mean not 93 or more percents sure] that this is a bug -- discuss
>     in lilypond-user, or lilypond-devel *please*".

As long as people don't change the subject line, I don't think
this is a problem.  If you see a long discussion, then quickly
check through all the emails.  If you see an email saying "thanks,
added as issue 1234", then stop reading and delete the whole email
thread.

>  * ... every issue report in the tracker would contain code to verify with.

Yes, absolutely!  My hope was that when bug squad members worked
on verifying issues, they'd realize how important this was, and
get pickier about making sure that their issue reports have sample
code.

That hasn't happened yet, but I'm still hopefuly.

> ps. About [in]competence -- working with issues can be good practice and gives
> me new knowledge very often!

Agreed!

> But it is a matter of efficiency, too -- every
> time i may make a decision (probably wrong) how to spend my time.

To reinforce my point again -- I'm not asking for efficiency.
Just 15 minutes of honest labor.  :)

> Better reports are easier to deal with.

Of course -- and one way to get better reports is to reject bad
reports.  Don't say "oh well, maybe somebody else can handle
this".  Reply immediately to say "I'm sorry, but I cannot
understand this report".

99% of the time, the user will be happy that somebody replied
quickly, and will gladly explain the issue (giving more code, or
pictures, or descriptions of what it should look like, etc).


But the vital thing is to make *some* kind of a reply.

Cheers,
- Graham