[openstack-dev] TC election by the numbers

Eoghan Glynn eglynn at redhat.com
Sat Nov 1 15:31:58 UTC 2014

> > +1 to this, with a term limit.
> Notable that the Debian TC has been discussing term limits for
> months now, and since DebConf they seem to have gotten much closer
> to a concrete proposal[1] in the last week or so. Could be worth
> watching for ideas on how our community might attempt to implement
> something similar.

That is indeed an interesting approach that the Debian folks are

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

 2. *weaken the continuity guarantee* - by un-staggering the terms,
    so that all seats are contested at each election.

 3. *go all out on proportionality* - by adopting a faction-oriented
    voting model, such as STV with simultaneous terms.

 4. *ensure some minimal turn-over* - by adopting either traditional
    term limits, or the more nuanced approach that Jeremy referenced

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


More information about the OpenStack-dev mailing list