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 triaged.
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 [email protected] in your replies. I'll look into making this automated. * The tracker should be used for tracking, not talking. Please hold discussions on [email protected] 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 bugs. 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. Thanks! -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
pgpQr6tvuqfYl.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
