[python-committers] And Now for Something Completely Different

[Steven D'Aprano]

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.



-- 
Steve