[openstack-dev] TC election by the numbers
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 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
More information about the OpenStack-dev