On Sun, Oct 11, 2015 at 4:27 PM, Guillaume Munch <g...@lyx.org> wrote: > 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. > The problem with letting community members define what is important and what is not, is that for each and every one of us our pet bug is the most importantest of 'em all. Until now we had a somewhat rigid system of determining what is of high importance (i.e. crash) and what is not (i.e. enhancement), and this seems to work quite well for our core devels.
> >> 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. > What I mean is that if a bug is not genuinely critical (dataloss, crash, etc.) or genuinely optional (enhancements), there is no easy way to say how "important" it is. Its importance will almost always be defined by whether there is a devel around to actually do it. If so, then it's "important"; otherwise, it's "not important". This is the traditional workflow that we have had on Tracker. However priority usually becomes obvious when (1) there is a definite milestone assigned to the bug or (2) when a devel explicitly takes interest in the bug (e.g. assigns himself to the ticket). This workflow seems to be working quite well for our core devels, but I will admit that it took me some time to understand what was actually going on in Tracker. >> 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. > IMO if a bug has high priority but it doesn't get touched for a decade, then priority becomes as meaningless as rolling milestones for bugs no one is working on. Again, the real difficulty and decider on priority is available manpower and devel interest. Just because a bug has a milestone or is set to be of "high priority" doesn't make it so; but if a bug is a crash or a programmer is actively working on it, then it implicitly has "high priority". Overall the consensus seems to be that we want milestones and priority and severity labels that actually mean what they say... Liviu > > 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 > -- Do you think you know what math is? http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02 Or what it means to be intelligent? http://www.ideasroadshow.com/issues/john-duncan-2013-08-30 Think again: http://www.ideasroadshow.com/library
