On Oct 30, 2014, at 10:41 AM, Zane Bitter <zbit...@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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to