Re: [Pharo-dev] Why are issue priority automatically changed from 3 to 5 ?

[philippe.b...@highoctane.be]

+100
Priority has nothing to do with the release per se.

Phil

Le 31 janv. 2017 00:11, "Nicolai Hess"  a écrit :

>
>
> 2017-01-30 15:23 GMT+01:00 Pavel Krivanek :
>
>> 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 :
>>
>>> 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
>>>
>>
>>
>

Re: [Pharo-dev] Why are issue priority automatically changed from 3 to 5 ?

[Nicolai Hess]

2017-01-30 15:23 GMT+01:00 Pavel Krivanek :

> 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 :
>
>> 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
>>
>
>

Re: [Pharo-dev] Why are issue priority automatically changed from 3 to 5 ?

[Pavel Krivanek]

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 :

> 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
>

Re: [Pharo-dev] Why are issue priority automatically changed from 3 to 5 ?

[Ben Coman]

On Mon, Jan 30, 2017 at 9:07 PM, Nicolai Hess  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

[Pharo-dev] Why are issue priority automatically changed from 3 to 5 ?

[Nicolai Hess]

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