I believe this is some kind of wishful thinking. In reality, if it weren’t for the language and its ecosystem (libraries, etc.), few people probably would stay “just for the community”.
Several core developers and prominent community members stopped being active along the way (such as Georg Brandl, Martin von Lôwis…). Apparently having a nice community wasn’t enough when their interest in language development dwindled.
“Staying for the community” is mostly an attractive slogan, one that helps people believe they are part of some special group.
Why would I have to become a member of every organization whose decisions affect my life? That’s completely unworkable. At the end I have to accept some degree of division of labour.
As for “the community”, I would point out that 1) there isn’t a single Python community, but a bunch of domain-specific communities 2) you can be a member (even a prominent one) of those communities without being a member of the PSF.
+1 for should rather than must. I’m a PSF voting member so it doesn’t affect me, but I can imagine that this extra requirement might discourage someone from running on the trio, if they have a problem with becoming a PSF member. (I won’t speculate on what problems people might have with that, but it could be as simple as not wanting to join any group which would have you as a member - w/apologies to Groucho Marx).
This proposal mostly fixes my gripes that I’ve expressed with PEP 8010 and I especially like that the trio isn’t supposed to be the top three voted people but that they are voted for as whole.
However OTOH I fail to envision how the election process is supposed to look practically? Even with say 5 candidates, there’s a lot of permutations to be had. And more importantly: what if I only care about candidate X and Y being part of the trio and don’t care about the third one? This might look like minutiae but the disheartening amount of discussion on voting mechanics on the rather straightforward-looking PEP 8000 makes me rather nervous about leaving this part vague.
@hynek I think that the trio would run as a slate. Therefore, folks would vote on the slate as an entity. Individuals could be part of more than one proposed slate.
What are the open issues for this PEP? Based on its current state the best I can tell is:
How the trio will be elected (the PEP says “Once this PEP is accepted and core devs have submitted their nominations, each active eligible core devs can vote for one group of three.”, but that’s seems a bit vague)
Term length for a trio
What if one member of the trio wants to stop?
The PEP also lists the disbandment of the trio and the formation of working groups, but what’s there saying “we can re-evaluate and potentially just re-run the trio elections” seems fine to me and I don’t think the PEP needs to be strict on WG formation.
Electing the trio
I say just choose whatever voting system we go with in PEP 8001 but without requiring a full ranking of candidates (if that even makes sense with the final voting system that’s chosen).
Term lengths/limits
In terms of Python timelines:
A feature release is 18 months
Releases live for 5 years
A major release is about 10 years
Now I personally have been involved with python-dev for over 16 years and a core dev for 15, so saying something like 10 years doesn’t phase me, but it might for others. Considering we currently ask release managers to hold that position for 5 years and that seems to have worked out I say we stick with that. That will see the trio through 3 releases which is enough to see a feature developed, made provisional, and then made stable (or developed, released and regretted, and then deprecated ).
What is one member wants to stop?
I think if someone wants to retire early then a new election needs to be held. The trio were elected as a slate and so the loss of one breaks that unit that was elected. I know that puts that one member who wants to leave early in an awkward position, but I would hope any elected slate would get along well enough that the reasons for stepping down would be understood and know ill will would held.
Would you mind to also describe how a trio member can leave immediately for personal reasons? Nobody expects an accident, a family member becoming sick, burnout, etc. I would prefer to see a process for that.
In my PEP 8015, I wrote “If a board member steps down, a new vote is organized to replaced them. If the situation of a board member changes in a way that no longer satisfies the board constraint (eg: they move to the same company as another board members), they have to resign.” … But votes of this PEP are organized using slates of 3 people which is different.
Looking over PEP 8011, similarly to PEP 8010, I see that this PEP defers defining how voting is handled to whatever mechanism is selected in PEP 8001. However, PEP 8001 does not use a secret ballot, but instead has a public ballot. While one can arguably suggest that voting on proposals not people, people are less likely to feel compelled to vote for their friends (regardless fo their true positions) because their friends are able to see how they’re voting. It seems like voting to elect the trio should almost certainly be done using some mechanism that ensures a secret ballot so that people feel free to vote their true preferences, without worrying about hurting people’s feelings.
It says that succession planning is open for discussion, but this should really be nailed down before this proposal is voted on. Ideally I think this should likely be another election of a new set of three developers, and similarly to 8010, changes to the governance model should go through the process outlined in 8010. While we may elect to tie changing the governance model to the cycle of a particular trio, we also may elect to change it mid cycle and both should probably be acceptable.
In addition to succession planning, it does not seem to state how long the trio itself serves for. Is this considered a “for life” position or is it for a set term? This should be spelled out explicitly in the PEP.
The other thing I think that is missing here, is the question of how do we handle the case where the trio is not acting in the best interests of Python? In PEP 8010 I suggested allowing any core developer to motion for a vote of no confidence, and if that is seconded by another developer, trigger a vote to determine if the trio should be recalled and a new trio elected. I believe that there is little likelihood of core developers trying to recall the trio out of “fun” or spite (particularly when it requires two developers to actually trigger one) so this seems like a reasonable way to bake in some level of protection, without an undo amount of extra process.
I’m concerned that there does not appear to be a mechanism by which the trio can resolve disputes internally if there isn’t a consensus on some issue. Is it implied that they’d effectively just vote amongst themselves and if two of them agree, they can overrule the third? What if all three have different ideas? Does that essentially mean the status quo wins in that case?
Maybe this is a case for an Approval vote and in the case of a tie a re-vote under Plurality for the tie? And in the event of yet another tie we go to random selection administered by the PSF president? IOW how the PSF board is elected, but with a single slate winner instead of voting for the top 3 individuals.
I guess not, but I assumed if we did Approval we would use Helios and thus it would be private. So in my brain it was a foregone conclusion it would be private if Mariatta chose to change the voting to Approval.
I’m actually not very picky about what voting method to use here Your reasoning for private voting makes sense, and I’m fine with private voting for the election of the trio. Would anyone here be able to create the PR for it? Thanks.
).
Yes, it’s sufficient!
So in my brain it was a foregone conclusion it would be private if Mariatta chose to change the voting to Approval.
Your reasoning for private voting makes sense, and I’m fine with private voting for the election of the trio. Would anyone here be able to create the PR for it? Thanks.