triaging, and how to spend less time on it.

at guadec, some people took a look over my shoulder to see me triaging (and Don told me about the correct pronounciation). of course the bugsquad sometimes teaches triaging to interested newbies in #bugs, but it was even more fun to explain stuff “in person” to muelli sitting next to me for example, or to discuss tips and tricks with other squadders (as long as claudio does not eat my cookies in the meantime, but of course he would never do). and people asked me to blog about it. now it’s october, and i’m late, but better than never:

a year ago i started to write a greasemonkey script that makes triaging faster in several points, and now i found time to clean up the code a bit (it’s still messy, but i never said that i wanna be a coder when i grow up ;-).
basic features:

  • add a “stacktrace” anchor link to the top of the page so you can directly jump to the signal handler call by clicking only once, and then compare two traces by quickly switching between the two browser tabs:
  • screenshot.
  • add additional product- or distro-specific stock responses for some products that get a lot of reports, so it’s easier for reporters to install the right debug packages – for example, i also have “english, please!” or “this is not a support forum” stock responses for evolution bugs, because… i need them. sigh…:screenshot.
  • after clicking on the stock response, set keyboard focus to the “save changes” button to save the time you would need for scrolling otherwise
  • reduce the width of the area containing the stock answer links. i have a big screen resolution and i like short ways

here you go for download (but be careful, it may eat your cat). feedback welcome, just send mail. (answers to possible questions: “i have only tested it in firefox, there will be problems with other browsers”, “no, the stacktrace anchor link cannot go upstream due to technical reasons”, “no, we don’t want individual answers for every single module and i don’t think it’s the way to go, it’s been just my personal workaround for some special cases and i thought it could be interesting for others too”.) thanks to nazgul for improvements and comments.

additionally, i have to say that having a laptop made triaging significantly faster for me too, because switching between keyboard and mouse on a desktop computer takes so much longer than using a touchpad and the keyboard which has only a few inches in-between them.
and i use keywords in firefox: you can open http://bugzilla.gnome.org/show_bug.cgi?id=100000 by entering “bug 100000″ into the address bar, you only need a bookmark with the keyword “bug” and the address “http://bugzilla.gnome.org/show_bug.cgi?id=%s”. you can add keyword “q” to quickly get to the query page. and so on…

for the last months, the bugsquad started to add the STACKTRACE keyword to crasher reports with pretty perfect traces. useful evolution and nautilus reports should more or less be completely marked with that keyword now, so that hackers and contributors can find and fix crashers more easily. the keyword is especially useful for modules with a large income of reports and few developers/manpower, combining the querying with the latest version number. perhaps there’s some people around interested in marking good gtk+ crasher reports, and some other folks in fixing them?

i’ve added a few more resolved bugs to the auto-reject list so we get less dup reports. we still miss some information to track changes with regard to the number of rejected reports, so now that we reject reports from 2.16 distributions, i saved a copy of the auto-reject list to compare the numbers in a month, to find out which crashers don’t exist in >=2.18 anymore. easy one.

it’s amazing to see that we have a lot of bugsquadders currently (tom, susana, pedro, nazgul, bruno, diego, philip, muelli, cosimo, wolki and those that i’ve forgotten). i still wonder how we manage to create interest in this unpleasant repetitive gruntwork triaging work, but currently it looks like we’re successful in that. perhaps it’s time for me to look out for new challenges (and finish my studies to get a job). :-)

6 Responses to “triaging, and how to spend less time on it.”

  1. claudio says:

    I’d never eat your cookies!

  2. Jeff Walden says:

    (Warning: grammar nazi!)

    The second paragraph in the boilerplate I see in your screenshot has a comma splice in it (two sentences joined with a comma without and/but/or or another conjunction). I propose you use the following, grammatically correct version instead:

    While I have your attention, I’d like to note that GNOME Bugzilla isn’t a support forum — it’s a bug tracking system for software errors. For future reference, please ask support questions in a support forum (for example, the support forum for your distribution). Thanks!

    I also tried to make it sound a little less canned and personable while I was at it. :-) This is partly a matter of personal voice, but I think a little more friendliness could sometimes go a long way here.

    Lastly — and please don’t take this the wrong way or anything, especially if I’m guessing wrong — I think my being a native English speaker helps a little with avoiding some of these things. I’m sure I’d be just as bad (no, let’s be honest, far worse) if I tried to write the same thing in German, which I studied for several years without reaching a state of even semi-fluency.

  3. aklapper says:

    hi jeff,
    thanks a lot for the feedback, i really appreciate that!
    i’ve corrected the wording and uploaded a new version. if you find more errors, don’t hesitate to give feedback. :-)

  4. brunobol says:

    Great, Andre!!!
    Can I use on Epiphany?

  5. aklapper says:

    bruno: i think you can, i haven’t tried it though. but if epiphany lets you add extensions like firefox, it will work.

  6. Matěj says:

    brunobol, yes you can. You need greasemonkey which is now part of epiphany-extensions.
    http://www.gnome.org/projects/epiphany/extensions