[openstack-dev] TC membership evolution, take 2

Mark McLoughlin markmc at redhat.com
Fri May 31 16:02:53 UTC 2013


On Fri, 2013-05-31 at 14:53 +0200, Thierry Carrez wrote:
> Mark McLoughlin wrote:
> > "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.
> 
> Ew. I've been part of such open source communities in the past and you
> always end up spending your time voting on everything. You'd be
> surprised how many people like to be consulted on every question. It
> makes up a very brittle community that is easy to disrupt... Commit
> once, veto and trigger plebiscites on every topic for one year.

That's a risk, for sure. The reason I suggest this (and I'm not trying
to say it's actually a serious proposal) is that I think our community's
reaction to this new world would be that we'd have very, very few votes.

I don't have anything to back that up other than a feeling that our
culture would not entertain people who regularly veto and lose the
resulting vote. Maybe you only get one veto per release cycle :)

> You need leadership in a project to make hard calls and go somewhere. If
> you make sure that leadership is representative of your contributors,
> you end up with a pretty efficient combination.

Absolutely you need leadership. The best leadership (IMHO) builds a
rough consensus, rather than a slim majority in a combative vote.

Indeed, the rough consensus approach is exactly what you're doing in
this thread :)

Cheers,
Mark.






More information about the OpenStack-dev mailing list