LWN.net Logo

Users doing bug triaging

Users doing bug triaging

Posted Mar 3, 2009 13:01 UTC (Tue) by epa (subscriber, #39769)
In reply to: Ubuntu now offering mainline kernel builds by fb
Parent article: Ubuntu now offering mainline kernel builds

The first problem you mention, of falsely marking bugs as duplicates, might be helped by having a 'not-duplicate' field in the bug tracker to complement the 'duplicate' field. So as well as writing in the description 'this is not a dup of #123 because...' you would also encode that information in machine-readable form as not-duplicate=123. Trying to mark it as duplicate would require an extra explicit step to override that marker.

I haven't used Launchpad's bug tracking, but I suspect the problem is in user interfaces that present bugs as bad things or todo items, and closing bugs as a good thing. Instead of the aim of the process being to improve the software, the aim becomes to close as many bugs as possible. You get a good feeling from marking a bug 'dup' or 'wontfix' or 'needinfo' and it disappears from your todo list. It feels like an annoyance when the pesky reporter comes back and asks for it to be reopened.

In my view the most useful thing that non-programmers can do with a bug report is to reproduce it. Not to ask the reporter whether it still occurs in the latest version, but to follow the recipe themselves and report whether they can verify the bug. If the instructions on how to trigger the bug are not clear, then of course the triager can ask for clarification.

Making a bug reproducible is often the hardest part of the process; once you have a test case for reliably making a bug appear, fixing it is often trivial.

So I would suggest the visual rewards given by the bug tracker for making progress on bugs should be weighted towards activities that add value. A bug's possible states might go through

unconfirmed
unconfirmed, but has a recipe to reproduce it
confirmed (by N separate people)
test case written
test case confirmed as valid by upstream

Each of these states is better than the previous one and could be displayed appropriately (perhaps a 'golden bug' for one that has a test case). However it works, the interface needs to give the perception that while bugs are a bad thing, bug *reports* are a very good thing, to be nurtured, tested and reproduced, not closed.


(Log in to post comments)

Users doing bug triaging

Posted Mar 3, 2009 18:39 UTC (Tue) by iabervon (subscriber, #722) [Link]

In theory, there should be no problem with having your bug marked as a duplicate of some other bug; that should mean that the other bug is seen as more important (more people have the problem), and it gets fixed, and either (a) the fix works for you (in which case it was a duplicate) or (b) the fix doesn't work for you. If (b) keeps occurring, whoever's marking them wrong should have bad stats.

Personally, I think bug trackers should have support for a "me too" feature, where you find a bug in the database that you think is happening to you, and file an intentional duplicate (already marked as such) with your particular conditions. Then people trying to fix the bug get a bigger pool of reporters who might be able to test possible fixes (and find out about variations that don't affect the outcome, which is useful for eliminating ideas), and people who find their problem in the database can track it more directly.

And, of course, it should count more to close a bug (successfully) with a lot of duplicates, if those duplicates verify the fix.

Users doing bug triaging

Posted Mar 3, 2009 21:13 UTC (Tue) by fb (subscriber, #53265) [Link]

> In theory, there should be no problem with having your bug marked as a duplicate of some other bug;

IMHO both in theory as in practice there is a problem. In theory each bug should have its own report. In practice often there is already a lot of tracking info in one bug, which gets lost ni the cross fire after merging. Second, it leads to conflicting reports, which makes it confusing for whoever is trying to verify, or fix it.


> Personally, I think bug trackers should have support for a "me too"
> feature, where you find a bug in the database that you think is happening
> to you, and file an intentional duplicate (already marked as such) with
> your particular conditions.

Actually launchpad has something like you describe, as users can subscribe to a bug. So you as a developer could choose to look first at the one bug with 25 subscribers, and not at the one with just 2.

Users doing bug triaging

Posted Mar 3, 2009 21:14 UTC (Tue) by fb (subscriber, #53265) [Link]

FWIW, I couldn't agree more with your words.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds