Why are issue priority automatically changed from 3 to 5 ?
For example: 19457 <https://pharo.fogbugz.com/f/cases/19457/Scrolling-Versionner-configuration-l...> Scrolling Versionner configuration list is very slow 18778 <https://pharo.fogbugz.com/f/cases/18778/FileList-View-as-does-not-work> FileList "View as" does not work 19221 <https://pharo.fogbugz.com/f/cases/19221/Rub-Find-And-Replace-can-not-search-...> 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
On Mon, Jan 30, 2017 at 9:07 PM, Nicolai Hess <nicolaihess@gmail.com> 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
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 <nicolaihess@gmail.com>:
For example: 19457 <https://pharo.fogbugz.com/f/cases/19457/Scrolling-Versionner-configuration-l...> Scrolling Versionner configuration list is very slow 18778 <https://pharo.fogbugz.com/f/cases/18778/FileList-View-as-does-not-work> FileList "View as" does not work 19221 <https://pharo.fogbugz.com/f/cases/19221/Rub-Find-And-Replace-can-not-search-...> 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
2017-01-30 15:23 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
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 <nicolaihess@gmail.com>:
For example: 19457 <https://pharo.fogbugz.com/f/cases/19457/Scrolling-Versionner-configuration-l...> Scrolling Versionner configuration list is very slow 18778 <https://pharo.fogbugz.com/f/cases/18778/FileList-View-as-does-not-work> FileList "View as" does not work 19221 <https://pharo.fogbugz.com/f/cases/19221/Rub-Find-And-Replace-can-not-search-...> 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
+100 Priority has nothing to do with the release per se. Phil Le 31 janv. 2017 00:11, "Nicolai Hess" <nicolaihess@gmail.com> a écrit :
2017-01-30 15:23 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
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 <nicolaihess@gmail.com>:
For example: 19457 <https://pharo.fogbugz.com/f/cases/19457/Scrolling-Versionner-configuration-l...> Scrolling Versionner configuration list is very slow 18778 <https://pharo.fogbugz.com/f/cases/18778/FileList-View-as-does-not-work> FileList "View as" does not work 19221 <https://pharo.fogbugz.com/f/cases/19221/Rub-Find-And-Replace-can-not-search-...> 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
participants (4)
-
Ben Coman -
Nicolai Hess -
Pavel Krivanek -
philippe.back＠highoctane.be