[python-committers] And Now for Something Completely Different
Steven D'Aprano
steve at pearwood.info
Fri Jul 20 12:32:02 EDT 2018
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
More information about the python-committers
mailing list