Re: Form is function

[Scott Kostyshak]

On Thu, Oct 22, 2015 at 12:34:01AM +0100, Guillaume Munch wrote:
> Le 20/10/2015 20:47, Liviu Andronic a écrit :
> >
> >I think #1 is more or less what we have now, slightly simplifying the
> >way we roll milestones (into the .x stack) or drop milestones
> >altogether ("very" old .x reports can be safely decommissioned).
> >#2 will allow to much better keep track of "important" tickets, across
> >major releases, but it will also require some change in bugtracker
> >habits as well as more or less constant supervision (at least at
> >first). It will require from devels a conscious triaging effort to
> >assess importance, but it will allow to not forget important issues or
> >missing features even when they're very old.
> >#3 seems to be like the above while keeping our current color
> >conventions on bugtracker.
> >
> >In truth, I have only but a small voice in this. Best would be for our
> >release managers and active developers to signal which scheme they
> >would be most comfortable with.
> 
> 
> On this we agree and it is the most important point in Liviu's message IMO.
> 
> 
> >And as Pavel has already mentioned,
> >the crucial part for either of Guillaume's proposals---since they
> >involve more departure from what we are currently doing---would be for
> >him to become actively involved in the triaging efforts on Bugtracker
> >for "some" time, so that the new habits stick with the old-timers;
> >otherwise devels will probably simply revert to what they've been used
> >to before.
> >
> >If Guillaume does assume this role, I think either of the proposed
> >schemes could work just nicely, and maybe we really do need a more
> >sensible and nuanced way to prioritize the importance of incoming
> >reports and keep track of them across major releases (as long as it is
> >indeed the devel team that decides on the priorities, not the
> >reporters)... And since Guillaume is clearly motivated, I think a
> >change in bugtracker practices could ultimately prove a positive a
> >change for the team in terms of moving the project forward.
> >
> 
> 
> This partly misunderstands or misrepresents my suggestions, in ways
> already addressed, but let me not explain all again.
> 
> I am motivated to make a one-off change to Trac's front page and advice
> page that would encourage agreed-on conventions by itself. The best
> change is one that reflects current habits, apart from what has been
> requested to change as per Scott's first message.
> 
> I support the rolling back to .X milestones if it corresponds to a
> well-experimented process. Since there also seems to be a consensus
> around the severity field, one can take that into account at the same
> time when improving Trac's emphases. I have something concrete in mind,
> but first let me wait for other people's input and Scott's cleaning of
> the 2.2.0 milestone.
> 
> I nevertheless want to thank Liviu for trying hard at explaining his
> understanding of the current process. While it ought not to be so
> difficult to get a picture of how things work currently,

Thank you both of you for trying to disentangle this not-to-exciting
topic.

> I feel that
> some progress has been made compared to Scott's original proposal.

Agreed.

OK so it still does not appear there is a consensus. I will proceed with
what I said before, basically just focusing on "2.2.0 milestone" or "not
2.2.0 milestone". I will try to make reasonable decisions as to whether
"not 2.2.0 milestone" means "2.3.0 milestone" or "no milestone" or
"2.2.x milestone" depending on the ticket. *please* correct me where you
think something could be improved.

I think this might be one of those things where we have to come up with
what works based on a lot of experimentation.

Scott

Re: Form is function

[Guillaume Munch]

Le 20/10/2015 20:47, Liviu Andronic a écrit :


I think #1 is more or less what we have now, slightly simplifying the
way we roll milestones (into the .x stack) or drop milestones
altogether ("very" old .x reports can be safely decommissioned).
#2 will allow to much better keep track of "important" tickets, across
major releases, but it will also require some change in bugtracker
habits as well as more or less constant supervision (at least at
first). It will require from devels a conscious triaging effort to
assess importance, but it will allow to not forget important issues or
missing features even when they're very old.
#3 seems to be like the above while keeping our current color
conventions on bugtracker.

In truth, I have only but a small voice in this. Best would be for our
release managers and active developers to signal which scheme they
would be most comfortable with.



On this we agree and it is the most important point in Liviu's message IMO.



And as Pavel has already mentioned,
the crucial part for either of Guillaume's proposals---since they
involve more departure from what we are currently doing---would be for
him to become actively involved in the triaging efforts on Bugtracker
for "some" time, so that the new habits stick with the old-timers;
otherwise devels will probably simply revert to what they've been used
to before.

If Guillaume does assume this role, I think either of the proposed
schemes could work just nicely, and maybe we really do need a more
sensible and nuanced way to prioritize the importance of incoming
reports and keep track of them across major releases (as long as it is
indeed the devel team that decides on the priorities, not the
reporters)... And since Guillaume is clearly motivated, I think a
change in bugtracker practices could ultimately prove a positive a
change for the team in terms of moving the project forward.




This partly misunderstands or misrepresents my suggestions, in ways
already addressed, but let me not explain all again.

I am motivated to make a one-off change to Trac's front page and advice
page that would encourage agreed-on conventions by itself. The best
change is one that reflects current habits, apart from what has been
requested to change as per Scott's first message.

I support the rolling back to .X milestones if it corresponds to a
well-experimented process. Since there also seems to be a consensus
around the severity field, one can take that into account at the same
time when improving Trac's emphases. I have something concrete in mind,
but first let me wait for other people's input and Scott's cleaning of
the 2.2.0 milestone.

I nevertheless want to thank Liviu for trying hard at explaining his
understanding of the current process. While it ought not to be so
difficult to get a picture of how things work currently, I feel that
some progress has been made compared to Scott's original proposal.

Guillaume

Re: Form is function

[Scott Kostyshak]

On Wed, Oct 14, 2015 at 07:50:54AM +0100, Guillaume Munch wrote:
> Scott asked not long ago what could be done to make it easier for
> newcomers. It is now clear to me that having a clearer bug tracker
> is an aspect that can be improved. In addition, the initial question
> was to know what to do with tickets with an unmet milestone.
> 
> 
> Taking into account what has been said, here are three proposition:
> 
> 
> 1. Milestones remain the main recipient of triaging information
>   + Unmet milestones are reverted to ".x", which are given more
> visibility.
>   + Severity is the secondary information used to order the lists.
>   + Color is supposed to distinguish enhancements from defects, though
> it is not really observed currently (indeed this colour code was
> kept secret!).
>   - As I see it, it leads to an information which is fragmented between
> three different milestones, which is maybe why it did not work in
> the past.
> 
> 
> or:
> 
> 
> 2. Priority (colour) becomes the main recipient of the triaging
>information.
>+ A list of all "important" defects regardless of milestone is
>  given visbility in addition to what we have already.
>+ "Important" enhancement are shown as well in a list separate from
>  the previous one; the colour do not means the same for
>  enhancements and defects.
>+ An unmet milestone can be removed safely: bump the priority if
>  necessary.
>- While colouring is attractive, it is against pre-existing
>  conventions. The colour code should be similar for defects
>  (yellow/red) but would differ for enhancements (essentially all
>  light blue enhancements would become untriaged).
>- Also, severity was already used to rate tickets on a scale.
> 
> 
> or a new proposition:
> 
> 
> 3. Severity becomes the main recipient of the triaging information.
>   + A list of all important defects regardless of milestone
> (major/critical/blocker) is given the visibility.
>   + A list of all consensual enhancements regardless of milestone is
> found at the end of the front page (e.g. major/critical).
>   + An unmet milestone can be removed safely; bump the severity if
> necessary.
>   + Does not invalidate the color convention which we can explain
> separately, and is consistent with the previous use of severity.
 
>From what I understand there has been no preference expressed by anyone
besides Guillaume on this. Does anyone else prefer one of the three
options (or a different one)? Liviu since you have been involved earlier
in the discussion, can you summarize your opinion with respect to the
propositions Guillaume outlined (or a new proposition) ?

Guillaume (and others), I would like to go through the bugs with
milestone 2.2 soon. My only goal will be to figure out which tickets
should keep 2.2 as a milestone and which should not. I'll make some
decisions about moving some tickets to 2.3 or 2.2.x but I do not plan on
thinking carefully about the severity or importance. I will assume that
anyone who cares about the particular ticket will modify it accordingly.
If someone prefers a different plan, please let me know.

Scott

Re: Form is function

[Liviu Andronic]

On Tue, Oct 20, 2015 at 8:52 PM, Scott Kostyshak  wrote:
> On Wed, Oct 14, 2015 at 07:50:54AM +0100, Guillaume Munch wrote:
>> Scott asked not long ago what could be done to make it easier for
>> newcomers. It is now clear to me that having a clearer bug tracker
>> is an aspect that can be improved. In addition, the initial question
>> was to know what to do with tickets with an unmet milestone.
>>
>>
>> Taking into account what has been said, here are three proposition:
>>
>>
>> 1. Milestones remain the main recipient of triaging information
>>   + Unmet milestones are reverted to ".x", which are given more
>> visibility.
>>   + Severity is the secondary information used to order the lists.
>>   + Color is supposed to distinguish enhancements from defects, though
>> it is not really observed currently (indeed this colour code was
>> kept secret!).
>>   - As I see it, it leads to an information which is fragmented between
>> three different milestones, which is maybe why it did not work in
>> the past.
>>
>>
>> or:
>>
>>
>> 2. Priority (colour) becomes the main recipient of the triaging
>>information.
>>+ A list of all "important" defects regardless of milestone is
>>  given visbility in addition to what we have already.
>>+ "Important" enhancement are shown as well in a list separate from
>>  the previous one; the colour do not means the same for
>>  enhancements and defects.
>>+ An unmet milestone can be removed safely: bump the priority if
>>  necessary.
>>- While colouring is attractive, it is against pre-existing
>>  conventions. The colour code should be similar for defects
>>  (yellow/red) but would differ for enhancements (essentially all
>>  light blue enhancements would become untriaged).
>>- Also, severity was already used to rate tickets on a scale.
>>
>>
>> or a new proposition:
>>
>>
>> 3. Severity becomes the main recipient of the triaging information.
>>   + A list of all important defects regardless of milestone
>> (major/critical/blocker) is given the visibility.
>>   + A list of all consensual enhancements regardless of milestone is
>> found at the end of the front page (e.g. major/critical).
>>   + An unmet milestone can be removed safely; bump the severity if
>> necessary.
>>   + Does not invalidate the color convention which we can explain
>> separately, and is consistent with the previous use of severity.
>
> From what I understand there has been no preference expressed by anyone
> besides Guillaume on this. Does anyone else prefer one of the three
> options (or a different one)? Liviu since you have been involved earlier
> in the discussion, can you summarize your opinion with respect to the
> propositions Guillaume outlined (or a new proposition) ?
>

I think #1 is more or less what we have now, slightly simplifying the
way we roll milestones (into the .x stack) or drop milestones
altogether ("very" old .x reports can be safely decommissioned).
#2 will allow to much better keep track of "important" tickets, across
major releases, but it will also require some change in bugtracker
habits as well as more or less constant supervision (at least at
first). It will require from devels a conscious triaging effort to
assess importance, but it will allow to not forget important issues or
missing features even when they're very old.
#3 seems to be like the above while keeping our current color
conventions on bugtracker.

In truth, I have only but a small voice in this. Best would be for our
release managers and active developers to signal which scheme they
would be most comfortable with. And as Pavel has already mentioned,
the crucial part for either of Guillaume's proposals---since they
involve more departure from what we are currently doing---would be for
him to become actively involved in the triaging efforts on Bugtracker
for "some" time, so that the new habits stick with the old-timers;
otherwise devels will probably simply revert to what they've been used
to before.

If Guillaume does assume this role, I think either of the proposed
schemes could work just nicely, and maybe we really do need a more
sensible and nuanced way to prioritize the importance of incoming
reports and keep track of them across major releases (as long as it is
indeed the devel team that decides on the priorities, not the
reporters)... And since Guillaume is clearly motivated, I think a
change in bugtracker practices could ultimately prove a positive a
change for the team in terms of moving the project forward.

Regards,
Liviu


> Guillaume (and others), I would like to go through the bugs with
> milestone 2.2 soon. My only goal will be to figure out which tickets
> should keep 2.2 as a milestone and which should not. I'll make some
> decisions about moving some tickets to 2.3 or 2.2.x but I do not plan on
> thinking carefully about the severity or importance. I will assume that
> anyone who cares about the 

Re: Form is function

[Jean-Marc Lasgouttes]

Le 15/10/15 00:13, Scott Kostyshak a écrit :

The version of trac we use is almost 5 years old now. There have been a
lot of changes since then. I don't think we should update before a major
release, and I don't even know if we have someone who would have the
time and knowledge to do the update. I just bring this up now in case it
would change any of the proposals that were mentioned as far as bug
triaging so that if we do ever update we don't have to go through
another process of workflow proposals. Does anyone know if the newest
version of trac changes anything significantly as far as the proposals
that Guillaume mentioned?  Here is the change log:
http://trac.edgewall.org/wiki/TracChangeLog


I do not think that there will be significant improvements, but a newer 
trac will come with better security and probably a better choice of plugins.


However, the best way to get that would be to upgrade our centos 
version. I just ran fearlessly "yum update" and we are now at CentOS 
6.7. Everything still seems to work :)


To update further, we would have to upgrade to CentOS 7, which a more 
difficult problem.


JMarc

Re: Form is function

[Guillaume Munch]

Le 14/10/2015 09:38, Liviu Andronic a écrit :

On Wed, Oct 14, 2015 at 7:55 AM, Guillaume Munch  wrote:

the hard truth is that our manpower is limited and our devels barely
  have the bandwidth to address crashes, regressions and the like (in
  between monitoring tickets, triaging, helping on the MLs, and
implementing things sorely needed to keep up with software
developments or just implementing things they need themselves). All
those red color-coded tickets on Trac tend to focus spirits and keep
  devels around the bugs that absolutely need to get fixed until the
next release.



I already did all of what you describe in addition to implementing
long-standing feature requests and last-minute fixes of compilation;
I am not going to take an authoritative argument about what I need.


This was never meant as a rebuke or criticism to any one devel in
particular (or to the team, for the matter), but merely what seems
like a factual description of how our devels operate and their
constraints.



No, of course.


Guillaume

Re: Form is function

[Guillaume Munch]

Le 14/10/2015 07:53, Pavel Sanda a écrit :

Guillaume Munch wrote:

I remember putting the remark about low priority in FAQ.


Here's all I could find about "enhancement" or "priority" on Trac, the
website, the wiki and the repository (with git grep):

?Enhancements have low priority and minor severity by default. We use
'Severity' field to determine urgency of the bugs.?

