[openstack-dev] TC election by the numbers

Eoghan Glynn eglynn at redhat.com
Mon Nov 10 17:09:54 UTC 2014

> > So, just to round out this thread, the key questions are:
> >
> >   * whether a low & declining turnout is a real problem
> >
> > and, if so:
> >
> >   * could this have been driven by a weakness in the voting model,
> >     and/or the perception of representative balance in the outcomes
> >
> > The options that were mooted on the thread could be ranked in order
> > of how radical they are, and how likely to have an impact:
> >
> >   0. *do nothing* - accept low turnout as a fact of life, or hope that
> >      natural factors such as a slowdown in contributor growth will
> >      eventually cause it to stabilize.
> >
> >   1. *make a minor concession to proportionality* - while keeping the
> >      focus on consensus, e.g. by adopting the proportional Condorcet
> >      variant.
> It would be interesting to see the analysis again, but in the past this 
> proved to not make much difference.


For the first TC2.0 election IIRC it only changed the destination of the
last seat.

> >   2. *weaken the continuity guarantee* - by un-staggering the terms,
> >      so that all seats are contested at each election.
> This is probably not feasible.

Interesting, why do you think it wouldn't be feasible?

(Given that in the first TC2.0 election, 11 of 13 seats were contested,
 with 2 just seats held back for term completion, and short-terms allocated
 to 5 of the 11 winners - so seemed to me we could revert to simultaneous
 terms after just one cycle of transition) 

> >   3. *go all out on proportionality* - by adopting a faction-oriented
> >      voting model, such as STV with simultaneous terms.
> I actually like Condorcet (to be clear, I meant that any possible 
> problems with Condorcet are addressable with better education, not by 
> changing the system). I don't think STV would be a good move.

Fair enough. STV is likely to give rise to different outcomes to Condorcet,
so at least worth doing the thought-experiment as to how that might impact
on the functioning and perception of the TC.

> >   4. *ensure some minimal turn-over* - by adopting either traditional
> >      term limits, or the more nuanced approach that Jeremy referenced
> >      up-thread.
> >
> > If it came down to it, my money would be on #2 or #3 for the reasons
> > stated before. With the added bonus that this would allow TC elections
> > to be viewed more as a plebiscite on some major issue (such as the
> > layering discussions).
> I think you missed the most important option I mentioned in the thread - 
> for the TC to engage more with the community and take an active 
> technical leadership role in the design of OpenStack as a whole.

Fair point, I should have qualified that I was summarizing mooted changes
to the electoral system itself, as opposed to how the TC leads, engages
with the community etc.

The "growth challenges" session at summit was the most prominent example
of that IMO.


More information about the OpenStack-dev mailing list