Reflections of a bigtime Debian bug reporter

Reflections of Dan Jacobson (http://jidanni.org/, jidanni@jidanni.org, 積丹尼, reporter of many small potatoes Debian bugs. Quantity, not quality.) A 2009 Taiwan Mini Debian Conference talk, 2009/09/26.

Outline of talk:

  1. You notice a bug.

    1. Moral obligation to report it

    2. Check health of package maintenance: Anybody home? Has rigor mortis already set in?

    3. Reporter not required to be able to tell at a glance if it is a Debian or upstream bug, thank goodness

    4. "Patches welcome" (bug reports not!)

    5. Download the source, finally make a patch... but the project/package got canceled/discontinued

  2. Role of reporter vs. maintainer

    1. User cannot ask his employer for time to debug all the bugs he encounters, so he creates a bug report and hands it off to the experts: maximum efficiency of each role

    2. "Cultural" differences

      1. Mind your manners*

      2. Reporter and maintainer might differ very much in age

      3. I'm banned for life from *@perl.org. Must have been some misunderstanding, but I can't reach anybody who is in charge even via the telephone. Alas, must report bugs downstream (to Debian)

        Telephones, and indeed computers too, are merely communication tools, and I can't get through. Moral of story: make sure one's organization has a contactable contact person

  3. Be glad I'm a dummy

    1. else if Debian is all experts, who is to play the part of the user?

    2. else you will never know how your package looks to the silent majority, see http://www.useit.com/alertbox/ (Jakob Nielsen)

    3. Don't scare the dummy into not giving any more bug reports (or even dumping the package altogether) by:

      1. Berating (but some maintainers are merely Don Rickles). *Did you know in industry one has to take courses in customer relations? ...worth your while

      2. The /dev/null treatment (Google: no way at their user to staff ratio to hear individual users)

      3. Prosecuting (MicroSoft: You dare to report a bug? Where's your proof of purchase serial number?)

      4. Five year turnaround, by which time the user might be mentally 5000 kilometers away, and not even know what you are talking about, even though the report bears his name. So strike when the bug (iron) is hot

    4. Once I turn into an expert, my eyes no longer see the bugs that still confront the little guy, who might not even know how to report them

  4. Etc.

    1. Don't make user jump through hoops to report a bug (subscribe to a mailing list first, answer a billion questions... only to fail a CAPTCHA, etc.)

    2. Bugzilla and other interactive reporting systems are great... if your modem is not metered. Debian BTS is great, just remember to Cc: the submitter

    3. Some maintainers think:

      1. "Each year, I the maintainer of package XYZ, will send a message to all open bug report submitters, asking them to test to see if the bug still exists in the current version. Those who don't respond will have their bugs closed. Muhahaha"

      2. "I'll 'pass the bug' (buck)"... only to have it end up reassigned back

    4. Where are the "how to write good bug reports" authors these days? I don't know. They don't answer their email and their software is brimming with bugs

      How about programs like reportbug?

      I just use that inside a script to generate the required pseudo headers of a Debian bug report. The rest I fill in by hand, because I hate sending extra bytes in my bug reports... If I have to include a logfile, I perhaps might use a "file bin" website URL to not clutter the report.

      So what should one include in a bug report?

      I'm not sure what the focus of my talk today is, but it's not that.

      In fact much more important than how to write a proper bug report is "is there anybody home at the other end to read it?" "Will they read it soon enough that the enthusiasm of the bug reporter doesn't die on the way to the hospital?"

      So, the best bug report would be an initial improper mini-bug report to test if the maintainer is still alive, and in a good mood. And OK, but why does he also have that junkyard of open bugs?

      *** warning: this lecture is getting too long. ***

    5. Why does every package these days seem to have a junkyard full of open bugs? Aren't there any sharp young maintainers left who take pride in a clean doorstep?

    6. On the other hand how unfortunate it is that some software ended up so complex that it's "bug if you do, bug if you don't"

    7. I don't know the package maintainer's side of the picture: too complex for me

  5. Legacy: so what will become of all those years-old open bug reports? "This bug is closed because that package has been removed from Debian"... ah, good thing I didn't try too hard to fix it in the first place!

Discussion

My Debian bugs (warning: lots. How many? I don't keep track.)

2010.04.01: Bug#576184: ITP: jidanni -- a natural intelligence to find many bugs

2010.07: Did I write all this? I sure must have been rather smart back then in 2009.

Last modified: 2011-04-13 09:17:19 +0800