I generally like this approach, but the voting mechanics feel very cumbersome. Is the idea to create a new repo for each vote? Or to reuse the repos but have a few of them for voting on different purposes?
2 Likes
We cannot reuse the repos if the vote is not meant to be public while it happens. After the voting period is over, we publicize the repository as a record of what happened and archive it so no further changes are done to it.
I don’t necessarily agree making people clone a repo to put a file in it is very cumbersome but my sense of ergonomics may be skewed. Do you have a different, less cumbersome, voting procedure in mind?
Agreed.
It may not be necessary to list voting technicalities in the PEP. Perhaps just mention that votes are private until the vote is closed, then get public? We can implement that however we want if the PEP is accepted.
1 Like
PEP content above updated to match 0cf5a7d8cf33ff6633db5162b39c0572ce80d6da
Note y’all: I updated the PEP with @willingc’s and @brettcannon’s edits for clarity that were already committed to python/peps.
“Leave it out, we’ll implement it afterwards”
If I do that, the proposal gets vaguer (and I criticize that in a BDFL model that doesn’t name a BDFL). More importantly, there is a chicken and egg problem there, I think. How are we to decide voting mechanics without voting mechanics?
It’s less attractive on the surface, but more robust, to have a rough agreement on how this is going to run - at least initially (we can and will evolve it!).
Formalize “Working Groups”?
I didn’t want the PEP to be to long, hence the explicit “Omissions”. But now I think you’re right that examples clarify those things a lot. As for fleshing out the “Working Group” concept, that term is not used in the PEP (save for your edit in Abstract). I tried to use familiar terminology in the PEP, hence basing on the “Experts Index”. I think it’s a hit or miss depending who is reading. If you feel like standardizing on “Working Group” is better, we might want to reword to the entire document to use this term in all places that mention “expert teams”, “a group of experts of a given area of interest”, and so on.
Thank you again for your thoughts and edits, Carol.
PEP 8012 conflates PEP process reform with governance model; restricts core development to people with time and money
@ncoghlan left me some useful comments over e-mail that I think are worth broader discussion.
Nick:
I think including PEP process changes in PEP 8012 weakens it significantly - as it stands, I couldn’t vote for it because the votes will be all-or-nothing, and I don’t like the proposed PEP process changes (e.g. PRs are a terrible format for reviewing design proposals), not because I think the governance proposal itself is bad.
Ł:
I see what you’re saying. The problem is that when you don’t have kings and princes, you need the process itself to be stronger. If I just proposed: let’s not have a BDFL nor a council and leave everything else as is, that’s a dangerous proposal.The PEP process currently hides a lot of things that were implicitly handled by Guido. Also, part of why we lost Guido was how unwieldy the PEP discussion was.
Could you enumerate what other changes proposed to the PEP process you find wrong?
As for the “a PR is a terrible format to review”, could you be more specific as to what is wrong with it? And specifically, what better form you have in mind?
Nick:
I don’t think the PEP would lose anything by initially limiting itself to proposals to change PEP 1, as well as to technical PEPs where no BDFL-Delegate can be chosen by consensus, or the chosen delegate chooses to request a formal vote. Any PEP 1 changes beyond that would be deferred to a potential follow-up PEP.
Ł:
I don’t quite follow this suggestion. In PEP 8012 the body responsible for approving the PEP is automatically the expert (or experts team) on the given area of interest. There is no process of choosing the Delegate.And there’s no documented way for the expert team to request a vote. I want to avoid popularity contests and if a given expert body is unsure enough about a change, it should not go in. Do you think this is important to allow? Do you know of any precedent in software that exercises this?
Nick: (in response to the above)
I think I’d completely misunderstood what you were aiming for with your proposal. (What you’re describing sounds a lot like restricting core development only to those folks that are either willing and able to treat it as an unpaid second job, or else are actually being paid for the time they spend on it)Victor’s PEP 8015 is much closer to what I had in mind.
Which brings me to…
Can PEP 8012 and PEP 8015 be merged somehow?
I think the two are the closest in spirit, with the obvious difference of the “Python Board” in place. The Board is very different from the Council concept I’m warning against in “Rejected Ideas Models”. I’m not fundamentally against this limited form of an overseeing body.
There are plenty of kinks to be figured out but what I really care about here is to not kill the community model by fragmentation. We now have PEP 8012, PEP 8014, and PEP 8015. Let’s distill what we agree on in those three PEPs and work from there.
I may misunderstand, but it seems like you are conflating two things:
- How our governance model will be chosen (AFAIU this will be the subject of Raymond’s PEP?)
- How regular decisions will be made once the governance model is in place.
Neither am I 
But that body should be humble and power-limited enough to keep close to the spirit of a Community Model, IMHO. Naming is important, and I don’t think calling it a Board is a good idea (a Board is generally quite powerful).
cc’ing @vstinner
No, not conflating those. What I’m after is this:
- Vote to choose PEP 8012.
- Start running the project according to how it’s described in the PEP, evolve it using the model described in the PEP.
What you’re suggesting by leaving out voting mechanics, leaves us with a weird situation:
- Vote to choose PEP 8012.
- We don’t know how voting in PEP 8012 is supposed to work. We need another PEP. Should there be a temporary working group for it? Should we vote for it?
- Decide on those things before you can…
- Start running the project according to how it’s described in the original PEP + the other PEP. A few people get grumpy: “this is not the model I originally voted for!”
I see. Then, like @dhellmann I will say that it seems cumbersome to have a repo per vote. We might accumulate dead repos in the Python organization. Also, it’s not obvious how you vote in a repo (does each committer add a separate file with their handle? that sounds like the only way to avoid merge conflicts).
I was in discussion with Łukasz last week who proposed me to collaborate on his PEP instead of writing mine. To be honest, I was really short in time since I was travelling/attending Pycon FR, so I decided to write my PEP anyway, and see later how to merge our ideas. I only started to read governance PEPs. The good news is that I see a lot of common ideas between all PEPs, but there are a few differences. Now we have to start discussing these differences to see in which direction we should go. For example, PEP 8011, PEP 8012 and PEP 8015 have many things in common (I didn’t read the other PEPs yet).
Can we use something like Helios for voting like we do for the PSF board?
1 Like
I think we just need to make the intended powers clear, as this terminology clearly has different implications for different people (I think of a council as being more powerful, and an inquisition being primarily inquisitive, but I know those aren’t universally agreed upon either ).
Can we use a Discourse poll and rely on the site to avoid double-voting? You can hide who has voted. (Requiring a larger-than-50% majority seems like an easy way to avoid off by one errors.)
I agree that it’s easy to cast a vote. I just mean that it seems like we will very quickly pile up a bunch of these voting repositories, which is going to make working in the GitHub project a bit of a pain.
There are any number of online voting tools available. Why not just pick one of those to use?
2 Likes
I’ve been reviewing the governance PEPs again, and it seems like this one still has the above question about why we are using Git repos instead of one of the plethora of online voting tools. If this PEP is going to continue to use git repositories as ballots, it should likely at least gain a section on why it’s rejecting Helios/Discourse Polls/Something Else.
Beyond that, this PEP makes some statements about a “BDFL” PEP, but the statements made about that PEP (assuming it’s about PEP 8010) don’t seem to actually reflect the actual state of PEP 8010 (maybe it changed materially since this PEP was written). PEP 8010 doesn’t actually have a Dictator (their powers are limited and there is the ability to recall them if they become malevolent) nor is the position for life (it’s an elected position that lasts for 3 release cycles). This PEP should probably be updated to argue against the actual contents of PEP 8010 instead.
I’m working on updating the PEP right now.
1 Like
I quickly reviewed this proposal again. One question: if a PEP doesn’t clearly relate to an existing (and staffed) expertise area, how is it going to be decided on? As an example amongst many, PEP 572, PEP 443 or PEP 487.
1 Like
Great question @pitrou. As this PEP is inspired by Rust, Django, and C++, I was under the assumption that the Core Team would be responsible for any PEPs or decisions which did not have an expert team to shepherd the PEP. Similar to https://github.com/aturon/rfcs/blob/rust-governance/text/0000-rust-governance.md#core-team
I would wonder if the PEP author may suggest a PEP delegate in that case, perhaps validated through consensus.
1 Like