Smalltalk › Pharo › Pharo Smalltalk Developers

Why are issue priority automatically changed from 3 to 5 ?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Nicolai Hess-3-2

Why are issue priority automatically changed from 3 to 5 ?

For example:
19457 Scrolling Versionner configuration list is very slow
18778 FileList "View as" does not work
19221 Rub Find And Replace can not search for "?"

For me, these are issues that "must fix" and not "Fix If Time". Most issues are only

fixed "if someone has the time to do it" regardless how serious they are.

Fixed if time looks like , we can live without this as we did since the last

release, but actually we are just used to accept some bugs and regressions because

we know we are to small or to few develoeper to actually fix this issues.

I don't see any value in downgrading the priority - else we could just discard any priority.

nicolai

Ben Coman

Re: Why are issue priority automatically changed from 3 to 5 ?

On Mon, Jan 30, 2017 at 9:07 PM, Nicolai Hess <[hidden email]> wrote:

> For example:
> 19457 Scrolling Versionner configuration list is very slow
> 18778 FileList "View as" does not work
> 19221 Rub Find And Replace can not search for "?"
>
> For me, these are issues that "must fix" and not "Fix If Time". Most issues
> are only
> fixed "if someone has the time to do it" regardless how serious they are.
> Fixed if time looks like , we can live without this as we did since the last
> release, but actually we are just used to accept some bugs and regressions
> because
> we know we are to small or to few develoeper to actually fix this issues.
> I don't see any value in downgrading the priority - else we could just
> discard any priority.

Looking in from the sideline, I guess the situation it addresses is...
How likely was it that ALL previous priority 3 issues could be dealt
with before Pharo 6 Release? So some kind of sorting was required.
While a NewInPharo6 issue is not necessarily more important than an
ExistedInPharo5 issue, automatic downgrading of ExistedInPharo5 issues
seems a reasonable first pass. I would hope that for any particularly
issue you feel strongly about, you should just revert it, but perhaps
with the rule you need to downgrade an equivalent number of current
priority 3 issues to priority 4, whic provides further sorting.

my two cents worth,
cheers -ben

Pavel Krivanek-3

Re: Why are issue priority automatically changed from 3 to 5 ?

In reply to this post by Nicolai Hess-3-2

Hi Nicolai,

I'm checking all current issues marked for Pharo 6 and testing if they are new or the problem already existed in Pharo 5. According to it I'm marking it and for most cases (but not all) I'm decreasing the priority to "Fix if Time".

I understand you but look at the priorities as priorities for the releasing process. Of course a lot such issues should be fixed and if you think they must be fixed for the upcoming release, increase the priority. Currently the assignment of priorities is on issue reporters and they use different personal scales. This way we can unify that a little bit.

After finishing of the marking I wanted to ask people to think again about priorities of the reported issues. But If we already made a release with some issue, it probably means it is not extremely important.

This step needs to be done anyway or we will never finish the release. To do it now gives us more time to focus on really important things. We want every new release to be better that release before so it makes sense to firstly look at new problems we created.

Cheers,

-- Pavel

2017-01-30 14:07 GMT+01:00 Nicolai Hess <[hidden email]>:

For example:
19457 Scrolling Versionner configuration list is very slow
18778 FileList "View as" does not work
19221 Rub Find And Replace can not search for "?"

For me, these are issues that "must fix" and not "Fix If Time". Most issues are only
fixed "if someone has the time to do it" regardless how serious they are.
Fixed if time looks like , we can live without this as we did since the last
release, but actually we are just used to accept some bugs and regressions because
we know we are to small or to few develoeper to actually fix this issues.
I don't see any value in downgrading the priority - else we could just discard any priority.

nicolai

Nicolai Hess-3-2

Re: Why are issue priority automatically changed from 3 to 5 ?

2017-01-30 15:23 GMT+01:00 Pavel Krivanek <[hidden email]>:

Hi Nicolai,

I'm checking all current issues marked for Pharo 6 and testing if they are new or the problem already existed in Pharo 5. According to it I'm marking it and for most cases (but not all) I'm decreasing the priority to "Fix if Time".
I understand you but look at the priorities as priorities for the releasing process. Of course a lot such issues should be fixed and if you think they must be fixed for the upcoming release, increase the priority. Currently the assignment of priorities is on issue reporters and they use different personal scales. This way we can unify that a little bit.

