Open Stack

On 04/08/2016 02:01 PM, Tim Bell wrote:
>
> On 08/04/16 20:08, "gordon chung" <gord at live.ca> wrote:
>
>>
>>
>> On 08/04/2016 9:14 AM, Thierry Carrez wrote:
>>> Eoghan Glynn wrote:
>>>>> However, the turnout continues to slide, dipping below 20% for
>>>>> the first time:
>>>>
>>>>     Election | Electorate (delta %) | Votes | Turnout (delta %)
>>>>     ===========================================================
>>>>     Oct '13  | 1106                 | 342   | 30.92
>>>>     Apr '14  | 1510    (+36.52)  | 448   | 29.69   (-4.05)
>>>>     Oct '14  | 1893       (+25.35)  | 506   | 26.73   (-9.91)
>>>>     Apr '15  | 2169       (+14.58)  | 548   | 25.27   (-5.48)
>>>>     Oct '15  | 2759       (+27.20)  | 619   | 22.44   (-11.20)
>>>>     Apr '16  | 3284       (+19.03)  | 652   | 19.85   (-11.51)
>>>>
>>>>>
>>>>> This ongoing trend of a decreasing proportion of the electorate
>>>>> participating in TC elections is a concern.
>>>
>>> One way to look at it is that every cycle (mostly due to the habit of
>>> giving summit passes to recent contributors) we have more and more
>>> one-patch contributors (more than 600 in Mitaka), and those usually are
>>> not really interested in voting... So the electorate number is a bit
>>> inflated, resulting in an apparent drop in turnout.
>>>
>>> It would be interesting to run the same analysis but taking only >=3
>>> patch contributors as "expected voters" and see if the turnout still
>>> drops as much.
>>>
>>> Long term I'd like to remove the summit pass perk (or no longer link it
>>> to "one commit"). It will likely result in a drop in contributors
>>> numbers (gasp), but a saner electorate.
>>>
>>
>> just for reference, while only affecting a subset of the electorate, if
>> you look at the PTL elections, they all had over 40% turnout (even the
>> older and larger projects).
>>
>> it may be because of those with "one commit", but if that were the case,
>> you would think the turnout would be inline/similar to the PTL elections.
>
> It could also be that the projects with the lower hanging fruit were uncontested.
>
> BTW, I don’t feel that a 1 commit person should be ignored in the voting. Many of us
> have roles which do not mean we spend all the time committing but when we see something
> wrong in the docs, spend a few hours to go through the process. I certainly favor
> those PTLs/TC members in my voting who still count the sum of this contribution to be significant.
>
> As we progress further with the UC-Recognition activity, there will be further discussion
> on this so I feel waiting for that work to make a proposal on how those people could also
> contribute to setting the technical direction.

I think the two thoughts are not mutually exclusive. The existence of a 
commit was an easy thing to track early on. I think it's problematic 
both in being too lax a guide for who is involved as the one commit 
issue shows, and also too strict - as the UC/Operator problem shows.

Ultimately the question isn't "how many commits is the right number" but 
"how do we recognize our electorate as close as we can as being the set 
of people who are actually involved and interested and part of the 
community". I'm pretty sure all systems we will devise to describe such 
a set of people will be deficient in some way, but I think purely one 
commit can be improved on from many directions.

Monty