[PLUG] Bug-tracking software.

Rogan Creswick creswick at gmail.com
Tue May 15 07:37:41 UTC 2007


On 5/14/07, Ronald Chmara <ron at opus1.com> wrote:
>
> On May 14, 2007, at 10:17 AM, Rogan Creswick wrote:
>
> > Does anyone have recommendations for a web-based bug tracking system?
>
> Well, a requirements phase might help you winnow down your needs... :)

We're looking for something relatively simple.  That is, the number of
things that need/can be specified for a given bug will ideally be
small -- in the half-dozen or so range.  A bare minimum is probably:
severity, state, description, reported by, assigned to, entered date,
and the ability to attach files of mixed types (screenshots, data
files, etc.).  It would be nice to be able to specify milestones, but
the options presented by mantis are overwhelming.  (Before decrying my
reluctance to have a field to hold the "bounty" for a bug, or the
iteration, sub-iteration, build number, sub-build number, and XP Pair
programmer's favorite color, please bear with me.)

Almost all of the projects we conduct are very, very small teams (2-3
people), and very short-term.  The complete life cycle of a code base
rarely exceeds 8 months, because our funding comes in 6-9 month
chunks, and usually only about 3 months are actually dedicated to
development.  It really isn't worth the time to figure out how many
iterations we're going to have for most projects -- but we *do* need
some way to easily keep unique id's on all of our bugs, and a place to
put reproduction steps.

> Something I've found helpful is to not introduce new *software* to a
> team, but instead introduce new *process*. If your devs are ignoring
> duties in tracking/documenting their work, and you introduce a new
> system that "will be used for generating metrics used in performance
> reviews", that is suddenly a totally different beast than "hey, look,
> yet another system to track our outstanding bugs", of which coders
> have seen, oh, more than a few. :)

Unfortunately, I'm actually the "new guy", so I can't exactly wave
threats of performance reviews. (I'm also "just" a dev, not a sysadmin
or manager.) I just happen to be the only *nix geek in the office, and
I'm a picky bastard when it comes to development tools.

> I love mantis, but hate bugzilla. It's a balance of granularity, ease
> of use, and purpose. Mantis isn't suited for maintaining 17
> concurrent releases of software versions, and bugzilla excels in this
> field, but fails to be a "20 second tool" for quickly entering and
> disposing of issues.

I looked at Mantis again today, and still found the interface to be
extremely difficult to use.  All the information I wanted to see (eg:
bug title) was in the middle of a mass of tables in a non-descript
font.  I'll spend some more time looking at it to see about
configuration options, but I'm not impressed thus far.  It may just be
that Mantis is more focused on the *management* of bugs, and less
focused on the *content* of bugs.  This is probably the way it should
be for large projects, but I don't believe that this is the case for
the size of code base we work with.

The search capabilities do seem better than what I remember, however.

> The biggest *process* problem I run into is when the CXO can enter
> bugs like "website broken" or "something isn't working right", but
> that's more of a process issue. In such an environment, an
> entomologist is needed, a dedicated bug hunter, tracker, and
> classifier, in order to hand out (and annotate, verify, and clarify)
> bugs to those who can fix issues. Or alternately, only allow the
> folks who program to fill out the online bug system, but allow others
> to 'submit bugs' to the entomologist.

That's essentially how we work -- any non-devs who find a bug report
it to a dev.  This is even pretty rare though, since we really only
write prototype code, and the authors are always the ones running
demos. Coding is just a means to an end for us (usually publication).

Thanks for all the advice so far,
--Rogan



More information about the PLUG mailing list