On Tue, Oct 13, 2015 at 01:46:26AM +0100, Guillaume Munch wrote: > Le 13/10/2015 00:53, Scott Kostyshak a écrit : > >On Sun, Oct 11, 2015 at 10:28:23PM +0200, Liviu Andronic wrote: > >>On Sun, Oct 11, 2015 at 4:27 PM, Guillaume Munch <g...@lyx.org> wrote: > >>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. > > > >Thank you for all of the discussion on this topic. My priority will be > >changing tickets that have the 2.2.0 miletone to either remove the > >milestone or change it to 2.2.x or 2.2.1. Please feel free to change the > >priority or severity and of course to disagree with a decision I make > >regarding the milestone and anything else. > > > > > My point again: whatever field we use to denote the triaging information, > the tracker should be set up to direct users towards this usage. I would > have been reassured to see people trying to address this side of the issue > as well. Let us think about this now. First, please, explain to me what the > milestones ".x" are supposed to mean exactly and I can suggest an > appropriate change to the tracker page (which may or may not be just "add .x > milestones to the front page").
My personal preferences is to not have the 2.x or as you say to clearly define what they mean. I just want to get started on the process of moving tickets off of the 2.2 milestone. Whether I move these tickets to 2.2.x or just clear the milestone, I don't have a preference but others do. I am planning to move the tickets for which no work has been done in a long time to have no milestone, and tickets to 2.2.x for which recent work has been done and it seems there might be some intention of working on the bug for a 2.2.x release. If we do decide to get rid of the 2.2.x milestone, it is easy to do, rather than if we change our mind from getting rid of it to keeping it. > In addition, the exchange showed the confusion about the purpose of the > priority field: Liviu says that it is a "rigid system" to determine what is > of importance or not, and that we want "priority labels that mean what they > say", while Pavel reveals that it was just "hijacked" to set up a colour > code. In any case this code was kept well secret and does not always > correspond to what I observe in practice on trac. I agree, we do need to make a decision on this and write it down somewhere and respect it. > If you do not like my suggestion to "hijack" the color field again for > something more intuitive, maybe we can still think about the place we give > to enhancements, because the current system wrongly gives the impression > that they are less important (in particular are considered on the same scale > as defects to begin with). Liviu's objections regarding a long-standing > "red" enhancement comes in my opinion from a misunderstanding of my proposal > which I recognise stemming from this way Trac currently makes us think: > indeed, if enhancements were shown separately from defects (through various > settings of trac: front page, default columns...), how could a long-standing > red enhancement diminish the value of red defects? Liviu's example > ironically shows the need for a way to show that there is a consensus around > a very desirable feature, however difficult (in a way easier to sort and > keep up to date than the wiki). > > I still think that refocusing the priority field would be more useful than > .x milestones, in particular because they do not need to be rolled over to > the next milestone every year. But my point applies to whatever system is > chosen. I agree with you. Although what Liviu says about people maybe saying "hmmm maybe I'll take a look in the 2.2.x milestone to find something to work on" would be nice, I don't see that happening. Scott