After finishing of the marking I wanted to ask people to think again about priorities of the reported issues. But If we already made a release with some issue, it probably means it is not extremely important.

I am not talking about "extremely important" issues. If it is an issue that "must be fixed for this release", I would use the "show stopper" priority.

Now if some uses used his time to report an issue, say one as priority "fix if time" and another one "must fix", now we put all this issues to "fix if time", don't you think we loose some valuable information ?

If this issues won't be fixed in this release (because we don't have enough man power) we can always put them on "Later" instead of "Pharo 6.0"

For me, it makes a difference if some issues occure in some situations, where we can maybe work around, and can be fixed "if time" or if an issues is a bug

that must be fixed just because the functionality is just not working anymore.

This step needs to be done anyway or we will never finish the release. To do it now gives us more time to focus on really important things. We want every new release to be better that release before so it makes sense to firstly look at new problems we created.

I don't get this point. Some issues were just introduced in the pharo 5.0. So instead of seeing this issues as "must fix", we decrease the priority as "fix if time", so we can focus on the issues we introduced in Pharo 6.0?

Cheers,
-- Pavel

2017-01-30 14:07 GMT+01:00 Nicolai Hess <[hidden email]>:
For example:
19457 Scrolling Versionner configuration list is very slow
18778 FileList "View as" does not work
19221 Rub Find And Replace can not search for "?"

For me, these are issues that "must fix" and not "Fix If Time". Most issues are only
fixed "if someone has the time to do it" regardless how serious they are.
Fixed if time looks like , we can live without this as we did since the last
release, but actually we are just used to accept some bugs and regressions because
we know we are to small or to few develoeper to actually fix this issues.
I don't see any value in downgrading the priority - else we could just discard any priority.

nicolai

philippe.back@highoctane.be

Re: Why are issue priority automatically changed from 3 to 5 ?

+100

Priority has nothing to do with the release per se.

Phil

Le 31 janv. 2017 00:11, "Nicolai Hess" <[hidden email]> a écrit :

2017-01-30 15:23 GMT+01:00 Pavel Krivanek <[hidden email]>:
Hi Nicolai,

I'm checking all current issues marked for Pharo 6 and testing if they are new or the problem already existed in Pharo 5. According to it I'm marking it and for most cases (but not all) I'm decreasing the priority to "Fix if Time".
I understand you but look at the priorities as priorities for the releasing process. Of course a lot such issues should be fixed and if you think they must be fixed for the upcoming release, increase the priority. Currently the assignment of priorities is on issue reporters and they use different personal scales. This way we can unify that a little bit.

After finishing of the marking I wanted to ask people to think again about priorities of the reported issues. But If we already made a release with some issue, it probably means it is not extremely important.

I am not talking about "extremely important" issues. If it is an issue that "must be fixed for this release", I would use the "show stopper" priority.
Now if some uses used his time to report an issue, say one as priority "fix if time" and another one "must fix", now we put all this issues to "fix if time", don't you think we loose some valuable information ?
If this issues won't be fixed in this release (because we don't have enough man power) we can always put them on "Later" instead of "Pharo 6.0"
For me, it makes a difference if some issues occure in some situations, where we can maybe work around, and can be fixed "if time" or if an issues is a bug
that must be fixed just because the functionality is just not working anymore.

This step needs to be done anyway or we will never finish the release. To do it now gives us more time to focus on really important things. We want every new release to be better that release before so it makes sense to firstly look at new problems we created.

I don't get this point. Some issues were just introduced in the pharo 5.0. So instead of seeing this issues as "must fix", we decrease the priority as "fix if time", so we can focus on the issues we introduced in Pharo 6.0?

Cheers,
-- Pavel

2017-01-30 14:07 GMT+01:00 Nicolai Hess <[hidden email]>:
For example:
19457 Scrolling Versionner configuration list is very slow
18778 FileList "View as" does not work
19221 Rub Find And Replace can not search for "?"

For me, these are issues that "must fix" and not "Fix If Time". Most issues are only
fixed "if someone has the time to do it" regardless how serious they are.
Fixed if time looks like , we can live without this as we did since the last
release, but actually we are just used to accept some bugs and regressions because
we know we are to small or to few develoeper to actually fix this issues.
I don't see any value in downgrading the priority - else we could just discard any priority.

nicolai