Open Stack

On Oct 30, 2014, at 10:41 AM, Zane Bitter <zbitter at redhat.com> wrote:

> On 30/10/14 06:22, 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%
>> 
>> 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.
> 
> The low (and dropping) level of turnout is worrying, particularly in light of that analysis showing the proportion of drive-by contributors is relatively static, but it is always going to be hard to discern the motives of people who didn't vote from the single bit of data we have on them.
> 
> There is, however, another metric that we can pull from the actual voting data: the number of candidates actually ranked by each voter:
> 
> Candidates
>  ranked    Frequency
> 
>     0        8   2%
>     1       17   3%
>     2       24   5%
>     3       20   4%
>     4       31   6%
>     5       36   7%
>     6       68  13%
>     7       39   8%
>     8       17   3%
>     9        9   2%
>    10       21   4%
>    11        -   -
>    12      216  43%
> 
> (Note that it isn't possible to rank exactly n-1 candidates.)
> 
> So even amongst the group of people who were engaged enough to vote, fewer than half ranked all of the candidates. A couple of hypotheses spring to mind:
> 
> 1) People don't understand the voting system.
> 
> Under Condorcet, there is no such thing as tactical voting by an individual. So to the extent that these figures might reflect deliberate 'tactical' voting, it means people don't understand Condorcet. The size of the spike at 6 (the number of positions available - the same spike appeared at 7 in the previous election) strongly suggests that lack of understanding of the voting system is at least part of the story. The good news is that this problem is eminently addressable.
> 
> 2) People aren't familiar with the candidates
> 
> This is the one that worries me - it looks a lot like most voters are choosing not to rank many of the candidates because they don't feel they know enough about them to have an opinion. It seems to me that the TC has failed to engage the community enough on the issues of the day to move beyond elections as a simple name-recognition contest. (Kind of like how I imagine it is when you have to vote for your local dog-catcher here in the US. I have to imagine because they don't let me vote.) It gets worse, because the less the TC tries to engage the community on the issues and the less it attempts to actually lead (as opposed to just considering checklists and voting to ask for more time to consider checklists), the more entrenched the current revolving-door membership becomes. So every election serves to reinforce the TC members' perception that everything is going great, and also to reinforce the perception of those whose views are not represented that the TC is an echo chamber from which their views are more or less structurally excluded. That's a much harder problem to address.

Another option:

3) People consider the lower choices on their list to be equivalent. I personally tend to vote in tiers (these 3 are top choices, these 3 are secondary choices, these 6 are third choices) and I don’t differentiate individuals in the bottom tier so it ends up unranked.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141030/19848b7e/attachment.pgp>