bug triage

Phil Hannent phil at hannent.co.uk
Fri May 25 04:45:33 EDT 2007

Hash: SHA512

Luke Schierer wrote:
> 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.  
In our in house bug tracker the priority field is just for the developer and
maybe the project managers.  Reporters should *not* get to update the field as
really the developer needs to be able to order the bugs in the order they are
going to work on them not in on the criticality of the bug (which might be
slightly different).

> 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.
I would also suggest some feedback based on the status, in house we do not have
"Open" as a state as it would clearly be that if it wasn't closed.  We have the

Awaiting assignee
Being reviewed by assignee
Being tested by assignee
Sent to tester for retest
Need to talk to project lead
Request further information
Waiting to be installed on test machine

Clearly not all of these match Pidgins methods but it gives the developer the
ability to quickly remember where they are with any given bug and give those
interested in the bug feedback, without bothering the developer or adding
comments to the bug.

Phil Hannent
Version: GnuPG v1.4.6 (MingW32)


More information about the Devel mailing list