Thanks Antoine. Personally, I found that useful. There are some points in there that I hadn’t considered, and some others that reinforced the direction I was thinking anyway. My thoughts are roughly as follows (roughly, because I’m still forming my opinion, I have not voted yet).
My biggest concern is the level to which decision making is deferred to the core-devs as a whole. I am concerned about any proposal that makes full core dev votes a routine part of our governance. So I’m overall inclined towards some level of “central authority” style of proposal.
My understanding of what we should be deciding here, is basically how we make decisions about Python, when the usual process of broad consensus and letting core devs decide on the day to day stuff without interference isn’t sufficient. I emphasise that because I’m not at all sure the various proposals address that requirement equally. Some, at least as far as I can tell, seem to be mandating processes outside of that basic remit, and that concerns me.
Taking the PEPs in order, with the above in mind:
PEP 8010 (New BDFL). In principle, I like this. It puts final authority in the hands of a leader, avoiding all of the debates over voting and who’s eligible. The PEP itself doesn’t try to over-specify responsibilities. And it’s a model that’s worked for us for a long time. The big (huge!) problem with it is that it’s utterly dependent on who the leader is. Whether there’s anyone who could take on the role, I don’t know, but as Łukasz said in PEP 8012, “imagine the worst possible person within our team as that BDFL”. I’d like to think we’d never pick someone that bad, but it’s a real concern. And conversely, if I think about who’s in the core devs, there aren’t that many people I’d be comfortable with in the role (and furthermore, I’m not completely sure that everyone would have the same people in mind).
PEP 8011 (Trio). This seems to me to essentially be a way of keeping the basic model of a BDFL but addressing the sustainability and burnout problems. Whether it actually does so, I’m not entirely sure - having a group reduces the stress on one person, but it presents us with the need to find three times as many candidates for the role. I think I’d choose this over 8010.
PEP 8012 (Community). While this has a good analysis of the problem we face, it doesn’t (in my view) state particularly clearly what it proposes as a solution. I feel that there’s a risk of situations coming up that we’re not sure how to address. Also, the voting mechanic seems to require all core devs to participate (while adding a concept of a “dormant” core developer which is something I’m not sure I’m comfortable with).
PEP 8013 (External Governance), I don’t like this because it puts final authority in a group which is specifically not comprised of core developers. I think we should govern ourselves. The proposal has some good ideas, and if it didn’t require the council to be external, I might feel differently, but as it stands I’m against it.
PEP 8014 (Commons). Everything is based on a vote by all the core devs. I don’t like that, I want to keep the number of times the full group has to vote limited. I don’t want to feel responsible for having an informed opinion on every PEP that gets proposed.
PEP 8105. This again involves full core dev votes for all PEPs, It feels to me like the most bureaucratic of all the proposals (which is not a good thing, to me). Also, this seems to me to be the worst offender in terms of “scope creep”.
PEP 8016. This is probably my favourite PEP at the moment. It avoids expecting core devs to vote on a regular basis, and it has an explicit goal to be flexible, and not mandate more than the minimum needed. I particularly like the sentiment encapsulated in “The council should look for ways to use these powers as little as possible”. I’m a little concerned about electing a new council every release (both in terms of the risk of “churn”, and the prospect of having an election campaign every 18 months…) but I’m inclined to hope that in practice people will stay on longer than that, and re-election will be reasonably common.
So that’s my current thinking. Sorry it was a bit long. It may well change, particularly if other people offer their views and that gives me more perspectives to consider.
Don’t worry about correcting any misconceptions there may be in the above - it’s a very broad summary of my feelings, nothing more. And I don’t expect to be swayed by facts anyway (More seriously, I don’t mind corrections, but I won’t ultimately be deciding based on fine details, so overall impressions are more important for me right now).
I completely fail to understand why you would not want the vote to be a popularity contest. It’s not like we’re voting for Miss World (or Mister World, to remain gender neutral), or that there is some grand prize awarded to the author of the winning proposal…
We’re trying to come up with a governance model that will work for the Python community, i.e. mainly for us. (and then I’m generously counting myself in:-) We want a model that is acceptable to the largest fraction of the community, and especially to the people who have invested most in the community and will invest most in the community under the new model. In other words: @guido first and foremost, and the likely candidates for the various roles that the various models have.
The whole idea of anonymous votes for an election like this is ludicrous, in my not-so-humble opinion, and quite possible detrimental (because it may lead everyone to vote for a model where they expect people X, Y and Z to be the new Board of Something but X, Y and Z actually utterly disliking the proposal). But that station has passed, and the vote is going to be anonymous and all that. So be it.
But the idea that we shouldn’t discuss the proposals is ridiculous. I most definitely want to know what Guido votes. And what quite a few other people vote but I won’t start naming them because then undoubtedly I’ll forget to mention some others.
Somewhat off-topic in this thread (because it’s on a single PEP), but I feel I have to answer it here anyway.
These two reactions suggest that I have seriously mis-phrased things in PEP8014.
It is definitely not the intention that everyone vote on everything, it is actually trying to forestall everyone having to vote on everything. The intention of the Council of Elders is that they are people who can extrapolate the vote results for a given proposal from the subset of actual voters to the whole. And 8014 doesn’t even assume infallibility of the Council of Elders: that’s what the tentative period is for, anyone is free to point out that they think the extrapolation isn’t correct.
And it is definitely not intended to be a gerontocracy: the Council of Elders has no inherent power, they are there only to allow the rest of the community the freedom not to vote on everything. The dutch word “corvee” comes to mind: doing the job that everyone knows needs doing because everyone wants them to be done but nobody really wants to do them (doing the dishes, getting the groceries, cleaning the latrines).
One last post for today: I really like the analysis in the Rejected Models, Motivation and Rationale sections of 8012. I think the points made there are rather hard to argue with…
I posted my thoughts a while ago on the mailing list, but over time I’ve been changing. My main criteria is the ability to agree on a resolution to a controversial decision. So I actually like PEP 8013 (my own) and PEP 8014 (which feels like it just chooses one way that mine could play out and requires it be applied in all circumstances) best right now.
Beyond that, PEP 8010 has the nice property of not leaving as much ambiguity as the rest, which either require broad agreement on something fundamentally unagreeable-upon (or it wouldn’t get that far), or simply defers the decision to some unclear time in the future.
And of course, the “no core devs” aspect of mine is different and not part of 8014, so don’t read that into my comparison. But notice how mine doesn’t include any conflict-of-interest resolution text for self-proposals…
For me, Paul pretty much nailed it – I’d be hard-pressed to post a better analysis.
I think we don’t have a BDFL among us (sorry Antoine :-), I don’t want the core developers to have to vote other than to replace the top leadership, and I am concerned about any PEP that tries to nail down the PEP process.
That leaves 8016 (Steering Council) and 8011 (Trio) tied for first place.
I think I did understand your intentions. What I was concerned about was not so much the intention, as the consequences - I would feel a responsibility to participate and vote, regardless of the intention of the proposal.
However, rereading the PEP, I’m surprised you didn’t pick up on this misunderstanding
No it’s not, it’s based on a vote of everyone. Random passers-by can vote, there’s not even a requirement that they use Python! And a PEP can be proposed by anyone. The core devs have basically no special voice at all (other than (1) a majority of all core devs can decide any proposal, or (2) the council essentially arbitrarily deems a vote with an insufficient number of core devs involved as invalid). As someone who reads python-ideas, this scares me. At the very least it makes me feel that I need to be even more active there, to make sure I’m involved in reining in the wilder ideas that appear there…
Yes, I know that’s a pessimistic view. But at the end of the day, it’s just an explanation of why I’ll vote the way I will. It’s not saying that things wouldn’t turn out OK, just that I don’t feel confident enough that they will to vote for this option.
I’m not sure why you think that my PEP 8015 requires core devs to vote on all PEPs. The abstract mentions PEP delegates:
PEPs are approved by a PEP delegate or by a vote (reserved to core developers, need >= 2/3 majority).
Above, I elaborate:
To decide how a PEP is approved (or rejected or deferred), there are two options: (…) PEP delegate (…) a vote (…). A vote is preferred for changes affecting all Python users, like language changes.
My intent is to rely as much as possible on our existing experts, so use PEP delegate on almost all PEPs. On PEPs proposed last years, I would only suggest a vote for a single PEP: PEP 572.
In short, core devs would only elect 1 or 2 new committee member per year, and sometimes (ex: once every 2 years?) vote on one very controversial PEP modifying the Python language.
In my PEP 8015, there is a central authority, but with limited power (that’s a deliberate choice). My intent is to make sure that Python evolution (especially reviewing and approving PEPs) scales horizontally (with the number of core devs).
I expect that the Steering Committee would be asked sometimes to take a decision when no consensus can be found.
I happened to talk to some Django devs about this issue this week, and for Django it sounds like it turned out the way you’re hoping. They actually do elections every 6 months, but it hasn’t been disruptive. Something like 3 out of their 5 current steering council members have served continuously since their council was created in 2014.
I think the point of the elections is to have some regular cadence where we check in with everyone to make sure the core devs are still generally happy with how the council is handling things, and that the council members are generally happy to keep serving. If so, they’re simply reelected and we all carry on. If not, then it’s a chance to make adjustments early, before any problems get out of hand.
Obviously @njs or @dstufft can correct me, but do note there is a very key section of the abstract to PEP 8016 which seems to go against your desire to have less votes by not guaranteeing such an outcome:
The council has broad authority, which they seek to exercise as rarely as possible; instead, they use this power to establish standard processes, like those proposed in the other 801x-series PEPs. This follows the general philosophy that it’s better to split up large changes into a series of small changes that can be reviewed independently: instead of trying to do everything in one PEP, we focus on providing a minimal-but-solid foundation for further governance decisions.
IOW the council of PEP 8016 could choose to make all PEPs be voted on. In the end, PEP 8016 really just says “we’re electing a council to figure out how to run things”. Now they may decide to just act as a 5-person version of PEP 8011/trio, but the council might also decide that everything must be voted on. None of that is specified and the way I read the PEP the council is there to figure out how we should run thing, not to actually decide on PEPs (unless they are governance-related).
Indeed! These two are really the whole point of an anarchist model: there are no strict rules for who gets to vote, and for what that actually means. Direct democracy with a vague constituency. And the Council of Elders is there to pronounce judgement on whether the vote outcome actually makes sense in a given situation.
One of the things that I try to solve with 8014 is that there are valued members of the community who are not core developers: the people who are developers of important projects that interdepend on Python (think of the various frameworks or SciPy or the AI stuff or the other implementations) or who are important to the wider community but don’t develop (teachers, book authors). I am pretty sure that @guido as BDFL considered their needs and opinions, and I think that is something that we shouldn’t lose.
That’s what I like about it. I don’t like fixing a lot of details in the initial governance document – the governance structure should be hard to change, but the way things are generally run should not be (that) hard to change.
Another reason why I don’t like governance PEPs that define how the PEP process should work. I think PEP 8016 solves this issue without opening itself up to attempts to rig the vote by rallying outsiders.
I have several anecdotes that make me wary of such outside pressure.
Long ago the Google App Engine project got to run the question moderation tool for a sort of “Ask Obama Anything”. Within hours, in every category a question related to legalization of marijuana was the top question. We worried our tool was hacked, but a careful analysis showed that we weren’t – stoners were just more internet-savvy than we gave them credit for, and submitted and voted for those questions in disproportionate numbers.
I had a less fun experience a few months ago was when Victor wanted to change some politically charged terminology in CPython. The GitHub PR was given many thumbs-down reactions by racist trolls, who then objected when the PR was merged by pointing out that this was “in spite of massive down-votes”.
I realize that PEP 8014 has mechanisms to deal with this, but I personally would rather not invite outsiders to participate in our elections only to then tell them we aren’t going to count their votes.
That is a very good point, and indeed a weakness in 8014 (and possibly in any anarchist model:-): a large number of outsiders can claim a moral right to influence decisions and it’s not something the insiders can defend against easily.
On the other hand: by not stating what the numerical value of an individual vote is and explicitly stating that votes by some individuals may have more weight than others we build a first line of defence…
Indeed. I hinted at that in my comment about “bureaucratic” proposals. I don’t think we yet know the best way to handle all of the situations that might come up in the future, and IMO we need a governance model that is flexible enough to react to changing circumstances. PEPs that try to be too prescriptive risk leaving us in a position where we don’t have a way forward. Obvious example, the original BDFL model didn’t have the flexibility to deal with the BDFL resigning
True. All proposals are subject to the problem of “what if the decision making process results in an outcome I don’t like?” Some more so than others, but it’s always there. For me, the mitigating factor with PEP 8016 is the tone - it repeatedly argues for light-weight processes, even explicitly making “minimising the need for heavy-weight and anxiety-provoking processes like whole-project votes” a goal in the rationale.
Of course, when formed, the council could end up comprising of a group of people who are all fundamentally opposed to the goals stated in PEP 8016. There’s nothing the PEP can do to prevent that1. But if PEP 8016 is voted in, there’s an implication that a majority of the core devs believe in the goals stated in that PEP2, which reduces the risk of something like that happening (I hope).
1 Apart from defining the process for a no confidence vote, which it does. 2 I don’t want to get sucked into what an option “winning” actually implies under the particular voting rules we’re using. We’ve had enough voting theory discussions for now, IMO
PEP 8012 is a peculiar egg in the basket because of its unique avoidance of a top-level structure. Due to this, it has to focus on how peers are going to make decisions going forward. And this can be achieved by evolving the PEP process here and there. This might be the thing that @guido alludes to when he says he dislikes proposals that focus on the PEP process itself. Well, PEP 8012 doesn’t really have a choice.
Save for the community model, I like PEP 8016 best. Among the good things about it, it composes with PEP 8012 very well. Where PEP 8016 stops, PEP 8012 begins. The spirit of '16 is for the powerful steering council to only exercise their powers rarely. '12 describes a world where no steering council exists to exercise its great powers. That tandem might be the most robust option.
I do hope that if we learn from the election results that '16 wins and '12 is a strong contender, the council will consider this as signal as to what the voters want to see in day-to-day operations.
(More seriously, I don’t mind corrections, but I won’t ultimately be deciding based on fine details, so overall impressions are more important for me right now).
