Currently, https://peps.python.org/pep-0013/#vote-of-no-confidence does not have any deadline for seconding a call for a vote of no confidence. It’s fairly obvious that doing so an year later wouldn’t make sense since a new council would have been elected by then.
IMO it would be a good idea to have an explicitly set “deadline” for seconding a call for a vote of no confidence – two weeks would be consistent with the voting periods for various other matters in PEP 13 today. Concretely, the text change would look something like (new content in bold italics):
A no-confidence vote is triggered when a core team member calls for one publicly on an appropriate project communication channel, and another core team member seconds the proposal within two weeks.
Based on https://peps.python.org/pep-0013/#changing-this-document, this is a detail that can be changed via a 2/3 vote of the core team. This does seem like a process gap that’s worth addressing at some point – IMO this isn’t worth an out-of-cycle vote but would be fine as an additional item to vote on during the next SC election.
I noticed this discrepancy too, and appreciate you bringing this up! I know that @malemburg has generally proposed changes around the SC and CoC enforcement, and I’ve been thinking along those lines as well.
Several of us have also been thinking about the resiliency of the SC. E.g. if all 5 members are recalled, resign[1], or replaced, I think we would have some serious[2] continuation problems. The PSF Board has a rotating election cycle of 3 cohorts[3], which ensures continuity between terms. The SC’s terms have always been tied to Python releases, which was retained when PEP 602 switched to an annual cycle. We may want to consider some adjustments to this policy.
I’m not necessarily saying we should have one single big change to PEP 13, but it may make sense to batch some of these changes together, conducting a discussion and opening a vote on each item at the same time.
PEP 13 has served us incredibly well over the years. As the SC’s “constitution” it’s a pretty great document[4], but it’s not unreasonable to consider some tweaks.
This reminds me of the Twenty-seventh Amendment to the United States Constitution - Wikipedia, which was proposed in 1789 and ratified in 1992, more than 200 years later. Regardless of the merits of the change itself, I don’t think that’s a good process and I’d support your proposed change to add a 2-week deadline to no-confidence votes.
I support a deadline of two weeks, and also suggest a deadline of one week.
Any vote of no confidence will introduce uncertainty to the Python project until the vote falls or a new council/member is elected.
The steering council election has nomination and voting phases. PEP 13 says “each phase lasts one to two weeks, at the outgoing council’s discretion”. To date, each phase has been two weeks, plus about week or two between phases for admin such as compiling the voter roll and so on. An outgoing council may select shorter phases to bring stability sooner, but it could be up to four weeks.
First call
Deadline until seconded
Two week vote of no confidence
One to two week SC nominations
One to two week SC election
If the deadline is two weeks, the minimum time of uncertainty would be between 6 and 8 weeks, plus admin.
This is a long time, around 15% of a regular SC term, during which I imagine a council may be unwilling to make big decisions.
Therefore I suggest the seconding time is one week to help bring stability sooner. This would make the whole process a minimum of between 5 and 7 weeks, plus admin.
In addition to the SC election phases being potentially one week long, PEP 13 also defines the core team vote as one week.
Note that whatever deadline is chosen, if a seconder does not come forward in that period, nothing stops the original caller from issuing a fresh call as soon as the deadline expires.
While two weeks is reasonable, I think one week (7 days) would be sufficient. Since we’re talking about a call to second, a brief governance timeframe is all that is needed (there is either significant support or not).
I know that @malemburg has generally proposed changes around the SC and CoC enforcement, and I’ve been thinking along those lines as well.
Let’s ensure transparency and inclusion when drafting wording for any proposed SC/CoC changes.
I appreciate the toll that the current practice has on SC members. I want us to keep focus that the toll is also felt by many, especially the handful of women on the core team.
Several of us have also been thinking about the resiliency of the SC.
It’s good governance to revisit this every 5 years or so. In the SC’s brief history, there has been turnover each term. Five members is a fairly small board, so staggering and extending terms to two years would likely have minimal impact on continuity. A great deal of continuity exists with current SC meeting practices/onboarding, developers in residence, and workgroups.
For whatever my opinion is worth, a deadline seems like a clear improvement, I don’t remember myself spending a ton of time agonizing over the vote of no confidence portion of PEP 13, so it just got missed
I don’t think one week is sufficient, given that we’re a community of (mostly) volunteers and people may be offline or away at the time the vote of no confidence is called for. They might also want a bit of time before seconding. Not everyone has an entranched opinion up front.
I also don’t buy the argument that calling for a vote of no confidence introduces too much uncertainty. The core development community hasn’t stopped working in the last ~2 weeks AFAICT. And it’s not like this happens often either…
I don’t think it makes sense for anyone to push for a vote without having already lined up strong support. If you don’t have a bunch of voters ready to immediately agree to second it when you call for such a last-resort action, there is no point. One week is quite reasonable (and already generous).
This deadline is not the duration of the voting period.
Just the “I should’ve done my homework and actually talked to a bunch of other voters first to see how in touch with our community I was before even posting this call for a formal process” period.
Plus even if the original deadline expires, nothing stops either of the two from calling for a new vote and the other seconding it, at any time. This can be the next week, month, whenever.
How do you do that? There are no political parties here, and many people don’t really know each other. Perhaps there is a smaller subset of people that have strong personal ties with each other, and confidently know each other’s leanings; if that’s your case then good for you. But many other people don’t.
In this case, many core developers expressed concerns with the 3-month suspension, yet none of them appeared willing to support the vote of no confidence (until before @stoneleaf dropped it, at least). Should @stoneleaf have privately e-mailed all of them?
I don’t understand what generosity has enough to do with this. A 2-week period wouldn’t hurt anyone. Nothing is gained by making it shorter, so why are you insisting on it?
The only caveat there is that the VoNC came at a relatively quiet time during the development cycle. If it had come up at a time during the cycle where e.g. lots of PEPs need deciding on, then I think it would likely be much more disruptive. I’m not sure an SC under a VoNC process would be too eager to make final decisions on PEPs until that vote was resolved.
You talk to people. Directly. Including with people you expect to have opinions that differ from your own. Use the non-public Inquisition category here perhaps if you feel that is your only connection to others. Private conversations, in general, work better when seeking a gut check on your own reactions. Many active committers hang out on our (non-public) Discord server for real time collaboration purposes.
Publicly calling for a vote requiring a super majority to pass when you haven’t checked to see if you are aligned with a significant number of voters beforehand is not constructive.
I don’t care what the limit is so long as it is not long. A month would be too long. While 2 weeks is pushing it in my mind, it is less than a month so, fine, whatever.
Others already explained why prolonging won’t help. Of course some will disagree. A difference in deadline will have zero impact on any outcomes as others already noted. The important thing is that we actually define a deadline. Lets not bikeshed the duration to death. When we vote for a PEP-13 text update, choosing the text that has the broadest support will make the process easier. So I’d just go with 2 weeks in such an edit as nobody who wants it to be shorter is going to reject that as it remains a clear improvement closing the open-endedness.
I think you’re underestimating how much courage it takes to put out such a vote request. It is well possible that people will only even consider supporting and seconding such a vote when someone has shown courage, stepped up and publicly announced it.
I won’t even go into details on what the social implications can be, if you try to gather support and the party you are trying to have dismissed hears about this early and then ramps up a campaign against you. I’ve been there; it’s no fun.
I also noticed this. I would have posted a two-week proposed deadline had I not withdrawn the motion.
I think two weeks is better simply because we are a volunteer community, not everyone has full-time access, and people should have time to think about such an important event.
That may seem at odds with my quick withdrawal, but I think the outcome was the best possible one: the failures of the current system were acknowledged, and the current board received overwhelming support (at least of those who responded within the 24 hours the motion was active). I saw no reason to extend the stress through the weekend when we had constructive changes proposed.
Looking at PEP 13 itself, the only 1 week deadline we have is voting for new core devs.
While I prefer the 1 week timeline so things are not left open for too long, going for 2 weeks might actually make proposing a no-confidence vote feel even more “heavy” as I agree w/ Greg and Barry that the SC will very likely suspend decision making while they wait to see what’s going to happen (assuming people don’t try to denial-of-service the SC by constantly proposing a no-confidence vote).
Yes, but I’m not thinking of one person doing it, but a group of people doing it one-by-one once a quarter or something so it adds up to 6 weeks over a year by 4 separate people.
Anyway, I’m very likely thinking of an edge case that won’t happen.
Coming back to this now that SC nominations have opened…
Is there something procedural that needs to happen so that this is an item to vote for on the same vote cycle as the SC vote? (eg: an update to PEP 8106)
Somewhat relatedly, one way to resolve the one week vs two week selection is having this be an approval vote with two options (2 weeks / 1 week) rather than a yes/no question.
Since we have a threshold requirement already, we don’t need a “none of the above” option (one can vote for none of them, which will reduce odds of the vote reaching threshold). If both cross the threshold, we can pick the one with the higher approval count. And, in case of a tie, pick one at random.
Changes to this document require at least a two-thirds majority of votes cast in a core team vote which should be open for two weeks.
This does not necessarily have to be part of the SC vote or using Helios, it can be a Discourse poll in the Committers category along with an email for visibility. See How to enact changes to PEP 13 for discussion and agreement on this.
So it might be easier doing a Discourse poll than using Helios? In any case, it would make sense for the two-week PEP 13 vote to coincide with the two-week SC election vote.
I think we should include an option for the status quo (that is, no defined deadline). If you see two options (2 weeks/1 week) it looks like those are the only options, and there should be a way to actively vote for the status quo.
