On Fri, Jul 20, 2018 at 10:37:03AM -0400, Doug Hellmann wrote:
Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100:
In contrast, I would imagine that people would continue to discuss PEPs in exactly the same way that they currently do, so the result would be that the votes are based more on partially-informed opinion and "gut feeling". Certainly some people will work harder to provide an informed vote, but I doubt that will be true in the majority of cases. Worst case, people will feel a responsibility to vote, but won't have any more time than they do right now so they'll vote with limited information simply because "it's expected of them" to vote.
In other communities that use this form of consensus approval for design changes I have seen folks who do not have time or interest to dig deeply into a proposed change learn to trust others who have the time, interest, and expertise. The team comes out stronger as a result of that built-up trust.
A few questions...
You say folks "learn to trust others", but what does that mean in practice? The only interpretation I can think of is:
People vote for a feature, because Fred says he's in favour
of it and they trust him, or like him personally, or because
he's more charismatic and persuasive than those against it.
What happens when two trusted experts disagree and the voters don't have the expertise to tell which one is correct?
How large are these communities you are referring to?
The sort of participatory democracy Victor and you seem to be talking about doesn't scale beyond small communities where everyone knows everyone else. That's why such participatory democracy worked in ancient Greece, and continues to be used in (eg) Swiss canons, but beyond that communities have moved to a representative democratic model.
Certainly the Python community as a whole is *significantly* bigger than a village. What about the core developers? Now? In the future?
One factor that I don't think Victor has covered is that of what percentage of core devs would have to vote for the result to be accepted -- a quorum, or equivalent.
When it comes to *representative democracy* I believe that the Australian model of mandatory voting (resulting in 90% turnouts or higher) has many advantages over other systems. But for a technical community like this, I don't know that mandatory voting is desirable.
(Perhaps if we have an Abstain option as well as Yes or No.)
So how many non-Abstain votes are needed? Victor mentioned "50% + 1" votes, but does that assume 100% turnout? What if only a handful of people vote on some exceedingly obscure, technical question of no interest to the majority?
Personally, I'm not sure I'd even want to vote on every PEP that comes up. When I was first nominated to the PSF, I took the voting rights as both a privilege and a duty and took them very seriously indeed. But as time went on, I got somewhat disillusioned and burned out (for reasons we need not go into). And that is only voting once or twice a year.
If I had to vote on a dozen or two dozen PEPs a year, most of which I have little or no interest in, the annoyance factor would be correspondingly greater. But if I don't vote, could that doom PEPs to fail because they don't get a quorum?
Another issue we should consider: organised vote swapping. If votes are public, as Victor suggests, that would allow people to do deals: "I'll support your PEP for GOTO, if you support my PEP to deprecate tuples..." sort of thing. There's a reason why most ballots are secret.