[openstack-dev] TC election by the numbers

Eoghan Glynn eglynn at redhat.com
Thu Oct 30 10:09:33 UTC 2014



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

Cheers,
Eoghan



More information about the OpenStack-dev mailing list