Re: do you care about bug reports?

[Graham Percival]

On Tue, Oct 27, 2009 at 01:54:32AM +0100, Valentin Villenave wrote:
> On Tue, Oct 27, 2009 at 1:41 AM, Graham Percival
> <address@hidden> 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