> On Jun 21, 2016, at 2:56 AM, Thierry Carrez <[email protected]> wrote: > > Chris Dent wrote: >> On Mon, 20 Jun 2016, Doug Wiegley wrote: >>> So, it sounds like you’ve just described the job of the TC. And they >>> have so far refused to define OpenStack, leading to a series of >>> derivative decisions that seem … inconsistent over time. >> >> Thanks for writing down what I was thinking. I agree that OpenStack >> needs some architectural vision, direction, leadership, call it what >> you will. Every time I've voted for the _Technical_ Committee that >> leadership is what I've wanted my vote to be creating. > > The TC is a representative body which is elected to make top-down decisions > on OpenStack. However, as much as our community loves the idea of "technical > leadership" and "vision", they hate the top-down decisions that come with it > (especially when that top-down decision doesn't go their way). They prefer > bottom-up consensus. > > So I'd argue that you need both. You need the TC whenever a hard call has to > be made, but in order to minimize the number of those hard calls (and favor > consensus building) you also need working groups to build a bottom-up > reasonable way forward.
This reads very strange to me, as I’d expect a group of technical leaders to both make hard calls *and* to be able to build consensus on overall direction and vision. They’re two sides of the same coin. What is it about our process that means the TC can’t build consensus on direction, but can only impose its will? I expect you didn’t mean it to sound that way, though. Is the workload too high on the bookkeeping to prevent the vision building? Are we too afraid of the implications of defining ‘what is openstack?’, and what it might mean to existing projects and the community? I’d think that in the long-run, it’d prevent seemingly unrelated topics from seeming to go sideways so often, and prevent a lot of these “hard calls”. But, I’m also on the fringe that is very ready to call the “big tent” a failed experiment in attempting to avoid hard calls, too. > >> It may be that an architecture working group can provide some >> guidance that people will find useful. Against the odds I think >> those of us in the API-WG have actually managed to have a positive >> influence. We've not shaken things down to the foundations from >> which a great a glorious future may be born -- a lot of compromises >> have been made and not everybody wants to play along -- but things >> are going in the right direction, for some people, in some projects. >> Maybe a similar thing can happen with architecture. > > That is my hope. I see the API WG and the Architecture WG as groups of > experts in specific domains preparing recommendations and long-term plans. > They don't have authority to force them onto projects. Ideally projects adopt > them because they see them as the right way to do things. > > And for the very few things that the TC deems necessary for OpenStack and > where bottom-up didn't get it in a specific project (if all else fails), the > TC can make a top-down request to a project to do things a certain way. The > project can them either comply or reject the TC oversight and become an > unofficial project. Don’t get me wrong, I welcome this initiative. I find it mildly disconcerting that the folks that I thought we were electing to fill this role will instead be filled by others, but the vacuum does need to be filled, and I thank Clint for stepping up. Thanks, doug > > -- > Thierry Carrez (ttx) > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
