I hate to say this, but often when somebody does lots of bug triage on a
package I work on, I find it to be a net loss for me. I end up having to go
through all the things that were changed, correct a bunch of them,
occasionally pacify angry bug submitters, and all the rest of it, and often
the benefits are minimal at best.
I would very much like this not to be the case. Bug triage is supposed to
help developers be more efficient, and I think most people who do bug triage
are generally well-intentioned and eager to help. Accordingly, here is a
series of mini-rants intended to have educational value.
Bugs are not like fruit.
Fruit goes bad if you leave it too long. By and large, bugs don’t,
especially if they’re on software that doesn’t change very much. There
is no reason why a bug filed against a package in Ubuntu 4.10 where the
relevant code hasn’t changed much since shouldn’t still be perfectly
valid. Even if it isn’t, it deserves proper consideration.
My biggest single annoyance with bug triage is people coming around and
asking if bugs are still valid when they haven’t put any effort into
reproducing them themselves. This annoys bug submitters too; every so
often somebody replies and says “didn’t you even bother to check?”.
This gives a very bad impression of us as a project - wouldn’t it be
better if we looked as if we knew what we were talking about? There is
a good reason to do this kind of check, of course: random undiagnosed
crash reports and the like may well go away due to related changes, and
it is occasionally worth checking. But if the bug is already
well-understood and/or well-described, you should just go and check
whether it’s still there rather than asking.
As I understand it, the intended workflow is that people file bugs, then
if they aren’t clear enough bug triagers work with the submitter to
gather information until they are, then they’re passed to developers for
further work. We seem to have added an extra step wherein submitters
must periodically give their bug a health-check, and if they don’t then
it gets closed as being out of date. In a small minority of cases this
is useful; in most cases, frankly, it makes us look a bit clueless. Can
we please stop doing this? The more we waste people’s time doing this,
the less likely it is that they’ll bother to respond to us, and this
might help our statistics but doesn’t help the project as a whole.
I know that there’s a problem with bug count. I think every project of
non-trivial size has that problem. But, honestly, the right answer is
to fix more bugs - and, personally, I would be able to spend more time
doing that if I weren’t often running around trying to make sure that
bugs I care about aren’t getting overenthusiastically closed just
because somebody thinks they’ve been lying around too long.
There is a good way to expire bugs like this, of course. It goes
something like this: “I’ve read through your bug and tried to reproduce
it with a current release, but I’m afraid I can’t do so. Are you still
experiencing it? If not, then I think it might have been fixed by [this
change I found in the package’s history that seems to be related].” You
can’t do this en masse, but you’ll get a much better response from
submitters, you’ll learn more doing it, and in the process of doing the
necessary investigation of each bug you’ll find that there are many
cases you don’t have to ask about at all.
Wishlist bugs are not intrinsically bad.
There are certainly cases where something is far too broad or vague for
a bug report; but there are also plenty of cases, probably far more,
where the wish in question is a relatively small change to the program,
or doesn’t need any more sophisticated tracking, and a wishlist bug is
just right. If you don’t know the program very well, it may be
difficult to tell whether a wishlist bug is appropriate or not; in that
case, just leave the bug alone.
Please, for the love of all that’s holy, don’t close wishlist bugs
saying that people should use Brainstorm or write a specification
instead! If you don’t want to see wishlist bugs in your statistics,
just filter them out; it’s quite easy to do. Even worse, don’t tell
people that something probably isn’t a good idea when you aren’t
familiar with the software; people who have gone to the effort of
writing up their idea for us deserve a response from somebody who knows
the software well. I’ve encountered cases where friends of mine
submitted a bug report (sometimes even at my request) and then a triager
told them it was a bad idea and closed their bug. This sort of thing
puts people off Ubuntu.
Specifications are software design documents. As such, they are best
written by software designers. People who tell other people to go and
write a specification may not realise that as a result of doing this for
three years it’s now essentially impossible to find anything in the
specification system! The intent was never that every user of Ubuntu
would need to write a specification to get anything changed;
specifications are used by developers to document the results of
discussions and write up plans. They are not a straightforward
alternative to wishlist bugs, nor do they turn out to work very well as
what many formal processes call “requirements documents”; the process of
refining the latter in the context of Ubuntu might involve wishlist
bugs, mailing list threads, wiki pages, private discussions with
developers, or things of that nature, and probably shouldn’t involve
creating a specification until the requirements-gathering process is
Closing a bug is taking an item off somebody’s to-do list.
You wouldn’t go up to a colleague’s whiteboard and take an eraser to it
unless you were sure that was OK, would you? Yet people seem to do that
all the time with bugs. It’s OK when the bug is really just like a
support request - “help, it crashed, what do I do?” - and either you’re
pretty sure it’s user error or there’s just no way to get enough
information to fix it. But once the initial triage process is done, now
it’s on somebody’s to-do list.
This is closely related to …
If a developer has accepted it, leave it alone.
Every so often I find that there’s a bug that I have accepted by way of
a bug comment or setting to Triaged or whatever, or even a bug that I
filed on a package I work on as a reminder to myself, and somebody comes
along and asks for more information or asks if we can still reproduce it
or something. The hit rate on this kind of thing is extraordinarily
low. There’s a good chance that the developer went and verified the bug
against the code, and in that case it certainly doesn’t need more
information (or they would have asked for it) and it probably isn’t
going to go away without anyone noticing.
In most other free software projects, developers file bug reports
themselves as a reminder about things that need to be done, and people
leave them alone unless they’re intending to help with the fix. In
Ubuntu, developers also have to spend time making sure that those to-do
items don’t get expired. Nobody is helped by this.
includes a Greasemonkey script called
lp_karma_suffix, which can help
you to identify developers without having to spend lots of time clicking around.
Check whether the package is being actively worked on.
Some packages are actively worked on in Ubuntu; some aren’t (e.g. we
just sync packages from Debian, or they’re basically orphaned, or
whatever). It’s worth checking which is which before doing any kind of
extensive triage work. If it’s being actively worked on, why not go and
talk to the developer(s) in question first? It’s only polite, and it
will probably help you to do a better job.