[openstack-dev] TC election by the numbers

Steven Hardy shardy at redhat.com
Thu Oct 30 14:14:12 UTC 2014


On Thu, Oct 30, 2014 at 08:11:59AM -0400, Sean Dague wrote:
> On 10/30/2014 06:09 AM, Eoghan Glynn wrote:
> >
> >>>>>>> IIRC, there is no method for removing foundation members. So there
> >>>>>>> are likely a number of people listed who have moved on to other
> >>>>>>> activities and are no longer involved with OpenStack. I'd actually
> >>>>>>> be quite interested to see the turnout numbers with voters who
> >>>>>>> missed the last two elections prior to this one filtered out.
> >>>>>> Well, the base electorate for the TC are active contributors with
> >>>>>> patches landed to official projects within the past year, so these
> >>>>>> are devs getting their code merged but not interested in voting.
> >>>>>> This is somewhat different from (though potentially related to) the
> >>>>>> "dead weight" foundation membership on the rolls for board
> >>>>>> elections.
> >>>>>>
> >>>>>> Also, foundation members who have not voted in two board elections
> >>>>>> are being removed from the membership now, from what I understand
> >>>>>> (we just needed to get to the point where we had two years worth of
> >>>>>> board elections in the first place).
> >>>>> Thanks, I lost my mind here and confused the board with the TC.
> >>>>>
> >>>>> So then my next question is, of those who did not vote, how many are
> >>>>> from under-represented companies? A higher percentage there might point
> >>>>> to disenfranchisement.
> >>>> Different but related question (might be hard to calculate though):
> >>>>
> >>>> If we remove people who have only ever landed one patch from the
> >>>> electorate, what do the turnout numbers look like? 2? 5?
> >>>>
> >>>> Do we have the ability to dig in slightly and find a natural definition
> >>>> or characterization amongst our currently voting electorate that might
> >>>> help us understand who the people are who do vote and what it is about
> >>>> those people who might be or feel different or more enfranchised? I've
> >>>> personally been thinking that the one-patch rule is, while tractable,
> >>>> potentially strange for turnout - especially when one-patch also gets
> >>>> you a free summit pass... but I have no data to say what actually
> >>>> defined "active" in active technical contributor.
> >>> Again, the ballots are anonymized so we've no way of doing that analysis.
> >>>
> >>> The best we could IIUC would be to analyze the electoral roll, bucketizing
> >>> by number of patches landed, to see if there's a significant long-tail of
> >>> potential voters with very few patches.
> >> Just looking at stackalytices numbers for Juno: Out of 1556 committers,
> >> 1071 have committed more than one patch and 485 only a single patch.
> >> That's a third!
> > Here's the trend over the past four cycles, with a moving average in the
> > last column, as the eligible voters are derived from the preceding two
> > cycles:
> >
> >  Release | Committers | Single-patch | 2-cycle MA
> >  ------------------------------------------------
> >  Juno    | 1556       | 485 (31.2%)  | 29.8%
> >  Icehouse| 1273       | 362 (28.4%)  | 28.0%
> >  Havana  | 1005       | 278 (27.6%)  | 28.8%
> >  Folsom  | 401        | 120 (29.9%)  | 27.9%
> >
> > So the proportion of single-patch committers is creeping up slowly, but
> > not at a rate that would account for the decline in voter turnout.
> >
> > And since we've no way of knowing if voting patterns among the single-patch
> > committers differs in any way from the norm, these data don't tell us much.
> >
> > 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. 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.

Well, FWIW, I think we should be, and I'd posit that the lack of turnover
probably is one of the reasons for voter apathy.

I'd hypothesise that smaller and/or newer projects probably do contain
voters who feel disenfranchised, based on the historically predictable
re-election of the incumbents.

No criticism of those incumbents intended, I'm just pointing out that it
may be hard for some folks to remain positive about a process if they feel
that their interests are persistently under-represented (one disadvantage
or the all-directly-elected vs PTLs+elected model I guess).

Steve



More information about the OpenStack-dev mailing list