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. 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
