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