On Tue, Oct 20, 2015 at 8:52 PM, Scott Kostyshak <skost...@lyx.org> 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 particular ticket will modify it accordingly.
> If someone prefers a different plan, please let me know.
>
> Scott
--
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
