On 12/1/05, Don Brown <[EMAIL PROTECTED]> wrote: > Step 2: > - Move closed tickets included in soon-to-be-released projects to their > milestone. > - Wade through TBD tickets and assign to milestones > > While I like Martin's idea of only putting tickets to milestones when someone > commits to resolving them, I'm afraid it would distort the roadmap by giving > the > wrong impression that we are always close to a release. Perhaps we could > start > using the "Assigned" field more often to mark which ones have been taken up > and > which are just hanging.
I'd be more concerned about giving people the wrong impression that someone is going to resolve the ticket before the next release. IMHO, if a committer assigns a ticket to a milestone, then that committer is saying he or she is going to make it so. :) Otherwise, we have a situation where someone who is not planning to do the work is making the decision :) And, if the bugs are resolved, we *should* always be close to a release. In 1.0 to 1.1 era, we were always saying "let's get this one last feature in before we release". I don't think that worked well for us. If we start setting tickets to milestones when there is not a volunteer ready, willing, and able to work on the ticket, we're falling back into the old pattern that says a release has to be big to be worthwhile. Hey, I'd be in favor of releasing after any ticket is resolved. Fix a bug, add a feature, roll a release -- works for me! If we end up with milestones like 2.3.52, then so be it. MySQL does that, and I never blinked. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]