This is quite different from ?we hijacked the priority field to show
enhancement in light blue?! I am sure it can be improved.


Haha :) Yes, feel free to improve it :)


But I still
haven't got a non-contradictory explanation of what the current system
is, although the picture is a bit clearer now.


I wouldn't expect that the trac usage is consistent in all details,
lyx devel is after all bunch of random people with very different
approaches and without some formal framing.
Often we can't even agree why we are doing it and for whom it should be :)
P



True! :)

Re: Form is function

[Pavel Sanda]

Guillaume Munch wrote:
>> I remember putting the remark about low priority in FAQ.
>
> Here's all I could find about "enhancement" or "priority" on Trac, the
> website, the wiki and the repository (with git grep):
>
> ?Enhancements have low priority and minor severity by default. We use
> 'Severity' field to determine urgency of the bugs.?
>
> This is quite different from ?we hijacked the priority field to show
> enhancement in light blue?! I am sure it can be improved.

Haha :) Yes, feel free to improve it :)

> But I still
> haven't got a non-contradictory explanation of what the current system
> is, although the picture is a bit clearer now. 

I wouldn't expect that the trac usage is consistent in all details,
lyx devel is after all bunch of random people with very different
approaches and without some formal framing.
Often we can't even agree why we are doing it and for whom it should be :)
P

Re: Form is function

[Guillaume Munch]

Scott asked not long ago what could be done to make it easier for
newcomers. It is now clear to me that having a clearer bug tracker
is an aspect that can be improved. In addition, the initial question
was to know what to do with tickets with an unmet milestone.


Taking into account what has been said, here are three proposition:


1. Milestones remain the main recipient of triaging information
  + Unmet milestones are reverted to ".x", which are given more
visibility.
  + Severity is the secondary information used to order the lists.
  + Color is supposed to distinguish enhancements from defects, though
it is not really observed currently (indeed this colour code was
kept secret!).
  - As I see it, it leads to an information which is fragmented between
three different milestones, which is maybe why it did not work in
the past.


or:


2. Priority (colour) becomes the main recipient of the triaging
   information.
   + A list of all "important" defects regardless of milestone is
 given visbility in addition to what we have already.
   + "Important" enhancement are shown as well in a list separate from
 the previous one; the colour do not means the same for
 enhancements and defects.
   + An unmet milestone can be removed safely: bump the priority if
 necessary.
   - While colouring is attractive, it is against pre-existing
 conventions. The colour code should be similar for defects
 (yellow/red) but would differ for enhancements (essentially all
 light blue enhancements would become untriaged).
   - Also, severity was already used to rate tickets on a scale.


or a new proposition:


3. Severity becomes the main recipient of the triaging information.
  + A list of all important defects regardless of milestone
(major/critical/blocker) is given the visibility.
  + A list of all consensual enhancements regardless of milestone is
found at the end of the front page (e.g. major/critical).
  + An unmet milestone can be removed safely; bump the severity if
necessary.
  + Does not invalidate the color convention which we can explain
separately, and is consistent with the previous use of severity.


A few current statistics:

 Defect  Enhancement
Blocker   0  0
Critical 23  0
Major35  1

The list of important enhancement would grow if we redirect unmet
milestones to it.


I think that 3. offers the advantages of 2. while being compatible with
what I now understand of the current secret conventions.

Re: Form is function

[Liviu Andronic]

On Wed, Oct 14, 2015 at 7:55 AM, Guillaume Munch  wrote:
>> the hard truth is that our manpower is limited and our devels barely
>>  have the bandwidth to address crashes, regressions and the like (in
>>  between monitoring tickets, triaging, helping on the MLs, and
>> implementing things sorely needed to keep up with software
>> developments or just implementing things they need themselves). All
>> those red color-coded tickets on Trac tend to focus spirits and keep
>>  devels around the bugs that absolutely need to get fixed until the
>> next release.
>
>
> I already did all of what you describe in addition to implementing
> long-standing feature requests and last-minute fixes of compilation;
> I am not going to take an authoritative argument about what I need.
>
This was never meant as a rebuke or criticism to any one devel in
particular (or to the team, for the matter), but merely what seems
like a factual description of how our devels operate and their
constraints.

Cheers,
Liviu

Re: Form is function

[Scott Kostyshak]

On Wed, Oct 14, 2015 at 07:50:54AM +0100, Guillaume Munch wrote:
> Scott asked not long ago what could be done to make it easier for
> newcomers.

Yes I am interested in this.

> It is now clear to me that having a clearer bug tracker
> is an aspect that can be improved.

Agreed.

> Taking into account what has been said, here are three proposition:

Thanks for writing these up and summarizing the
advantages/disadvantages.

> I think that 3. offers the advantages of 2. while being compatible with
> what I now understand of the current secret conventions.

I don't have a strong preference at this point. Whatever others agree on
is fine with me.

