I was thinking we might be able to address this issue through JIRA's voting procedure. Perhaps a rule of "If an issue has two votes, it must be dealt with before the release." Then we could add those issues to the release plan as a reminder (and requirement) for the release.
Two votes (plus the original reporter who can't vote for his own issue) seems to me to be a good standard for whether or not something is urgent. Of course there could be an urgent bug that nobody votes for, but its a start. I agree with Craig that we should be definitive about what is going to be deferred and what is not. Perhaps we could add a "TBD" version (for "To Be Determined") and mark bugs that we are intentionally deferring as such. The JIRA voting system could help us sort them out. Thoughts? sean On 8/2/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 8/2/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > Count me in! > > > > +1 for a release plan, but not as detailed, I would say - listing a 100 > > bugs is not so informative, I'd say. > > > > The purpose of listing the outstanding bugs isn't really to be > informative (you can do your own queries just as easily). The purpose > is to motivate the developers to dispense with them -- either get them > fixed (and therefore off the list), or deliberately decide to defer > them (and list them as outstanding issues on the release notes). > > Either outcome is OK -- what's not OK is uncertainty about whether a > particular issue is going to get addressed or not. And, if it's on a > list like this, there's no excuse for a developer to say "but I didn't > *know* about that problem" ... :-) > > > regards, > > > > Martin > > > > Craig >
