On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt <j...@johngarbutt.com> wrote:
> On 25 September 2014 14:10, Daniel P. Berrange <berra...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev