On Thu, Aug 14, 2008 at 22:33:39 -0400, Mark Stosberg wrote: > I agree with this assessment of what they mean. I think we could do without > the > "feature" priority, though.
I was going to say +1 for collapsing feature into wishlist, but what if we don't know what release we want this to be critical for, but we do know it's a pretty 'big' wishlist item? How do we declare that, as it worth trying? > If it's really a problem that we are missing a feature, we could call that a > bug, or we could track features as "wishlist" items that have been tagged as > "Release Critical" for the next release. > > "feature" gets well-intentionally mis-used by users who are likely find the > difference between "wishlist" confusing. I got confused when I first started triaging, thinking that feature essentially corresponding to actually adding, for example, a new command or switch, whereas wishlist was something that needs to change. In retrospect, that was a silly distinction. > They mark a request as as "feature", which I think only a > developer/project manager should declare that a particular change is > desired in the next release. (While anyone can "wish" for something to > be considered). Nod. > > * undecided: duplicate vs. resolved vs. deferred: > > * I don't like using resolved for duplicates, because it makes it harder > > to search for a bug and determine if it has already been fixed or not > > * But if we just use 'duplicate' we can't tell if it's a duplicate of a > > fixed bug or not > > I would mark a bug a duplicate while the issue is still open (in some other > ticket) and then mark it as resolved when the other ticket is resolve, so that > the ticket requestors of the dupe ticket are notified that it is resolved. Yes. This means gardening the duplicates. Perhaps we just need a script that says 'if I am a duplicate, and my supereceder is resolved, then I am resolved', maybe with a message saying so and requesting that the original poster check for themselves. > I use 'deferred' as a way of saying "lower priority" Usually this goes along > with wishlist requests. Fine > I like this use of "need-eg", although I just renamed it to > > "need-info", so it is a more general purpose way to say > "the ball is stalled in the requestors court. Good. Now we have an all purpose "we can take no action until somebody tells us something" > > * what does in-progress mean? > > Maybe it means "Quit bugging about this...we're activetly working on it". > This tag doesn't get used much. Thanks very much for adding these tags and starting the discussion! These may seem like silly details, but it's important to get them right so that using the bug tracker becomes obvious. We want it so that anybody can pigeonhole a bug easily, thereby avoiding bugtracker-rot. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
pgpQrs1hhEMG1.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