The version of trac we use is almost 5 years old now. There have been a
lot of changes since then. I don't think we should update before a major
release, and I don't even know if we have someone who would have the
time and knowledge to do the update. I just bring this up now in case it
would change any of the proposals that were mentioned as far as bug
triaging so that if we do ever update we don't have to go through
another process of workflow proposals. Does anyone know if the newest
version of trac changes anything significantly as far as the proposals
that Guillaume mentioned?  Here is the change log:
http://trac.edgewall.org/wiki/TracChangeLog

Scott

Re: Form is function

[Guillaume Munch]

TL;DR: thank you for your suggestions and criticisms; new propositions
in a separate message.


Le 13/10/2015 02:20, Scott Kostyshak a écrit :


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.



Yes, thank you for the work.



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.



On this aspect I can see it working well with either system, given that
the relevant list would be added to the front page in any case.



Le 13/10/2015 07:24, Pavel Sanda a écrit :


z.y.x milestone used to mean that it would be nice to have this bug
fixed within z.y stable cycle (e.g. it does not involve fileformat
change, does not need too much refactoring), but it's not happeninng
in z.y.next_stable for whatever reason (during the cycle it usually
starts to be dump for zombies).


Thanks for this explanation, Pavel.


I remember putting the remark about low priority in FAQ.


Here's all I could find about "enhancement" or "priority" on Trac, the
website, the wiki and the repository (with git grep):

“Enhancements have low priority and minor severity by default. We use
'Severity' field to determine urgency of the bugs.”

This is quite different from “we hijacked the priority field to show
enhancement in light blue”! I am sure it can be improved.


There was a time when I was sorting out every and each bug, finding
dupes, contacting people who could be in charge etc. so while the
usage of prio field was not intuitive it was consistent.


Now that I realize all that triaging effort that has been done and not
just to mean that enhancements are by principle of lesser importance, I
am more careful with refocusing the priority field. Of course you are
right that one should not invalidate extant information and ingrained
conventions. And thank you for this past effort.



No matter what system you come up with, people will break it. At the
end what matters is comittment of one or few people continuously
sorting out new entries. So while I do not have strong opinions
about the suggestions or new system you might come up with, my
concern is whether it's you who volunteer to keep trac in that state
for next year or two ;)



I am surely not going to ensure that conventions are enforced neither in
two weeks nor in two years.



Le 13/10/2015 09:10, Liviu Andronic a écrit :

it may be something that works well enough and requires only some
minor tweaks. Maybe we just need to document it explicitly for
incoming devels...


Yes, if it only requires some minor tweaks that's great! But I still
haven't got a non-contradictory explanation of what the current system
is, although the picture is a bit clearer now. And we started with the
concrete question of what to do with unmet milestones that we still have
to address.


While I'm personally always very fond of my pet enhancement requests
(and I'd be all for putting 'em all up in red)


I've had a look at the ~40 tickets I have currently bookmarked and I
have to disagree, it is easy to compare them in terms of cost-benefit
ratio and some tickets do stand out. There's always some part of
subjectiveness, but at some point you have to assume that people are of
good faith.


the hard truth is that our manpower is limited and our devels barely
 have the bandwidth to address crashes, regressions and the like (in
 between monitoring tickets, triaging, helping on the MLs, and
implementing things sorely needed to keep up with software
developments or just implementing things they need themselves). All
those red color-coded tickets on Trac tend to focus spirits and keep
 devels around the bugs that absolutely need to get fixed until the
next release.


I already did all of what you describe in addition to implementing
long-standing feature requests and last-minute fixes of compilation;
I am not going to take an authoritative argument about what I need.


But, thank you for all your efforts at explaining the current
conventions which are still a bit of a mystery to me.


Guillaume

Re: Form is function

[Liviu Andronic]

On Tue, Oct 13, 2015 at 2:46 AM, 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  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
>
At the end of the day Trac is there to assist devels, not users. While
"it has always been like this" is never a good reason to keep
something as it is, if some convention works reasonably well then we
should not try to fix what's not broken. The current system seems to
work well enough for most devels, and allows to keep things useful. I
did my best to try to explain some of the rationale behind what we
have, and why it may be something that works well enough and requires
only some minor tweaks. Maybe we just need to document it explicitly
for incoming devels...

While our current system is somewhat rigid, it is also simple and
intuitive for those who actually need and use it. If we go for
something fancier, we may end up distracting our devels from tickets
that actually matter. While I'm personally always very fond of my pet
enhancement requests (and I'd be all for putting 'em all up in red),
the hard truth is that our manpower is limited and our devels barely
have the bandwidth to address crashes, regressions and the like (in
between monitoring tickets, triaging, helping on the MLs, and
implementing things sorely needed to keep up with software
developments or just implementing things they need themselves). All
those red color-coded tickets on Trac tend to focus spirits and keep
devels around the bugs that absolutely need to get fixed until the
next release. (And god knows our releases advance at glacial speeds.)
If we start putting enhancements and other bugs in red, could this end
up in fewer crashes being fixed in a timely manner?

