Open Stack

On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt <john at johngarbutt.com> wrote:

> On 25 September 2014 14:10, Daniel P. Berrange <berrange at redhat.com>
> wrote:
> >> The proposal is to keep kilo-1, kilo-2 much the same as juno. Except,
> >> we work harder on getting people to buy into the priorities that are
> >> set, and actively provoke more debate on their "correctness", and we
> >> reduce the bar for what needs a blueprint.
> >>
> >> We can't have 50 high priority blueprints, it doesn't mean anything,
> >> right? We need to trim the list down to a manageable number, based on
> >> the agreed project priorities. Thats all I mean by slots / runway at
> >> this point.
> >
> > I would suggest we don't try to rank high/medium/low as that is
> > too coarse, but rather just an ordered priority list. Then you
> > would not be in the situation of having 50 high blueprints. We
> > would instead naturally just start at the highest priority and
> > work downwards.
>
> OK. I guess I was fixating about fitting things into launchpad.
>
> I guess having both might be what happens.
>
> >> > The runways
> >> > idea is just going to make me less efficient at reviewing. So I'm
> >> > very much against it as an idea.
> >>
> >> This proposal is different to the runways idea, although it certainly
> >> borrows aspects of it. I just don't understand how this proposal has
> >> all the same issues?
> >>
> >>
> >> The key to the kilo-3 proposal, is about getting better at saying no,
> >> this blueprint isn't very likely to make kilo.
> >>
> >> If we focus on a smaller number of blueprints to review, we should be
> >> able to get a greater percentage of those fully completed.
> >>
> >> I am just using slots/runway-like ideas to help pick the high priority
> >> blueprints we should concentrate on, during that final milestone.
> >> Rather than keeping the distraction of 15 or so low priority
> >> blueprints, with those poor submitters jamming up the check queue, and
> >> constantly rebasing, and having to deal with the odd stray review
> >> comment they might get lucky enough to get.
> >>
> >> Maybe you think this bit is overkill, and thats fine. But I still
> >> think we need a way to stop wasting so much of peoples time on things
> >> that will not make it.
> >
> > The high priority blueprints are going to end up being mostly the big
> > scope changes which take alot of time to review & probably go through
> > many iterations. The low priority blueprints are going to end up being
> > the small things that don't consume significant resource to review and
> > are easy to deal with in the time we're waiting for the big items to
> > go through rebases or whatever. So what I don't like about the runways
> > slots idea is that removes the ability to be agile and take the
> initiative
> > to review & approve the low priority stuff that would otherwise never
> > make it through.
>
> The idea is more around concentrating on the *same* list of things.
>
> Certainly we need to avoid the priority inversion of concentrating
> only on the big things.
>
> Its also why I suggested that for kilo-1 and kilo-2, we allow any
> blueprint to merge, and only restrict it to a specific list in kilo-3,
> the idea being to maximise the number of things that get completed,
> rather than merging some half blueprints, but not getting to the good
> bits.
>
>
Do we have to decide this now, or can we see how project priorities go and
reevaluate half way through Kilo-2?


>
> Anyways, it seems like this doesn't hit a middle ground that would
> gain pre-summit approval. Or at least needs some online chat time to
> work out something.
>
>
> Thanks,
> John
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140926/67f8ac10/attachment.html>