When doing triage on this BTS, I'm bugged by the ambiguity of some of
the existing practices.  In particular,

 - The difference between feature and wishlist isn't obvious.

 - Why should any bug have status need-volunteer?  Surely every bug
   that's unresolved and unassigned IMPLICITLY needs a volunteer.

   More generally, since status and priority can (respectively) have
   only one value at a time (unlike topic), values for these fields
   should be defined such that they can never "overlap".

 - 'Control-C Ctrl-C C-c' is annoying because it's very long and
   contains spaces.

In the past I started to address these problems by basically trying to
make our BTS act like Debian's debbugs (http://bugs.debian.org).  This
was more disruptive than helpful, because it was undiscussed,
unilateral and incomplete.

Therefore I propose "doing it right", by spending some time looking at
other BTSes, stealing their best practices, and working out a coherent
vision of how we want our BTS to work.

Oh, and in the short term, the BTS should probably link to the wiki's
BugTracker* pages, which explain the semantics of current statuses,
priorities and topics.

I agree that a research project on this would be a good idea, so I'm marking
this need-volunteer (hah!) for somebody to please:
  1. identify 3 projects with similar needs to Darcs
  2. study how they use their bugtrackers.  It may be good for at least one of
these projects to be using roundup (say, roundup themselves)
  3. and write a summary on how they uses priorities and statuses

Other concrete tasks to perform are
  4. tidy up the BugTracker* pages on the wiki
  5. add the to the roundup template

I think 4-5 need to be done by me and perhaps 1-3 too, but I'm always happy to
have help, hence the need-volunteer

I realise that this is somewhat besides the point, but if I may clarify some of
the points Trent raised

 - need-volunteer: the idea behind "need-volunteer" is to identify tickets
   where we have identified a concrete physical action that needs to be
   performed before the bug can move forward.  For example: "I need a volunteer
   to darcs get this repository and run X test on it and tell me Y".

   In other words it means "you don't have to figure out what to do about this
   bug (if you don't want to) because somebody else already has; please do the
   requested thing".  Perhaps needs-concrete-action is a better term, although
   I did want to highlight "just needs somebody to step up to the plate and do
   something".

   What may be annoying about it is that can either mean something like
   need-info and needs-implementation.  There is also a risk that this status
   only really makes sense to people who use a Getting Thing Done worldview
   and I'm willing to bend to the rest of the non-GTD BTS universe :-)

 - I think the intention behind Control-C etc is so that you wouldn't have to
   think about what variant you're looking for, but I personally prefer having
   just one string (for the reason Trent pointed out), so I'm changing that.

 - Feature and wishlist are fuzzy.  It's really just a notion of priorities.
   Feature is "yeah, let's work on that!" and wishlist is more "patches
   welcome!"  (maybe we should rename wishlist to patches-welcome :-P)

Just a note that I've been doing some tidying (regrettably without taking the
trouble to research other bug-trackers)

One thing I've done was to split need-volunteer into need-action (need some
diagnostics action) and need-implementation (we know what to hack, now go hack).
 So hopefully this will be less fuzzy and easier to apply.

I'll leave this open because this is still very much a work in progress.

Here's the latest list of topics:
http://wiki.darcs.net/BugTracker/Topics

Should need-foo sort before chatting/unread?  Currently the ordering is

  unread, chatting
  need-info, need-action, need-implementation
  in-progress
  duplicate, wont-fix, presumed-dead
  deferred
  resolved

When I sort by status in order to find things to do, should triage (unread, chatting) be before
tickets that need some kind of concrete action?

Perhaps my real question is: what does the status ordering denote?  I'd expect the latter order to
be

  in-progress
  deferred, wont-fix
  duplicate
  presumed-dead, resolved

since deferred/wont-fix bugs might still have activity (with people volunteering to do the work),
whereas duplicate, moribund or resolved bugs are very unlikely to be of further use.

Another Roundup BTS is bugs.python.org.  I just noticed that its status and priority lists have an extra
description field, providing a one-sentence explanation of each value.  I think this is a good idea; any
wiki page on the BTS can then include those tables verbatim, and go into additional details in prose.

  http://bugs.python.org/status
  http://bugs.python.org/priority
  http://bugs.python.org/keyword

I expect implementing this will require changes to the .tal files at http://darcs.net/darcsbugtracker.
If the description field isn't already present in the database, it'll also require changes to the schema.

If you wanted to get really fancy, I suppose you could even include the description sentence as a tooltip
whenever you printed that value in a list of issues, using ABBR or whatever.

On Sat, Aug 15, 2009 at 03:11:15 +0000, Trent W. Buck wrote:
>   unread, chatting
>   need-info, need-action, need-implementation
>   in-progress
>   duplicate, wont-fix, presumed-dead
>   deferred
>   resolved
> 
> When I sort by status in order to find things to do, should triage (unread, chatting) be before
> tickets that need some kind of concrete action?

I think so.  I want to place an emphasis on triage.  The goal is for
there to be zero unread/chatting bugs.

Keep things moving.

The order should reflect a sort of rough treadmill of increasing
done-ness.

> Perhaps my real question is: what does the status ordering denote?  I'd expect the latter order to
> be
> 
>   in-progress
>   deferred, wont-fix
>   duplicate
>   presumed-dead, resolved

So following your advice it's now:

   unread
   chatting

   need-info
   need-action
   need-implementation

   in-progress

   deferred
   wont-fix

   duplicate
   presumed-dead
   resolved

I think this is now fairly stable.  See http://wiki.darcs.net/BugTracker