Open Stack

On Fri, 2013-05-31 at 09:08 -0400, Monty Taylor wrote:
> 
> 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.

You mean, you don't like it? Awww ... :)

I wouldn't go so far as to call the above a joke - more of a thought
experiment :)

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

Voting isn't exactly an awesome way of uncovering consensus either ...
but it does gets a decision made. The risk is that you rush to a vote
too early on something and it gets through by a narrow margin even
though you could have built a better consensus.

My point about the mailing list was that TC meetings shouldn't be where
the considered and thoughtful happens ... because a mailing list
discussion gives people a better chance to actually think about things
and listen to each other.

But yes, a real-time, follow-up discussion maybe be required to hammer
out some compromise so a consensus can be hammered out.

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

I agree, it's working very well. Indeed, the title of that talk was
"OpenStack Governance: What it is and why it's working".

As we evolve it, though, I'll always advocate for less bureaucracy
rather than more.

For example, I think some of our current governance probably really
helped when we were still building trust between project leaders and
concerned about corporate control. I think there's a huge amount of
trust around these days, and maybe we should embrace that a bit more.

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

It's the addition of bureaucracy to cope with the growth of the project
that's being discussed here.

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

I don't buy the fudge, frankly :)

How the project leads are chosen does matter or we wouldn't be debating
it. Anyone interested in how our governance works will attempt to
understand it.

Cheers,
Mark.