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 _______________________________________________ bug-lilypond mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-lilypond
