[openstack-dev] TC election by the numbers

Zane Bitter zbitter at redhat.com
Mon Nov 10 16:06:43 UTC 2014


On 01/11/14 16:31, Eoghan Glynn wrote:
>
>
>>> +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
> considering.
>
> 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.

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

This is probably not feasible.

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

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

cheers,
Zane.




More information about the OpenStack-dev mailing list