You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by Mike Beckerle <mb...@tresys.com> on 2018/09/07 16:43:55 UTC
JIRA ticket releases - never and deferred
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?
Re: JIRA ticket releases - never and deferred
Posted by Mike Beckerle <mb...@tresys.com>.
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 <sl...@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?
>
>
>
>
Re: JIRA ticket releases - never and deferred
Posted by Steve Lawrence <sl...@apache.org>.
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?
>
>
>
>