Open Stack

On 05/31/2013 08:40 AM, Mark McLoughlin wrote:
> On Tue, 2013-05-28 at 15:29 +0200, Thierry Carrez wrote:
> 
>> https://wiki.openstack.org/wiki/TC_Membership_Models
>>
>> I'd like everyone interested with this discussion to have a look at this
>> page. If you see goals that we missed, please suggest them on the thread
>> here, along with how well each currently-proposed solution would score
>> against it. Same if you think some model was not scored fairly against
>> existing stated goals. Finally, if you have an alternate model which
>> you'd like to suggest, feel free to do so. I'll keep the wiki page
>> updated based on the ML discussion.
> 
> And here's an attempt at a completely different model which I don't
> expect anyone to like, but might spark some ideas:
> 
> "Rough Consensus, Veto Triggers Plebiscite"
> 
> All ATCs are members of the Technical Committee. Technical Committee
> meetings become a forum to bring together people across the project
> interested in specific topics. The detailed discussions happen over the
> mailing list. Project leaders use their influence to help drive
> consensus. Any ATC who feels that a proposal is being forced through and
> doesn't reflect a rough consensus can veto the proposal and trigger an
> immediate plebiscite of members present. If a vote is triggered, the
> proposal requires a two thirds majority to pass. We build a culture of
> empowering people to JFDI with a - hopefully rarely used - safety valve.

I'm going to read that as a joke, because if I do, it's actually quite
funny. I mean, I've watched Debian try to get things done over the
years, and it's a comical expression of exactly how JFDI such a thing
winds up being.

We aren't talking about 20 people here. If we were, sure. We're talking
about over 800. The mailing list is a TERRIBLE way to discover
consensus, and in the history of OpenStack it has never one time worked.
The mailing list is a great way to uncover points of view.

It's all well and good to eye-roll the "ridiculous structure" that we
have and to wave ones hands in the air and laugh at concerns about undue
influence. I'd like to counter that with the fact that we are a project
with 800 developers after 3 years, over 200 companies, and we are
churning out results like a banshee. I think we have thusfar done an
excellent job in not making things too bureaucratic, with the one
exception that we ask people to vote every once in a while.

Fine, let's do an all-direct-elected TC. I don't think it's going to be
that much of a problem. But let's address the actual issue, and not
battle a bureaucracy that simply isn't there and also simply isn't a
problem.

You wanna explain the TC structure under the 6+7 model to newbs? How
about this:

OpenStack is a collection of projects. Each project has a leader that is
elected from the contributors to that that project. Each project leader
has control of his or her project, but occasionally there are topics
where it is advantageous for OpenStack to do things consistently. To
that end, there is a Technical Committee, which is comprised of a set of
the project leads, and a set of at large members.

Done. It took me 2 minutes to explain. It's not even crazy, because I
wasn't going out of my way to make it sound complex. How does the voting
system for that body work? Screw it - that's an advanced topic, and most
people will never care enough to pay attention.

Monty