This however is my opinion, and our devels should choose what works
best for them.

Regards,
Liviu


> 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").
>
> 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.
>
> 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.
>
>
> 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 

Re: Form is function

[Pavel Sanda]

Guillaume Munch wrote:
> 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").

z.y.x milestone used to mean that it would be nice to have this bug fixed
within z.y stable cycle (e.g. it does not involve fileformat change, does
not need too much refactoring), but it's not happeninng in z.y.next_stable
for whatever reason (during the cycle it usually starts to be dump for zombies).

> 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 remember putting the remark about low priority in FAQ. There was a time
when I was sorting out every and each bug, finding dupes, contacting people
who could be in charge etc. so while the usage of prio field was not
intuitive it was consistent.

> 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.

No matter what system you come up with, people will break it. At the end
what matters is comittment of one or few people continuously sorting out
new entries. So while I do not have strong opinions about the suggestions
or new system you might come up with, my concern is whether it's you
who volunteer to keep trac in that state for next year or two ;)

Pavel

Re: Form is function

[Scott Kostyshak]

On Sun, Oct 11, 2015 at 10:28:23PM +0200, Liviu Andronic wrote:
> On Sun, Oct 11, 2015 at 4:27 PM, Guillaume Munch  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.

Scott

Re: Form is function

[Scott Kostyshak]

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  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

Re: Form is function

[Guillaume Munch]

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  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").


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.


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.



Guillaume

Re: Form is function (was: Removing 2.2.0 milestone (as opposed to changing to 2.3.0))

[Liviu Andronic]

On Sun, Oct 11, 2015 at 11:50 AM, Georg Baum
 wrote:
> Liviu Andronic wrote:
>
>> While I understand when people want to remove milestones since "if no
>> one is working on them they're meaningless", I also agree with
>> Guillaume's arguments here: a milestone usually contains some
>> information about the bug, its intended scope and its importance. The
>> mere fact that it has a milestone means it's that bit higher in the
>> priority list, even if no one is actively working on it right now.
>
> Yes, we do currently use milestones like this (and we should transfer this
> information to some other setting), but I don't think that this is how most
> people expect milestones to work.
>
>> My solution would be as follows:
>> All bugs with 2.2.0 or 2.1.4 milestones, which no one is currently
>> working on, should be retargeted to 2.2.x or 2.1.x milestones. This
>> way we do not lose milestone information, and the 2.x.x milestones are
>> not blocking releases nor confusing people as to whether someone is
>> actively working on them. Yet, they conserve the triaging information,
>> which is indeed a collective effort in itself. The 2.x.x are thus
>> simply placeholder milestones (what they always were), not getting
>> into anyone's way but allowing someone to pick up on important stuff,
>> whether they're new on the block or simply a regular devel with more
>> spare time.
>
> We did retargeting to .x milestones for many years already, and it did not
> work (see e.g. #4118). Having a milestone (whether it is a specific one like
> 2.2.0 or a more fuzzy one like 2.2.x) implies that it is planned to fix this
> bug for that milestone. However, this assumption is wrong for many (if not
> most) of our bugs.
>
> IMO it is better (both for developers and users) to be honest about the bugs
> that can be expected to be fixd for a particular release. Your proposal is
> still better than the current situation (where milestones are basically
> useless if one wants to know when a particular bug will be fixed), because
> this uncertainty would be limited to the .x milestones, but I would still
> prefer a solution where even the .x targets are more meaningful.
>
IMO, the only meaningful targets are e.g. 2.2.0 or 2.2.1: when a
major/minor release is performed, those who didn't make the cut but
are still being actively considered are usually rolled to e.g. 2.3.0
or 2.2.2.

The .x targets are more of a stack of "would be nice if someone
bothered to look at them". I would also suggest that we keep the .x
targets for "some" time, but if the ticket hasn't seen any activity
for one or two major releases, then we can safely delete the .x
milestone and let the bug rot in peace. For instance, the 8 year old
http://www.lyx.org/trac/ticket/4118 can be de-milestoned safely...
This way .x targets are indicative of the relative recent nature of
the bug, which is still useful info.


> 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",
and usually hand in hand with "major" or "critical" severity) or
"feature requests" (i.e. enhancements usually marked as "low"). At
least this is the workflow I'm used to seeing on Tracker.

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? 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).


Liviu


>
> Georg
>
>



-- 
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

Re: Form is function (was: Removing 2.2.0 milestone (as opposed to changing to 2.3.0))

[Liviu Andronic]

