[darcs-users] state of the issue tracker: triage complete!

Eric Kow kowey at darcs.net
Mon Sep 7 21:59:10 UTC 2009

Hi everybody,

Here's the latest update on the issue tracker status.  In the last
message, I reported that all explicitly unknown status bugs had been

I'm pleased to add that now *all* the open bugs have been triaged in a
similar fashion.

This means that all open tickets have been recently scrutinised and fit
into the rough pigeon holes I described in the last message.  They
should now also follow fairly consistent conventions in with respect to
use of the priorities, status and topics.  So I hope this will be useful
to us in the long run!

Bugs for everybody!
I want to be very clear that the issue tracker is for *everybody*
to use.  I may make a lot of noise about what status flags and topics
etc I apply to tickets, but that's only because (i) I want to reason out
loud about them (ii) I want readers to unconsciously absorb and
hopefully critique the methodology.

Nobody will jump on your back if you do something "wrong"; it's all
good.  So don't worry!  I'll be picky so you don't have to :-).  Please
just use the tracker without thinking too hard about it.  My hope is
that scheme I am using makes it easy for the natural thing to align with
the conventional thing, but if this is not the case we can always
renegotiate things.

Notable queries
Target 2.4:   http://tinyurl.com/darcs-target-2-4
ProbablyEasy: http://tinyurl.com/darcs-probablyeasy2   [101 entries]
Performance bugs: http://tinyurl.com/darcs-performance2 [44 entries]

Tweaks to conventions 
Details, details!  Just thinking aloud here, folks.

* Darcs-devel is now nosy on all bugs.  Please include bugs at darcs.net
  in your replies.  I'll look into making this automated.

* The tracker should be used for tracking, not talking.  Please hold
  discussions on darcs-users at darcs.net instead.

  Examples of tracking: have you tried foo? what happens when you
  wibble the bar? now we need a volunteer to blaz the qlup.  On
  darcs-users, we decided to blux the qlup rather than blazzing it.
  Examples of talking: eg: I think blazzing the qlup is way better that
  bluxing it because blah blah blah.  No actually but if you blaz it
  you'll have to deal with the flumping and we hate flumping.

  Again, if you get this wrong, No Big Deal!

* The 'need-info' status has now been changed to waiting-for, which means
  (i) we are waiting for somebody (usually the original reporter) to do
  something we specifically asked them for [or] (ii) that we are
  waiting for something to happen in the universe, a typical case being
  when a ticket depends on some other ticket being resolved.  Case (ii)
  used to be handled by 'deferred'

* The 'deferred' status is now being much more sparingly.  I think
  hiding deferred bugs by default is a good thing but that we should
  avoid over using this feature.  So I've set a lot of these bugs to
  'need-action' or 'need-implementation' (and some to 'waiting-for' if
  they are only being deferred because of a dependency).  The remaining
  uses of deferred basically mean something like "this basically isn't
  going to happen in the near to mid future" (think darcs-3 and beyond)

* Topics shakeup: I've thrown out a lot of topics which I thought were
  better modeled by other parts of the tracker (notably 'Confirmed' or
  'IncludesExampleOrTest').  Now you have four kinds of topics at
  your disposal.  I hope they make it easier to search the tracker:

   - priorities       (eg. ProbablyEasy, Regression, Target-2.4)
   - broad regions    (eg. Documentation, Core)
   - technical themes (eg. Hashed, ThePendingPatch, HTTP)
   - platforms        (eg. Windows, Mac)

  Basically I wanted topics that really effectively partitioned the

Where to from here
Now I can really shift out of triage (except for new incoming bugs) and
into proper maintenance mode.  I expect to be able to leave the tracker
[modulo new bugs and follow-ups] alone for the next month.

After one month I will begin a maintenance cycle, which consists of
looking at 2 open bugs a day, stalest bug first (see my 'Maintenance'
query for this).  If we stay on top of the tracker and go scrutinise 2
bugs every day, we should be able to assure a 6 month ping cycle for
*every* ticket.  If the number of bugs doubles, then we get a 1 year
ping cycle.

Meanwhile, my next job is to clean up a little bit of infrastructure (i)
merge duplicate users and (ii) think more about a patch tracker.

Apologies to those following darcs-devel for the spike in noise.  Things
should calm down a little bit from here.


Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090907/82430923/attachment.pgp>

More information about the darcs-users mailing list