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
