[teampractices] Bugzilla migration Re: Project management tools review: Regressions/tradeoffs; migration

[Luis Villa]

On Wed, Mar 26, 2014 at 3:34 PM, Bryan Davis <bd808 at wikimedia.org> wrote:

>
> A giant bug triage and resolve party does sound generally useful
> however. It sounds exhausting as well. :)


Bugzilla/future bug tracking system, first and foremost, has to serve the
developers by helping them figure out what to work on next. Old bugs can
make the BTS less effective at that goal, by cluttering developer queries.

If old bugs are making the BTS less effective at that goal, then purging
them is often one legitimate way to deal with the problem.

Some factors to consider when figuring out if a purge is a good way to deal
with the problem of old bugs that aren't helping developers:

   1. Flow of incoming bugs:
      1. Who files these: mostly developers? one-time users?
      repeated/ongoing reporters?
      2. What are their motives?
      3. How will changes to old bugs impact their motives? Will it
      discourage them (say, because they are repeat reporters, and/or
because the
      change was poorly explained)? Will it have no impact (say,
because many of
      the old bug reporters only filed one bug and wouldn't return anyway?)
      4. How many are they, relative to developers/triagers?
      2. Cost of "stale" bugs:
      1. Do old bugs clutter developer queries, and therefore push
      developers to use other planning tools, or worse, ignore new bug reports?
      Or has the project been good at aggressively triaging/closing existing
      bugs, such that remaining open old bugs are consistently
relevant/important
      to current code base and active development? (Note that you could be good
      now at triaging incoming bugs, but still have a huge backlog of old bugs
      that are impractical to deal with because there are so many of them.)
       2. Do old bugs represent genuine stores of useful knowledge about
      the current codebase? (May not be the case if they are so old
the relevant
      code has been substantially rewritten, for example, or if
development focus
      has shifted for some other reason.)
      3. If you're considering closing old bugs, are there objective
      criteria you can use (short of manually re-triaging each old
bug) to close
      those that are likely to have higher costs/lower benefits?

Or to try to put it another way: it is common that old bugs are actively
harmful to developers by making the BTS less useful, particularly in large,
old projects, where change in the code makes it hard to reproduce old bugs,
or likely that they are no longer relevant. And if there are a small number
of triagers/developers and a large number of bug filers, it can make sense
to ask those large numbers to take on a small burden (verify that the old
bug is relevant to a new codebase) rather than a large burden on the small
# of triagers developers. So closing very old bugs en masse (particularly
if you can identify ones that are more likely to be useful and keep those
open, or give them particular triaging attention) can be a
legitimate/useful tool.

HTH-
Luis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20140328/df29e93c/attachment.html>