[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