On Tue, Oct 27, 2009 at 01:54:32AM +0100, Valentin Villenave wrote: > On Tue, Oct 27, 2009 at 1:41 AM, Graham Percival > <[email protected]> wrote: > > It feels like more because you let it pile up. *as soon as* a bug > > report comes in, look at it. If it takes you more than 60 seconds > > to understand it, reply to the submitter to that effect. Once > > you've bounced the bug report back -- asking for clarification, a > > minimal example, whatever -- then it's no longer your problem. If > > the user doesn't reply, then forget about it, and move on to the > > next issue. > > Au contraire, it *is* my problem because most of the time it's me not > being intelligent. Take Frédéric's latest "too many accidentals" > report: perhaps I'm getting stupid (or very very very tired), but even > after reading the whole discussion twice I'm having a hard time making > heads or tails out of this.
Yes. The first report was unclear; many people (including me) thought it wasn't a bug. So what happened? He made an example that was more obvious. (the "key signature not inherited" thing) The most important thing out of the whole affair, IMNSHO, was the *immediate discussion*. Sure, the first few people who replied were "wrong" -- they claimed (as I thought) that there was no bug. But because they questioned him immediately, the details were still fresh in his mind, so he created the next example. If there's a one-week delay while you try to figure out if you're being stupid or not, then the person who reported it might forget details, and at the very least he'll feel extremely unwelcome. > > If you understand it (60 seconds), test it on the lastest devel > > release (30 seconds), then upload it to the tracker (60 seconds). > > Yeah, the "understanding" part is my weakness :) No, the "not wanting to look stupid and sitting on it for longer than 60 seconds" is your weakness. Be stupid [1]. Be mean [2]. You'll be far more effective, and people will love you for it. [1] in this context, i.e. "sorry, I don't understand why you think there's a bug. Could you explain what Arabic notation / lyrics / a bes in the key of f \major is supposed to look like?" [2] in this context, i.e. "sorry, I can't add a bug that I don't understand / sorry, I can't reproduce it on my system; what OS do you use / sorry, we don't have the resources to debug large scores; please create a tiny example as explained on lilypond.org/bugs.html / etc" You don't have to be rude. Just be mean. :) > > I want to emphasize this point. **if you cannot easily understand > > the bug, it's the submitter's fault, not yours** we simply do > > not have the resources to hunt through unclear bug reports. > > Not always: Frédéric's initial report seemed crystal clear, but > getting to the bottom of this seems awfully complex when it's 2AM :-) Valentin, drop the hubris. IIRC, Neil, Trevor, Mats, and me *all* thought that there wasn't a bug. Do you really think that you're supposed to know more about lilypond than that group of people? > > I read an article somewhere about a "hot potato" way of handling > > bug reports. I don't know if you play this game in France, but > > Yeah, we have that -- though the "patate chaude" paradigm is often > used here in a political context (for instance when the government > tries to get rid of healthcare policies or whatever ;) Great! Now, your job is to get rid of la patate chaude. You have two ways of doing this: asking the user for more info / a new example, and adding it to the tracker. Letting an email sit in your inbox for more than 2 days is not one of those options. > > But it would be nice if we had _some_ kind of response, so > > submitters have a bit more confidence in the system. I don't care > > if they think we're meanies who are really picky about accepting > > reports, just as long as they have confidence in our mean-ness. > > Only brilliant people like you can afford to be mean; these days I > just feel plain stupid and incompetent... :) When it comes to handling bugs and documentation, my brilliance is in *not* being brilliant. Be stupid. "Sorry, I don't understand..." There's a phrase "the customer is always right" (that's the only thing I remember from my mandatory "business" class in grade 10). When I write documentation, I adapt this -- "the reader is never wrong". In other words, if somebody gets the wrong idea after reading my docs... or worse, if they can't *find* the right place... then it's my fault, not theirs. In this case, you're the customer/reader. If you don't understand what the bug reporter is trying to tell you, it's their fault for not explaining it clearly enough. Maybe you're just not familiar with Ukranian accordian notation. Maybe you're like me, and have never written stuff with lyrics. Yeah, those bug reports were fun to handle... but if you just say "sorry, I'm not at all familiar with lyrics. What is this extender line thing supposed to look like?", then you can't go wrong. Really, trust me. Be stupid; you'll be a _much_ better bug meister. (we could still use a few more people doing this job, though. And remember: it's ok if you're stupid!) Cheers, - Graham _______________________________________________ lilypond-user mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-user
