On Fri, Jul 20, 2018, 17:03 Victor Stinner, <vstin...@redhat.com> wrote:
> 2018-07-20 18:32 GMT+02:00 Steven D'Aprano <st...@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. > But that's for representation, not policy. California is actually a direct democracy through its proposition system. > 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. > Who decides what's a sensitive PEP? -Brett > 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 > _______________________________________________ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ >
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
