It is interesting. Isn’t there a saying about how most problems in computer science can be solved with another layer of abstraction? Seems applicable in this case.
This idea prevents the PSF from getting too involved in specific details about how funds get spent on CPython work. The workgroup would be in charge of details of making sure funds go to the right place and producing reports back to the PSF. It could relieve the people doing the CPython work from the management duties. A challenge is that you have to find people willing to be on workgroup and do the management stuff.
The board used to be re-elected every year, but they relatively recently changed the bylaws to move to a staggered term where only some portion of the board is elected each year. They did this to provide continuity year over year so there was less disruption in the board’s normal activities.
I’m not particularly worried about a board of 5, but I’m also not against a higher number.
My main concern with a higher number would be if we chose say 9, that’s a decent number of people, how likely are it that we’re going to get meaningful choice in an election (E.g. we’d need at least 10 people to volunteer to be on the board for any given release).
If we go with a larger number, then it may be wise to increase the length of the term to something like 5 years and then do a staggered election cycle. The idea being that it’s easier to get 3-5 people to volunteer for one of 2 positions, than it is to get 10-15 people to volunteer for one of 9 positions.
This will likely adjust the election procedure a bit, since there is no outgoing board (just a few outgoing members). Presumably we’d adjust it to just be nominated by the council at large or something.
I don’t think this would require a change in the PSFs bylaws. I think it’s effectively just stating that there cannot be a CPython working group, and that if CPython itself wants funds to be handled than isntead of a work group it is up to the council to go and request the grant from the PSF and then handle spending those funds. IOW, the council is essentially part workgroup.
While we trust council members to act in the best interests of Python rather than themselves or their employers, the mere appearance of any one company dominating Python development could itself be harmful and erode trust. In order to avoid any appearance of conflict of interest, at most 2 members of the council can work for any single employer.
Barry brought this up somewhere else, but I think it’s a good point. Barry works for Linkedin, which is a distinct entity but is owned by Microsoft, which Brett works at. Does this mean that Barry and Brett cannot both serve on the board together? IOW, does the “single employer” ban extend to owned subsidiaries or only actually the same employer?
I feel like actually the same employer is all that’s needed and we don’t need to traverse the entire hierarchy. The goal here isn’t so much to prevent one company from gaining too much power and nefariously taking over CPython (I don’t think that’s likely, and if one does then we have the power to recall a council member). But rather I think the idea is that we want a diverse range of experiences, and two people from the some company are likely going to be hitting the same problems, whereas splitting them out into different companies increases the likelihood that the experiences/problems that person has in their head immediately are different.
Yea. Particularly we’re using
firstname.lastname@example.org for PyPI as well, so there are PyPI developers on that list who are not CPython developers. There may be other people who are not core developers on that list as well.
5 or 7 seem best. I agree with you that 9 is too large initially. If it’s 5, what is the quorum (3, 4, or 5) to have a meaningful decision?
I agree with you that a subsidiary can be viewed as a different employer (LinkedIn and Microsoft).
As for money exchange and bylaws amendment, I believe that it depends how the handling of money would occur. I could see the PSF earmarking a lump sum each year for CPython where the specific decision making on the funds, as allowed by 501c3, is based on the core team’s views. This could be a group as suggested in this PEP a) acting as a workgroup, b) having fiscal sponsorship with the PSF, or c) requesting funds as needed to be voted on by the PSF board. I think a) and b) would lend for smoother operations.
The management of the workgroup and reports back to the workgroup are not too time consuming. For other workgroups, we provide a 1-2 paragraph monthly report (which can be “no updates at this time”). After the workgroup agrees to funding (for example, the science workgroup) a project, the PSF handles the fiscal management from that point on.
- Vote on promoting a contributor and on PEPs now requires >= 2/3 rather than 50%+1.
- Vote on changing this PEP now requires >= 4/5 rather than 50%+1.
- (Also: Specify the Condorcet method: use Schulze/Beatpath/CSSD variant to elect Python Steering Committee members. Specify how to deal with tie and the constraint on the employers.)
I now agree that 50%+1 was too weak to justify a change/promotion. It’s hard to deal with half of core developers who disagree with a change/promotion.
Sorry, I didn’t mean to undersell the PSF here :-). The thing I’m gesturing vaguely at is… well, there’s this weird disjunction: legally, the PSF and its board are the final arbitrars of what Python is, since they hold the trademark. But traditionally, the PSF board and the Python core devs have acted as two independent groups that mostly don’t even talk to each other, and the PSF just kind of implicitly assumes that whatever it is the core devs are doing to the language is probably fine.
This wasn’t really a problem so long as both groups deferred to Guido whenever any questions arose, but going forward it would be good to get everyone on the same page. If there’s a CPython workgroup, then presumably it wants to spend the funds on things that the CPython project decides are worthwhile, which means it somehow needs to interact with the CPython project’s governance. Or for another example, consider the fork of CPython called “python 2.8” – is it Python? Can it use the trademark? The decision was “no”, basically because Guido said so. In the future, if the PSF needs a ruling on questions like “will there ever be an official python 2.8?”, then our new governance mechanism will need to somehow generate that ruling, and communicate it to the PSF.
How exactly that will look, I’m not sure! Your suggestions downthread make sense to me, but figuring out the details will take some work. My goal in the draft was just to be clear that the council has the mandate and authority to have those conversations and get something figured out. Maybe it could be clearer…
I don’t think it’s going to be a big issue, given that the candidates are all being drawn from the pool of existing Python core team members? And since they have to win an election, I assume they’ll mostly be pretty active contributors who know what’s happening in the project, already have working relationships with the other council members, and that people will often end up being re-elected for multiple terms anyway.
We could switch to staggered terms if people prefer the other way… I don’t have a strong opinion. I just figured this was probably fine and I’m trying to keep things simple :-).
Not sure where you’re getting this? In the current text, the only ways a council member can be forced to step down are either through a successful recall, or if they disappear and stop responding to messages.
That would also work, but I figured that organizing big project-wide votes is a hassle and we’d prefer to avoid it when possible. (And we’d rather people step down if they’re having trouble than hold on because they don’t want to cause a hassle.) I’m guessing that in most cases it will be like when someone volunteers to act as a BDFL-delegate – someone diffidently volunteers to take it on, and everyone else is like “oh yay now I don’t have to volunteer”. If it turns into some big controversial thing, then the council can always decide to hold a vote…
Yeah, I’ll clarify the text.
Oh interesting! I just copied that bit from Django, I can adjust.
I guess the traditional OSS thing is to elect new committers via “general acclaim”, i.e. you wait until it’s pretty obvious to everyone that someone’s ready, and the four-fifths stuff I copied from Django follows that. But now that I think about it, I’m not a huge fan of the super-conservative thing either, and Donald was suggesting using 2/3 as a supermajority threshold earlier too, so sure, let’s switch it.
Again I don’t care that much – does anyone else have an opinion? I feel like if there’s something that’s so uncontroversial that 4/5 of the core team will vote for it, then it’s unlikely that 3/5 of the council will be against it. And even if it that does happen, then the council can always be recalled, or just wait for the next election and then elect council members who aren’t so obstructive. OTOH, I can’t think of any situation where the veto would be useful either, and leaving it out would simplify things a bit…
Oh uh, that’s what Django calls it and I was sloppy with cut-and-paste :-). Thanks, I’ll fix it.
I think this is less of a problem here than it would be for something like the PSF board. For the steering council, there’s no requirement to meet regularly, votes should be rare, it’s fine if a vote is spread out over a week or two, members can abstain and still count towards quorum if its an issue where they don’t feel like they can form a meaningful opinion, and if someone doesn’t have the time to participate anymore then it’s pretty easy for them to step down and get a replacement. Also, like Donald points out, our total universe of potential candidates is only like 20-30 people (estimated from only 25 people responding to the voting systems poll), so 9 on the board would be quite a lot :-).
But really the reason I’m a bit reluctant to change this is that if quorum != council size, then it raises other issues, like should the conflict-of-interest rule be based on the size of the quorum or the size of the council? And I’d kind of like to not have to think about that kind of thing if I can avoid it :-). How worried are you about this?
Oh, that’s interesting… I would have said that obviously LinkedIn and Microsoft are the same company. (Though note that in the current draft, you can have 2 people from the same company on the council, so Barry and Brett can definitely both serve at the same time – it’s just that if they do, then maybe Steve and Eric would have to wait for the next term.)
As a practical question: is there any simple and unambiguous way to tell the difference between a separately-branded subdivision (e.g. Xbox) vs. a subsidiary (e.g. LinkedIn)? Do we have to go read SEC filings or something?
I think the benefit of a conflict-of-interest rule like this is partly to diversify the council, sure, but also there are a lot of people out there who are genuinely nervous about that possibility of a big company taking over Python development. (And let’s be honest, it’s not like these big companies haven’t done dubious things in the past.) And conversations about this are terrible, all innuendo and vague conspiracies and other distracting nonsense that isn’t good for Python or for the companies involved – so it’s better to just avoid the whole issue entirely. This generally argues for making sure the rules don’t encourage hair-splitting…
I like this idea very much. I have tried to do a similar thing with 8014: get a minimal governance model in place and trust in the common sense and goodwill of most people involved most of the time. (but 8014 is different than 8016 as presented here in that 8014 explicitly tries to codify as few things as possible, while 8016 seems to codify things in a simple way).
I’m looking forward to seeing the PEP!
I’m honestly surprised PEP 8013 didn’t get more of a mention, which perhaps mean I didn’t at all make clear in it that it’s spiritually identical to this except for the pool of candidates being outside the core development team, and a whole lot of non-binding details (that is, not the “spiritual” parts).
Do the authors of 8016 think there are major differences? If the pool of potential candidates were allowed to include current core developers (and we came up with some conflict-of-interest wording, which seems likely anyway) would it make more sense to combine them?
And by “combine”, I mean withdrawing mine and allowing anyone to self-nominate for election in 8016. I really don’t care that much about the details, and if people who do care about the details want to work on it I have no problem. Everything else here seems good to me.
I feel like a major difference is that PEP 8013 doesn’t allow the CoA to delegate their authority, and the intent appears to be that the CoA is making decisions themselves on PEPs with regularity. Sort of one of the core ideas of PEP 8016 is that while final decision does ultimately rest within this steering committee, that they have the freedom to effectively implement some other PEP without involving a heavyweight process. This could allow us to say, give direct democracy a try on a PEP or two and see how it works out, and give them the power to tweak how that process works over time without involving a full vote of the entire electorate. It is of course possible that they ultimately decide the best model is to have decision making stay within that steering committee, but that there is an easier way to experiment and ultimately implement changes to the process.
One example I like to think of, is that originally there was no concept of a long standing delegation like myself and Paul Moore (originally Nick Coghlan) have for PyPI and the packaging interoperability PEPs. However because Guido more or less had complete authority to experiment and tweak the PEP process, we were able to try that out and it ended up working out quite well (and if ti hadn’t, Guido had the power to revoke that delegation). Giving the steering committee flexibility to implement our processes however they see fit, means that it’s far easier to adjust to the changing needs of the Python community. Of course the steering committee does have a decent amount of power, so we do limit their ability to effect how the committee itself is chosen or serves by encoding that in the PEP and requiring a full vote for that.
With regards to whether we can allow non-committers to be a part of the steering committee or not. I don’t personally care? I’m not opposed to allowing anyone to serve on the committee and leaving it up to the core developers who are voting to decide if they are OK with a specific person who isn’t a core developer being on the steering committee or not. I suspect though that if someone is not a core developer and they get elected to the steering committee, that feels like a really strong signal that that person should probably already be a core developer anyways.
That’s true, but if the CoA says “we’ll be happy if X is happy” and there’s one final post to python-committers with the final text and a reply saying “yes”, I don’t see how it is functionally different? It also allows the CoA to withdraw the delegation if they choose, rather than it being an irreversible transfer of power. (And all of this works out because the model allows the council to choose on a case-by-case basis how to evaluate each PEP. The model provides some suggestions, but no requirements.)
Perhaps, but there are plenty of people who have an interest in Python’s direction but no willingness to merge random PRs. I don’t see any value in conflating the two roles.
It may just be a case of optimization. By explicitly disallowing delegation, it feels to me like the intent isn’t that the CoA can (or at least should) do a psuedo delegation by saying “whatever this person says is what we’ll pick”, which would seem to me like explicitly going against the intent of the PEP, which I think would make the CoA less likely to actually do that, whereas PEP 8016 explicitly enables that so the hope is that people will feel more like it’s allowed.
That being said, if you don’t actually have a problem with delegation (either to a person, or to another process) then you’re right that a lot of the differences start shrinking to how set in stone the actual process is (PEP 8013 outlines a specific process PEPS have to go through, PEP 8016 allows the steering council to make that choice) and who is eligible to serve as part of that committee.
I’d be interested in @njs view on it, but I don’t personally have a problem making anyone eligible. I trust the core developers who would be voting on the candidates to select responsible candidates who will make reasonable decisions regardless of whether those candidates are members of the core team or not.
As a practical point, if the majority of the core developers feel like being a core developer should be a part of the mandatory qualification, then it doesn’t really matter whether we allow non core developers to be a part of the steering committee or not, because they’d never actually win. However, being flexible does allow exceptions to that even if that’s the general “rule” that happens in practice.
Maybe I just have a more lax view of what it means (or should mean) to be a core developer That is maybe a larger discussion not really relevant to the governance discussions, but I feel like the commit bit is possibly the least interesting part of being a core developer (and that may be bias because I use mine so very rarely) and it’s more a recognition that we trust some person’s decision making for the good of Python and that they’ve put in some significant effort in improving Python. If someone is regularly working on PEPs and end up being involved as part of the CoA/steering committee, that feels like a strong signal we trust them and should make them part of the team, regardless of if they want to push the merge button on PRs or not.
The part where only core devs are eligible for the steering council is one of the bits we copied from Django; I’m not especially attached to it.
I agree with Donald though that anyone who could win a vote like this is probably qualified to be a core dev :-). If you look at the draft text about the “core team”, then you’ll see that another thing we copied from Django is language about how people can qualify for the core team via non-code contributions. (And this is not actually new really… I barely had any code in git when I became a core dev.)
I want to reread 8013 before saying more detailed about the relation… I had the impression there were more spiritual differences than that, but if that’s wrong and we can merge proposals then that’d be great.
I’ve updated the draft text to finish up the missing bits and incorporate the feedback from this thread. In particular:
- Switched to a 2/3 supermajority threshold everywhere, and clarified that this is a >= check
- Fixed the stray references to Django’s technical board and removed the reference to only core team members being allowed to review security reports (thanks @vstinner)
- Dropped the council veto on constitutional amendments, so now it’s just a supermajority vote of the core team
The biggest change since the last draft is that I added in a mechanism to remove someone from the core team if we really have to. The proposal is that it requires a 2/3 supermajority of the steering council (so 4:1 in normal circumstances, like @dstufft suggested above), and is also special in that it can’t be delegated, and can’t be used when a vote-of-no-confidence is in process. I’m not particularly wedded to the details here; I think it should be possible but can be nearly arbitrarily difficult since it should only be used in really egregious cases.
@steve.dower For now I left in the requirement that council members also be core team members, just because I wanted to get a draft done and that discussion seems unfinished. We should finish it
@Mariatta: I know you feel strongly about having some language around diversity in the governance PEP, and I really liked the language around this in PEP 8011. I ended up not copying it directly in this draft because I wasn’t sure how to fit it into the flow, but I did try to add some similar language, specifically in the section on the steering council’s mandate and electing the steering council. If you have a chance to look at it, I’d definitely value your thoughts on this part (and anything else too, of course).
Happy to. What are your thoughts? So far it seems I’m strongly in favour (but I have my own proposal), and your coauthor is okay with it on the basis that election to the steering council would imply probable election as a core developer anyway (and on this point I’d suggest that allowing non-core developers to nominate would avoid a – purely hypothetical! – rush of people to become core developers first in order to try and join the council).
I wonder if it’d make sense to move this discussion into Committers now that it’s more than an idea?
Anyways, I’ve merged PEP 8016. One thing I noticed regarding the Emeritus status, is we don’t specify how exactly you become not emeritus. I assume just stating you want to be non-emeritus and then you get everything back.
@njs Can you please create a new thread on the Committers category with the full text of your PEP, so I can comment it there?
My feeling is similar to @dstufft’s, that it’s unlikely to make much difference whether we limit the council to only core members or not, so I don’t have a strong feeling either way. If you’re saying that this one change would be enough to let us drop PEP 8013 from the list and shrink the field a bit, then that seems like a good reason for making the change to me :-). But I don’t want to pressure you either.
I just re-read PEP 8013, and it struck me as both similar and dissimilar. Both 8013 and 8016 follow the general philosophy of people-over-process, where the defined process is mostly about choosing people, and then letting them apply their judgement. In 8013, the focus is very much on deciding about PEPs, and there’s no mechanism for resolving disputes about non-PEP-worthy topics or about whether a topic is PEP-worthy, for allocation of project assets, for disputes about whether someone is ready to become a core dev, etc. In 8016 OTOH the council has a much broader mandate to deal with any disputes that arise. And of course 8013 paints a compelling picture of how neutral external auditors can be used for ruling on PEPs. In 8016, the vision is more that the council will define processes like this, so instead of acting themselves as external auditors, they would delegate to external auditors if that seems like a good idea (and this decision could be made on a tentative or PEP-by-PEP basis, they could tweak details like how the external auditors are chosen as needed, etc., versus 8013 which makes some specific choices there and doesn’t currently provide any mechanism for changing them at all AFAICT). But, since they both emphasize people-over-process, there aren’t really processes in place to force things to play out that way: 8016’s council decided to themselves act as external auditors, then there’s nothing in the document to stop them.
So I guess the reason you’re suggesting that we allow 8016 steering council members to be non-core-team-members is that it makes it more plausible that we could then use the 8016 steering council itself as a “council of auditors”. And the reason Donald and I are shrugging is not that we don’t like the idea of external auditors, but rather that as far as we’re concerned, 8016 is already totally compatible with the external auditor approach, regardless of whether the steering council allows external members. Does that sound right?