[openstack-dev] [all][elections] Results of the TC Election
eglynn at redhat.com
Fri Apr 8 21:21:46 UTC 2016
> >> 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.
I'd be -1 on removing this "perk" ... I prefer to think of it as
something that contributors "earn" by their efforts.
OTOH I'd be fine with moving the goalposts somewhat to require more
than a single commit. Increasing that to 3 or 5 commits would likely
still result in some contributors dividing that single patch into a
series of 3, but for others might not be worth the effort.
Another approach to consider would be to continue to offer the ATC
pass for a single commit, but to require a little more participation
in order to vote in TC/PTL elections (modulo Foundation bye-laws etc.)
More information about the OpenStack-dev