[openstack-dev] TC election by the numbers
Eoghan Glynn
eglynn at redhat.com
Thu Oct 30 10:22:54 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%
Correction, I skipped a cycle in that table:
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.0%
Grizzly | 630 | 179 (28.4%) | 29.2%
Folsom | 401 | 120 (29.9%) | 27.9%
Doesn't alter the trend though, still quite flat with some jitter and
a small uptick.
Cheers,
Eoghan
> 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