On Sun, Oct 11, 2015 at 1:27 AM, Guillaume Munch <g...@lyx.org> wrote:
> Le 10/10/2015 22:51, Scott Kostyshak a écrit :
>>
>> I am going to start removing many 2.2.0 milestones if it seems unlikely
>> the bugs will be fixed for 2.2.0 (i.e. no one has said they are working
>> on them). If I remember correctly, there was some discussion on this and
>> most LyX developers prefer this (I think I remember in particular Georg
>> and Vincent) as opposed to changing the milestone to 2.3.0.
>>
>> Before doing this for a lot of tickets, I wanted to give a chance for
>> those to speak up if you disagree and think the milestone should be set
>> to 2.3.0 instead of cleared. The argument for this is that we should not
>> forget about certain bugs and retargetting to 2.3.0 is a way of
>> reminding us to work on them. However, although this makes sense in
>> theory to me, I find that in practice it does not work. In practice the
>> target just becomes overloaded and thus becomes meaningless. If a bug is
>> important to you and you want to remember to work on it in a few months,
>> use a different system (e.g. a personal reminder system or calendar
>> system) instead of the trac milestone.
>>
>> Other opinions?
>>
>
> This new principle means that untargeted bugs are given more importance in
> the end. I had already observed that not setting a milestone for bugs was
> sometimes a way to let a bug get silently forgotten. So this is good.
>
> But as a consequence of this, setting a milestone has been a way of triaging
> bugs and letting others know that some were more important than others. This
> is a tedious task, and we don't want lose bugs that have been triaged as
> important get lost among the 1182 others untargeted bugs. I think that the
> proposal of having a personal way to track bugs is unsufficient because it
> defeats the purpose of a bug tracker, which is supposed to be collective.
>
While I understand when people want to remove milestones since "if no
one is working on them they're meaningless", I also agree with
Guillaume's arguments here: a milestone usually contains some
information about the bug, its intended scope and its importance. The
mere fact that it has a milestone means it's that bit higher in the
priority list, even if no one is actively working on it right now.

My solution would be as follows:
All bugs with 2.2.0 or 2.1.4 milestones, which no one is currently
working on, should be retargeted to 2.2.x or 2.1.x milestones. This
way we do not lose milestone information, and the 2.x.x milestones are
not blocking releases nor confusing people as to whether someone is
actively working on them. Yet, they conserve the triaging information,
which is indeed a collective effort in itself. The 2.x.x are thus
simply placeholder milestones (what they always were), not getting
into anyone's way but allowing someone to pick up on important stuff,
whether they're new on the block or simply a regular devel with more
spare time.

When a major release is ready (e.g. 2.2.0), we can simply move 2.1.x
milestones to 2.2.x and where appropriate 2.2.x milestones to 2.3.x.
If we decide to go this way, I could volunteer to keep this
bookkeeping on our Tracker.

Opinions?

Liviu



> The current situation may have something to do with the fact that it is very
> easy to see targeted bugs, but harder to see ones without a milestone,
> regardless of their priority. (“Form is function”)
>
> Refocusing the purpose of milestones can only work if in exchange we give
> more importance to the priority field. To this purpose, I propose the
> following:
>
> - Add to the front page of Trac the list of all bugs with priority high and
> highest, regardless of their target.
> - Let us be more liberal about the priority, because there are already too
> many bugs of "normal" priority, and we are not really using the distinction
> high/highest enough right now.
> - Instead of retargetting to 2.3.0, you could increase the priority to not
> lose that triaging work.
>
>
> A few statistics:
> Priority highest: 4 (without milestone: 2)
> Priotiry high: 35 (without milestone 16)
> Priority normal: 935 (without milestone 762)
> Total open bugs: 1415 (without milestone 1182)
>
>
> Also, are you also speaking of minor version retargetings (e.g. 2.2.2 ->
> 2.2.3) ? These make more sense to me.
>
>
> 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

Re: Form is function (was: Removing 2.2.0 milestone (as opposed to changing to 2.3.0))

[Georg Baum]

Liviu Andronic wrote:

> While I understand when people want to remove milestones since "if no
> one is working on them they're meaningless", I also agree with
> Guillaume's arguments here: a milestone usually contains some
> information about the bug, its intended scope and its importance. The
> mere fact that it has a milestone means it's that bit higher in the
> priority list, even if no one is actively working on it right now.

Yes, we do currently use milestones like this (and we should transfer this 
information to some other setting), but I don't think that this is how most 
people expect milestones to work.

> My solution would be as follows:
> All bugs with 2.2.0 or 2.1.4 milestones, which no one is currently
> working on, should be retargeted to 2.2.x or 2.1.x milestones. This
> way we do not lose milestone information, and the 2.x.x milestones are
> not blocking releases nor confusing people as to whether someone is
> actively working on them. Yet, they conserve the triaging information,
> which is indeed a collective effort in itself. The 2.x.x are thus
> simply placeholder milestones (what they always were), not getting
> into anyone's way but allowing someone to pick up on important stuff,
> whether they're new on the block or simply a regular devel with more
> spare time.

We did retargeting to .x milestones for many years already, and it did not 
work (see e.g. #4118). Having a milestone (whether it is a specific one like 
2.2.0 or a more fuzzy one like 2.2.x) implies that it is planned to fix this 
bug for that milestone. However, this assumption is wrong for many (if not 
most) of our bugs.

