[python-committers] And Now for Something Completely Different

[Doug Hellmann]

Excerpts from Steven D'Aprano's message of 2018-07-21 02:32:02 +1000:
> 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?

The same sort of thing that happens with PEPs. Either the proposal
itself is changed to support more compromise, or it is abandoned and the
status quo prevails.

> How large are these communities you are referring to?

OpenStack had 2000 contributors during 2017. Of those, I would
estimate that on the order of a few hundred are considered core
reviewers in some way and would have a formal vote in our specification
process, although the group reviewing any given specification would
be somewhat closer to the size of the python core developer team
size.

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

It is certainly harder to implement as the size of the group grows. I
don't think this group has hit the point where it is impossible to
sustain, though.

> Certainly the Python community as a whole is *significantly* bigger 
> than a village. What about the core developers? Now? In the future?

I'm not sure the entire Python community is really the relevant
size to consider. Another important aspect of open source governance
to keep in mind is that decisions need to be made by the folks doing
the work.  That's one reason the existing PEP delegate process works
so well today -- the person making that final decision is invested
in not just the decision but the overall area where the work is
happening. We already trust them to both know what they are doing
technically and guide the decision making process to consensus.

I find it interesting that the arguments in favor of a single BDFL
tend to assume that the person selected will be responsible and
informed enough to make good decisions, and the argument against a
more democratic approach seems to be that the community would not
be. Where in that latter assumption is the leadership of the person
we would be giving the BDFL title to? Why are they unable to
communicate, inform, and lead a democratically organized community
to achieve goals for the common good? And if they can't, why are
they qualified to be a dictator?

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

Yes, this is a good point. I'm not sure a 1-size-fits-all approach
necessarily works, but some way of deciding how to know when consensus
is reached would be an important aspect of choosing a democratic
approach.

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

One approach some of our teams take is to have a subset of the core
reviewers serve as reviewers for specifications. This reduces the
number of people needed for quorum, explicitly asks those people
to commit to doing the reviews, and still supports a democratic
decision making process. Combining that approach with the PEP
delegation system already in use, we could designate a team for
making decisions on individual PEPs. Core developers could volunteer
or be drafted, and we could include knowledgeable and interested
contributors who are not core, in some cases (PyPA comes to mind).

> 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 don't know anyone currently on the core team who would engage in
that sort of behavior, or who would put up with it if discovered
in any current or future members.  Within the OpenStack community
we have *much* higher pressure from companies to add features
supporting their products (supporting hardware, use cases, odd-ball
customer configurations, etc.) than I have ever seen in any discussion
related to Python itself. An open, democratic, approach *exposes*
these sorts of issues, and lets us deal with them directly.

Doug