bug triage

[Luke Schierer]

I need some advice here on how we as a project want to use trac.

Bugs are coming in at a very fast rate.  Historically, I have tried to
filter these for other developers, with varying success, so that they
have the best chance of being fixed.

With trac, we have several ways I can approach this.

With the SF trackers, we had a couple fields, owner, priority, group,
and category.

The latter two were difficult to use, I at least found it hard to make
meaningful categories and groups.  I ended up using the group field to
denote version number, and so tried to prevent bugs from sitting open
endlessly ignored.  The priority field was also hard to use, because
submitters would frequently re-prioritize their bugs.

With trac, we present a very simple interface to the user.  We have a
built in field for version number.

We have a milestone, a priority, a component, and key words.

Of these, I believe that the users can change the several of them at
submission, but none of them after that.  (I'm not 100% sure of this
though).

I set up a couple components: finch, pidgin, winpidgin, libpurple,
webpage and trac.  I have winpidgin as a separate component not in a
real attempt to discriminate against it, but because there still exist
problems that are specific to that environment, at least some of which
require a win32 system to replicate, and/or familiarity with win32 to
fully understand.  While I have at times abused it, I try not to.  I
believe the other components are self-explanitory.  I expect tickets to
move from component to component as the defect is isolated.

Is it useful for me to assign owners?  The project is growing rapidly,
and is already very complex.  Any attempt to assign ownership by me is
going to be subject to my faulty memory of who has last worked on what.  

Ethan seems to find this useful.  Do others?

I can also assign milestones.  This reflects my judgement of when a bug
ought to have been fixed by, or at least when it ought to have been
*looked* at by.  I realize however that there is significant room for
error in my estimates, and so to remain useful, some issues would have
to be recategorized.  While this has the potential to get us into the
habit of letting defects slip from milestone to milestone, it also has
the potential to remind us to look at bugs as a release nears.  Sean has
found the milestone estimates useful, do others? Should I continue?

Lastly, we have the priority field.  I have largely ignored this field,
but it could, for example, be used to denote that a bug should be bumped
from one milestone to another only if we change the milestone schedule
itself, if for example we were to determine there will be no 2.0.2
release, but will proceed directly to 2.1.0.  

What think you all?  What can I do to make your use of trac most
efficient?

While this email is primarily directed to developers and patch writers,
if others have experience with trac and can offer suggestions, I'm open
to that as well.

luke