IMO it is better (both for developers and users) to be honest about the bugs 
that can be expected to be fixd for a particular release. Your proposal is 
still better than the current situation (where milestones are basically 
useless if one wants to know when a particular bug will be fixed), because 
this uncertainty would be limited to the .x milestones, but I would still 
prefer a solution where even the .x targets are more meaningful.

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.


Georg

Re: Form is function

[Guillaume Munch]

Le 11/10/2015 15:27, Guillaume Munch a écrit :

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.



...essentially adding at the end of the page:

[[BR]]
== High priority defects ==
[[TicketQuery(order=id,desc=1,format=table,status=reopened|assigned|new|accepted|fixed|fixedinmaster|fixedinstable=highest=defect=summary|severity|status|component|keywords)]]
[[TicketQuery(order=id,desc=1,format=table,status=reopened|assigned|new|accepted|fixed|fixedinmaster|fixedinstable=high=defect=summary|severity|status|component|keywords)]]

[[BR]]
== High priority enhancements ==
[[TicketQuery(order=id,desc=1,format=table,status=reopened|assigned|new|accepted|fixed|fixedinmaster|fixedinstable=highest=enhancement=summary|severity|status|component|keywords)]]
[[TicketQuery(order=id,desc=1,format=table,status=reopened|assigned|new|accepted|fixed|fixedinmaster|fixedinstable=high=enhancement=summary|severity|status|component|keywords)]]

Re: Form is function

[Guillaume Munch]

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

Re: Form is function (was: Removing 2.2.0 milestone (as opposed to changing to 2.3.0))

[Georg Baum]

Liviu Andronic wrote:

> 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? 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).

OK, I understand. Now your proposal makes much more sense to me and is 
probably the best compromise.


Georg

Re: Form is function

[Liviu Andronic]

On Sun, Oct 11, 2015 at 4:27 PM, Guillaume Munch  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 

Re: Form is function

[Pavel Sanda]

Guillaume Munch wrote:
> 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 clarify - the coloring scheme currently used dates back to time when I had
actually time to care about the tracker. Being very color sensitive and
spending lot of time with trac I hijacked the priority field for signalizing
different things, i.e. blue for METAs, cyan for ENHs, yellow for important ones
and red for criticals; the importance itself was indicated by Severity.

I'm not saying this to defend the current state, but to give the perspective;
people who spend their time today to triage the bugs might have better use
for priority field ;)

Pavel

Form is function (was: Removing 2.2.0 milestone (as opposed to changing to 2.3.0))

[Guillaume Munch]

Le 10/10/2015 22:51, Scott Kostyshak a écrit :

I am going to start removing many 2.2.0 milestones if it seems unlikely
the bugs will be fixed for 2.2.0 (i.e. no one has said they are working
on them). If I remember correctly, there was some discussion on this and
most LyX developers prefer this (I think I remember in particular Georg
and Vincent) as opposed to changing the milestone to 2.3.0.

Before doing this for a lot of tickets, I wanted to give a chance for
those to speak up if you disagree and think the milestone should be set
to 2.3.0 instead of cleared. The argument for this is that we should not
forget about certain bugs and retargetting to 2.3.0 is a way of
reminding us to work on them. However, although this makes sense in
theory to me, I find that in practice it does not work. In practice the
target just becomes overloaded and thus becomes meaningless. If a bug is
important to you and you want to remember to work on it in a few months,
use a different system (e.g. a personal reminder system or calendar
system) instead of the trac milestone.

Other opinions?



This new principle means that untargeted bugs are given more importance 
in the end. I had already observed that not setting a milestone for bugs 
was sometimes a way to let a bug get silently forgotten. So this is good.


But as a consequence of this, setting a milestone has been a way of 
triaging bugs and letting others know that some were more important than 
others. This is a tedious task, and we don't want lose bugs that have 
been triaged as important get lost among the 1182 others untargeted 
bugs. I think that the proposal of having a personal way to track bugs 
is unsufficient because it defeats the purpose of a bug tracker, which 
is supposed to be collective.


The current situation may have something to do with the fact that it is 
very easy to see targeted bugs, but harder to see ones without a 
milestone, regardless of their priority. (“Form is function”)


Refocusing the purpose of milestones can only work if in exchange we 
give more importance to the priority field. To this purpose, I propose 
the following:


- Add to the front page of Trac the list of all bugs with priority high 
and highest, regardless of their target.
- Let us be more liberal about the priority, because there are already 
too many bugs of "normal" priority, and we are not really using the 
distinction high/highest enough right now.
- Instead of retargetting to 2.3.0, you could increase the priority to 
not lose that triaging work.



A few statistics:
Priority highest: 4 (without milestone: 2)
Priotiry high: 35 (without milestone 16)
Priority normal: 935 (without milestone 762)
Total open bugs: 1415 (without milestone 1182)


Also, are you also speaking of minor version retargetings (e.g. 2.2.2 -> 
2.2.3) ? These make more sense to me.



Guillaume