[openstack-dev] TC election by the numbers

Eoghan Glynn eglynn at redhat.com
Thu Oct 30 13:54:46 UTC 2014


> > If we're serious about improving participation rates, then I think we
> > should consider factors what would tend to drive interest levels and
> > excitement around election time. My own suspicion is that open races
> > where the outcome is in doubt are more likely to garner attention from
> > voters, than contests that feel like a foregone conclusion. That would
> > suggest un-staggering the terms as a first step.
>
> I am curious why you believe the staggering is dramatically changing the
> outcome of the elections.

Well, I don't.

In fact I've already stated the opposite in a prior discussion on TC
election turnout[1].

So I don't think un-staggering the terms would dramatically alter the
outcome, but I do think it would have a better chance of increasing the
voter turnout, than say standardized questionnaires. 

The last few seats would be perceived as being "in play" to a greater
extent IMO, hence increasing both voter interest, and possibly promoting
slightly more balance in the representation.

On the balance aspect, which does concern the outcome, the logic goes
along the lines that the impact of the majority opinion is amplified by
being applied *independently* to each staggered cohort ... e.g. the same
voter can rate both Monty and Thierry, say, as their #1 preference.

In the real world, I believe research suggests a weak correlation between
simultaneous terms and representation of minorities in local government;
some references can be found in [2] if interested, as per usual with
academic research, paywalls abound :(. The applicability of such research
to our scenario is, of course, questionable.

This is one further quirk (bug?) in the design of TC2.0, that may tend to
muddy the waters: the results of original TC2.0 election were used to
determine the term cohorts, as opposed to a random selection.

So the most popular candidates from that race who're still in the running
end in competition with each other every second election, whereas the less
popular remaining candidates contest the alternate elections.  

Switching to simultaneous terms would also remove that quirk (or fix that
bug, depending on your PoV).

Cheers,
Eoghan

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-May/035832.html
[2] http://books.google.ie/books?id=xSibrZC0XSQC

> Because this is a condorcet system, and not a
> weighted one vote one, in a staggered election that would just mean
> that: Thierry, Vish, Jim, Mark, Jay, Michael, and Deva would be in the
> pool as well. Who I'd honestly expect to be ranked really highly (based
> on past election results, and based on their impact across a lot of
> projects).
> 
> If there is some reference you have about why a race for 6 or 7 seats
> with 6 or 7 incumbents is considered less open than a race for 13 seats
> with 13 incumbents, would be great to see. Because to me, neither the
> math nor the psychology seem to support that.
> 
> Note in both elections since we started open elections all incumbents
> that chose to run were re-elected. Which is approximately the same
> results we've seen in PTL elections (with only 1 exception that I know
> of). So that seems consistent with the rest of the community tone. We
> can argue separately whether we should be actively creating more turn
> over across the board, maybe we should be. But the TC doesn't seem
> massively out of line with the rest of the elections we do in the project.
> 
>     -Sean
> 
> >
> > Cheers,
> > Eoghan
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> --
> Sean Dague
> http://dague.net
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list