[python-committers] And Now for Something Completely Different

[Victor Stinner]

2018-07-20 18:32 GMT+02:00 Steven D'Aprano <steve at pearwood.info>:
> What happens when two trusted experts disagree and the voters don't have
> the expertise to tell which one is correct?

In my proposal, if no consensus can be found, the vote fails to reach
the majority, the PEP is rejected.

Usually, people disagree on on specific aspect of a PEP, not on the
overall idea. This is where I propose to separate the decision in two
votes: one vote for the "overall PEP" and one vote to decide between
two variants (paint it blue or green?).


> 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.

Hum, I'm not sure if it's revelant here, but in France, 44 855 000
people vote for the president every 5 years.

If you want numbers, it seems like PHP has around 32 voters on RFC. I
also expect a number around 30 for Python. I'm not talking about the
total number of core developers (who can vote), but the number of core
developers that I expect to vote on a single PEP. I expect that many
cores will abstain from voting because they consider that it's not
their interest area, they didn't have time to follow the discussion or
they are "away from keyboard".


> 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.

My worst example for a vote would be the PEP 446 example that I used
previously. In short, they were 3 people who cared: Charles-François
Natali, Guido van Rossum and me (the author).

First, I would suggest that the authors are not allowed to vote on
their own PEP. For the PEP 446, it means that there were only 2
voters.

I propose to require at least 3 voters on a PEP. For the 50%+1
majority case, it means 2 "+1" votes are enough to approve a PEP on a
total of 3 voters. On sensitive PEPs (the ones with 66%+1 majority), I
propose to require at least 5 voters. If there are not enough voters,
the vote is canceled and a new vote can be attempted later.

I don't think that we will reach this minimum often. If it occurs,
maybe we can extend the vote window and ask people to vote.


> 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.

Wait. I'm against mandatory voting.

First, it's common that people are away from their computer for good
reasons like holidays.

Second, I would strongly suggest core developers to abstain to vote if
they didn't read the PEP (at least) or if they consider that they
don't know enough to be able to have an opinion on a PEP.


> (Perhaps if we have an Abstain option as well as Yes or No.)

I propose to not account "vote: 0" and missing voters to account the majority.

Ballot example:

* Like (+1): 6
* Dislike (-1): 5
* Abstain: 1

If you account Abstain, 50%+1 majority means: (6+5+1)//2+1, at least 7
"like" votes are needed for the majority.

If you ignore Abstain, 50%+1 majority means: (6+5)//2+1, at least 6
"like" votes are needed for the majority.

IMHO 6 to win the vote makes more sense than 7. It becomes even more
obvious if you account all core developers who didn't vote, it would
look more like:

* Like (+1): 6
* Dislike (-1): 5
* Abstain: 60

:-)


> Personally, I'm not sure I'd even want to vote on every PEP that comes
> up. (...)

Me neither :-) As I wrote, I'm already ignoring some topics like
typing and packaging.


> 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.

I propose to make the vote public. I expect that some people who are
not sure about their vote will check who already voted (and what were
their vote) to help them to make a choice.

After talking with friends, I realized that I forgot to explain
something: my proposal doesn't change anything on the long discussion
which occurs *before* the vote. IMHO most tractions occurs during
these discussions, not during the vote. (I'm not sure of the word
"traction": I mean the pressure to pull most people on your side.)

By the way, I propose that the vote window will be "short": just 1 week.

Maybe we should announce the date of the vote 1 week before, to make
sure that people who care about the PEP will be available to vote.

Let me explain why I prefer a short window with a counter example. If
a vote remains open for 1 month, the discussion will likely continue
during the vote, and people who voted early may want to change their
vote. I'm not sure that it's a good thing that people are tempted to
change their vote.

Victor