Le 11/10/2015 12:19, Liviu Andronic a écrit :
This way .x targets are indicative of the relative recent nature of
the bug, which is still useful info.
It is useful to know if a bug is recent, but we already have the bug #
and often the version, no?
I think that Guillaumes proposal to use the priority is more consistent
whith user expectations: A bug with high priority is important. We would
probably need to adjust our bug searching habits a bit (and I'd also like
preconfigured views in trac that show high priority bugs), but then it could
work.
Senior devels will know better, but from what I understand we mostly
use Priority to indicate "very bad bugs" (i.e. crashes, regressions,
dataloss and associated issues, usually marked as "high" or "highest",
What about:
very bad bug -> highest = red
something a community member judges important -> high = yellow
?
and usually hand in hand with "major" or "critical" severity) or
"feature requests" (i.e. enhancements usually marked as "low").
IMO we shouldn't be shy marking enhancements as high or highest. We
should stop marking them low just because they are enhancements. The
"enhancement" tag is already there to indicate that.
To support this, I suggest to separate "enhancements" from "defects" in
the main page, so that they don't interfere with each other and we are
less reluctant to give them a high priority. The meaning would probably
be: high -> some community members find this important, highest -> there
is a consensus that this is important.
At least this is the workflow I'm used to seeing on Tracker.
As I understood, Scott's (and other developper's) request was indeed to
change this workflow. My point is that you're used to see that because
trac is configured to let people think this way (I know, these are also
habits I took very quickly). The proposal was to accompany Scott's
proposed changes in philosophy with more focus given to the priority on
trac.
ALL other bugs fall into two categories: somewhat important if a devel
is interested in the bug, not important if no one will be bothered to
address it. This is why I find Guillaume's proposal unworkable, if I
understood it correctly, in the sense that: How do we define which
inconvenience is important and which is not?
I do not understand.
The lack of horizontal
scrolling was a major inconvenience for many users for a decade or so,
yet no one looked at it until recently because it required major
surgery; having it in High priority may or may not have been useful...
But if it had been in High priority all this time, then it would have
rendered the priority meaningless, too (same issue as with milestones
above).
This is a good example: IMO it would have deserved to be an enhancement
with priority "highest" (red) as long as necessary. High priority does
not mean that we plan to work on it soon, contrary to the milestone.
I can apply my proposal to the Trac page right now for you to judge, and
we can revert it if you are not convinced.
Guillaume
