Open Stack

On 27 September 2014 00:31, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> 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?

What we need to decide is not to use the runway idea for kilo-1 and
kilo-2. At this point, I guess we have (passively) decided that now.

I like the idea of waiting till mid kilo-2. Thats around Spec freeze,
which is handy.

Thanks,
John