8010 actually, and except for the caveat that I don’t know whether a pronouncement about what is and isn’t Python would actually be legal or not without the involvement of the PSF, I’d say that’s a pretty accurate summary.
I wouldn’t mind approving a PR that added a top level TL;DR section. 
that’s a @tim.one bot <wink> for the modern age.
Incidents should definitely be reported to the Conduct WG. They can also provide advice on potential ramifications for an incident. But as of right now they don’t have explicit power to enforce anything. (Things are still being worked out in terms of whether that should change or stay an advisory role.)
In the PEP 8015, I chose to rely on an external entity, the PSF Conduct Workgroup, rather than on the Steering Committee, to remove the commit bit from core developers. There are multiple reasons for that.
I don’t want to give too many responsibilities to the Steering Committee. IMHO it’s already difficult to handle the few responsibilities that I give to this committee. I would like to make sure the reduce the “burden” on these 5 people. It is going to be challenging to manage the Python project as Guido van Rossum did since 1991. Today, there are millions of Python users, and many haters are awaiting the first decision made in the post-Guido era to complain “that’s a big mistake, Guido would never do that (…)”.
Steering Committee members are core developers as well. Most core devs know them each other, some of them are close friends. I prefer to have an external “neutral” group to handle Code of Conduct to have a fair and objective judgment.
I don’t think that the Steering Committee would be able to handle a CoC incident if it implies a Steering Committee member. Again, I like to have an independent group.
Using the Code of Conduct “against” a core developer to remove their status can be see as “threat” to core developers. There is a risk of “abusing” the CoC to justify to kick someone that we don’t like for whatever reason. Again, I consider here that it’s better to have an external group.
I’m sure that the PSF Conduct Workgroup will think twice before proposing to ban temporarily a core developer, because of the side effect of removing also the status. Maybe no action will be taken rather than a ban because of that. But I trust the Workgroup to remain fair and objective.
cc @ncoghlan
@vstinner I think those are reasonable concerns to raise, I’m just working on the theory that in the PEPs where the council also handles CoC concerns (on the basis of “we elected them, so we’re mutually accountable to each other”), there’s still the PSF Board as an even higher level authority that can be approached if either the CoC working group or another party is unhappy with the way the Council has handled a situation.
The approach you have in PEP 8015 seems viable to me - it’s just not my most preferred approach.
Sorry for the late reply (busy:-) but the intention of 8014 is indeed almost but not quite “everyone votes on everything”. The idea is that is is “everyone can vote on everything but isn’t always expected to do so in reality”.
Pure “everyone votes on everything” has all sorts of issues, such as people not paying attention or not realising the gravity of what they’re voting for. Or, alternatively, if you have compulsory voting, to never get anything done.
The intention of the Council of Elders is to keep EVOE in principle, but making it usable by having the CoE determine whether the given vote of a subset of the voters is deemed to be a good representation of what a vote of “everyone” is likely to be.
Sorry for the slow followup, but the PR is up here: PEP 8010, 8011: Clarify authority of GUIDO and Trio by njsmith · Pull Request #845 · python/peps · GitHub
Now that the elections have started, I have a question. Is it okay to campaign for a particular PEP (or set of PEPs)? Or are we supposed to be quiet until the election is over? The reason I’m asking is that I stopped following this forum due to the high volume, and now I am trying to form my own opinion based on just reading the PEPs. Once I have an opinion I would like to turn it into voting advice, and I don’t know where else I would post that except here or on python-committers.
According to me, open advocacy here during the voting window is not only allowable, but desirable.
There’s certainly no rule against it. There are no rules, unless you decide to make some after all :-).
I think the discussion has died down because we’re past the period where issues can be fixed, and into the period when some people have already voted and can’t change their mind even if they want to. We delayed the vote specifically to give people a chance to read the PEPs and do advocacy before the vote started, so it’s too bad you missed that. But better late than never!
I think it might also reassure people if you said a bit more about how you’re approaching this in general? Until now it seemed like you were signaling that you planned to stay out of the decision entirely, so this feels like a sudden change, and I think we’re all feeling a bit anxious about sudden changes and uncertainty right now.
Why can’t we change our vote? PSF board member votes let you update your vote.
Also, I thought the reason for the delay was that proposals were still being edited actively. There’s a difference between campaigning for a particular proposal to be picked (which requires the choices are fixed) and trying to convince a proposal’s author to change it (which requires the opposite).
I chose not to try and influence the set of choices or the details, but I do have a preference about which proposal I want to win (and no, it’s not another BDFL).
The only thing I’ve been signaling is that I’m close to burn-out, but that I still care. That’s all still true.
The debate about voting systems didn’t interest me, and the discussions about details of each proposal were too high volume, so I stayed out of those, and I’ve only just found the time to read/skim all the proposals.
I sure hope that people don’t feel pressured to vote for the proposal I favor. But I also hope that people actually want to know which one(s) I favor. If most people have already voted, that’s fine too.
In this message I don’t want to state my preference yet, I want to take the time to write up how I feel about each proposal.
The CIVS voting service we’re using flat-out does not support changing votes, period. No way, no how.
Different voting software - Helios. But Helios doesn’t support the kinds of ballots needed for IRV (specified in the original PEP 8001) or Condorcet (current PEP 8001) voting.
Alas, it apparently does now - too late .
As has been advised many times, because people can’t change their votes, they should delay voting at all until they’re sure their decision is final…
Abstractly, I would rather the vote not turn into a popularity contest (where the proposal getting the most approvals from “stars” wins). On the other hand, perhaps my preferred PEP(s) would win in such a contest
One thing that may be useful though is a more relaxed form of opinion such as “I would have a problem contributing if we were adopting this or that model”. In other words, if some people are so critical of one form of governance that adopting may lead them to stop contributing, then it’s a nice piece of information to have. But I’m not sure we’re at that point (also there’s the problem in that the BDFL PEP really depends on who gets elected BDFL… so how do you make an opinion about it?).
For example, there’s one PEP (and only one) that I ranked below “Further discussion” (yes, I already voted).
OK, fine. I will go back to sleep mode. Wake me up when the election’s over. I’m not voting. Good luck.
I hope you reconsider. Nobody in the universe knows more about what guiding Python entails, and nobody else has in fact guided it. Your perspective is uniquely valuable!
This isn’t PEP 572 - the winner will be decided by everyone-is-equal vote, not by decree. People are quite free to vote against Guido’s - or anyone else’s - stated opinions in this context. Do you really believe the outcome is likely to be better if “stars” keep their thoughts private? I want to know what Guido is thinking - and I want to know what everyone else is thinking. That’s the only thing that can put “informed” in “informed decision” for me.
Agreed. I was hoping for more discussion than there’s been so far, so advocacy (and subsequent debate) would be most welcome.
Please do. I know you’ve said you now intend to bow out, but I urge you to reconsider. I was strongly advocating earlier that we needed to get to a point where the proposals were stable, and then have discussions. Not advocacy, or a popularity contest, as Antoine seemed to be wary of, but rather a sharing of opinions, so that as a community we could better understand each other’s reasoning and share expertise and experience. As a very simple example, I would be extremely interested in your personal experience of how the BDFL role is unsustainable, as it would directly affect my view on PEP 8010 (most of my opinions on that proposal being entirely theoretical, for obvious reasons )
As things stand, I’m feeling very much like I have no-one to talk to about this major decision. Most of python-dev seem to be inclined not to participate in this thread, and I don’t know where else any discussion might be appropriate.
As things stand, I’ll probably end up just voting on instinct and hoping I didn’t miss crucial points. But I won’t be very confident in my opinion, and that bothers me.
Me too. In order to “put my money where my mouth is”, I’ll try to post here later tonight with my current thinking.
Ok, since everyone else seems to find it useful, here is my thinking (which also informed my vote, since I already voted).
For me, PEP 8012 (Community), PEP 8015 (Community + Steering Committee) and PEP 8016 (Steering Council + Community) are all reasonable. Some details may turn out a bit wrong, but we will have opportunities to fix them later anyway. Whether one is better than the others is not clear to me.
PEP 8011 (Trio), PEP 8013 (Semi-External Governance) and PEP 8014 (Anarchy + Gerontocracy) have some interesting bits but also oddities that make them a bit risky IMHO. Still they may turn out reasonable to live with.
The only remaining proposal is PEP 8010 (New Monarch). Apart from the fact that I am biaised against monarchies, I have a concrete problem with this proposal: who’s going to be the BDFL very much determines whether I could live or not with the result, and that information is not in the PEP.
In particular, since I know the community, I am guessing that there are two particular persons that may both be willing to candidate (based on their personalities and history in the project) and have a chance to be elected (based on their seniority, “clout”, etc.). Of these two persons:
a) one is good-willed, but I don’t think has the emotional bandwidth and solidity to handle the workload of being a BDFL on such an exposed project; I think electing him would be a missed opportunity.
b) the other is so problematic that him being a BDFL would almost be a casus belli.
(there is a single third person that I think could make a decent BDFL, but is probably too reasonable to accept the responsibility (and actually said he didn’t like PEP 8010))
Thats PEP 8010 
Oops, I’m sorry 
Will fix.