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