On 12/1/05, Don Brown <[EMAIL PROTECTED]> wrote: > > In my opinion, it would be simpler to assign those tickets to the next > major/minor release, forcing developers to assess when that milestone is > on deck > whether the ticket will actually get fixed in this one or moved further > down. > The problem with this "1.1 Family" is evident in Bugzilla where we have a > bunch > of tickets still assigned to the 1.2.x family. I think these family > categories > are just corners where tickets go to hide and be forgotten.
+1 Personally, I think even a "Future" or "TBD" milestone clouds the issue, but > it > would be a good compromise. What I'm going for is tickets are only > assigned to > a milestone when someone steps up and says they'll fix them or the > community > agrees it is a requirement of the milestone. What I'd like to see is that, when an issue is assigned to a milestone, it means that someone has committed to make sure it gets into that milestone, not that someone thinks it would be a good idea to get it into that milestone but isn't stepping up to make that happen. If we abide by that, then I think we can add an Unspecified (or New or Undecided) as an initial default. Whether we need an additional value for "probably never", I'm not really sure, but I tend to think that if we just have Unspecified, that should be enough. As for the "probably never" tickets, just sitting in Bugzilla not having a > milestone will be enough to keep them from the casual project view > (assuming we > put in place a clean roadmap). > > In general, I think the most simple solution will be the one that lives > the > longest and brings the most clarity. +1 -- Martin Cooper Don > > Ted Husted wrote: > > On 12/1/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > >>Did we agree anything on bugs which we don't want to allocate to a > >>milestone - my preference is a "probably never" or "un-allocated" > >>milestone - something we can query on. Personally I don't like "LATER" > >>resolutions - IMO thats not a "resolution". > > > > > > In my own project, we have a major release pseudo-release for issues > > that we haven't allocated yet, and then true mliestone releases for > > issues that'ave we have allocated, so the JIRA map looks like this: > > > > [Unreleased] 2.x ( Release Notes) > > Progress: [Unresolved Issues - 100% (4 issues)] > > 0 of 4 issues have been resolved > > New Feature (Story) WNE-77 UNRESOLVED A user by any other role > > New Feature (Story) WNE-76 UNRESOLVED Attachments > > New Feature (Story) WNE-75 UNRESOLVED Multiple comment > > New Feature (Story) WNE-44 UNRESOLVED Optimistic locking > > > > [Unreleased] 2.0.16 ( 2005-Dec-13 | Release Notes) > > Progress: [Resolved Issues - 9% (1 issues)] [Unresolved Issues > - > > 90% (10 issues)] > > 1 of 11 issues have been resolved > > New Feature (Story) WNE-16 UNRESOLVED Add Facility Mandate > > New Feature (Story) WNE-19 UNRESOLVED Delete an Action and a > Violation > > New Feature (Story) WNE-84 UNRESOLVED Meeting Table > > .... > > > > ---- > > > > So, "2.x" is the "undecided" category for our 2.x release series. > > > > -Ted. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
