Open Stack

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141030/cd7f1a6d/attachment.pgp>