I agree that most bugs should be in no-assigned version unless there's a specific plan (and developer) to add them to a release, or they're part of the theme for that release.
Priority, up-votes, etc can be used to "suggest" a bug for fixing. So I think we should just delete all the fix versions for all open tickets except a few that we are already working, or that are clearly in scope of 2.3.0 ________________________________ From: Steve Lawrence <slawre...@apache.org> Sent: Thursday, September 13, 2018 8:29:41 AM To: dev@daffodil.apache.org; Mike Beckerle Subject: Re: JIRA ticket releases - never and deferred I agree with this. "never" and "deferred" should be changed to have no fix version. Related, it might also be useful change how we assign Fix Versions in general. Currently, when we create new bugs they are just assigned to the next planned release. And when we do a release, we just bump all the unresolved bugs to the next version. This makes it difficult to figure out how much work is actually remaining for a release, so the fix version isn't all that useful. So, what are thoughts on removing the fix version from all unresolved tickets, except for those that are actually planned for a particular release? This doesn't mean that we can't/won't fix other issues during a release, but it gives us a better idea of what is planned for a release and how much effort remains. This would also make the "Roadmap for Upcoming Release" page somewhat redundant--bugs will just be assigned to future fix versions. - Steve On 09/07/2018 12:43 PM, Mike Beckerle wrote: > So our assignment of tickets to these quasi-releases 'never' and 'deferred' > is no longer serving us the way we need it to. > > > They become value-judgements on the importance of the issue, but that's in > the mind of current active team, and the users those active team members know > about. > > > E.g., for me bi-directional charset properties aren't important. But to some > other new contributor, that may be their passion and skill set. We don't want > to discourage that. > > > So I think we should get rid of "never" and "deferred", and leave those > tickets with no release specified, and go with just labels "beginner" for > easy introductory things, and "hard" for things where we're documenting that > the feature/bug exists, but explicitly pointing out that it is either very > hard to fix, or we don't know how to fix it at all (e.g., > utf16Width='variable' on Java JVM implementation of DFDL). > > > Priority major or critical/blocker are for the tickets assocaited with a > release, that are associated with the theme-features of that release. Other > things are going to be major or minor priority, purely based on perception, > and easy (beginner), medium (Not labeled), or hard. > > > Thoughts? > > > >
