> > >>>>> 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
