The proposed diff would change PEP 13 to specify the following:
FYI the steering council approves of these changes.
0 voters
I’d rather have two weeks for membership votes as well, so I chose -1.
Quickly searching it doesn’t look like https://www.python.org/dev/peps/pep-0013/ currently specifies a vote duration for these, so it’ll be good to have something in place.
I’m with Antoine here. Lets keep it simple and recommend two weeks for everything.
I will mention that some feedback we got on the last round of votes for core devs is that at least one of candidates found the waiting for the results stressful even at one week, so extending it to 2 weeks would not help alleviate that. Compare that to updating PEP 13 where the personal impact on any single individual is greatly reduced and thus not nearly as stressful.
Perhaps if we managed to make the vote private the stressful aspect would be alleviated?
It’s a possibility.
It’s probably a per-person question as to whether the anticipation/dread of waiting for the results is the stress inducer or if it’s seeing the live vote count as the vote occurs (partially why I’m experimenting w/ hiding the voting results until the poll closes).
I think a two-week window will give adequate time for discussion and allow a greater percentage of core devs to vote. I appreciate that waiting is stressful, but that’s part of being a core dev.
The easiest way to relieve that stress, when possible, is don’t tell the candidate about the proposal until it’s done and positive. 
Unfortunately we have had people turn down the invite to be considered for a core dev and I don’t know if people would like us holding a vote for them without their prior knowledge (especially if that vote doesn’t go in their favour).
I guess I should explain why PEP 13 doesn’t already specify these details. They were intentionally left to the steering council. The idea was that the steering council can’t override the things the PEP does mention, so they can’t e.g. appoint a bunch of new core team members without holding a vote, or change the threshold for electing them. But, if they want to choose between a 1 week or 2 week voting period, they they can do that using their regular powers. (And likewise for other details like what platform is used to hold the vote.)
The main difference is flexibility: if the steering council sets a voting period of 1 week, and then later we decide 2 weeks would be better, the steering council can just change it. If we set the periods by a vote like this, then the only way to adjust them in the future will be to do another whole-project PEP-13-amendment supermajority vote.
This might have gone more smoothly if the proposal were posted for discussion before starting the vote, so there was a chance to incorporate feedback? (Cf. the council’s mandate to “Seek consensus among contributors and the core team before acting in a formal capacity”.)
@njs: I’m not sure making these two changes are in the scope of powers of the steering council. They speak to the two things that PEP 13 says the council can’t do: change PEP 13 and affect the membership of the core team. Although I guess you could argue that the length of the elections doesn’t directly affect either of those things. But I think, for these two items specifically, have the core devs vote is a good idea.
I think a better way to handle this is to have independent discussions on these two issues first, then propose independent votes. As it is, I can’t say I’d prefer 2 weeks for #1 and a month for #2.
I’m the past, we’ve said short election cycles don’t allow enough time for people on vacation, etc.
Agreed. While I wouldn’t want things to degenerate into endless debates, it would be nice to get a bit more insight into the direction of the council’s thinking before things pop up as proposals/votes.
The controversial “one week for core dev votes” topic was brought up on python-committers when Victor brought up Stephane’s candidacy. He asked if anyone objected to his proposed one week for that vote, no one objected and I at least personally said I supported the one week amount of time. Based on that I don’t think anyone on the council viewed this as controversial (or at least that’s why I didn’t expect any specific issues with the proposed time length and didn’t worry about bringing it up ahead of time).
The PEP 13 changes has not been brought up previously, but everyone seems fine with 2 weeks. My guess is that since that’s the length we use for steering council elections then that’s become an acceptable amount of time.
That was my motivation for wanting to see it specified, as otherwise the steering council could theoretically manipulate core dev membership or PEP 13 changes by arbitrarily closing votes when the count was in their favour. I.e. PEP 13 doesn’t say vote length has to be specified before voting starts, so technically I could vote myself and then shut the vote down immediately thereafter and be within the guidelines of PEP 13 (although obviously not operating within its spirit).
We actually talked about doing that, but since this is the first time anyone has proposed a change to PEP 13 we weren’t sure if that was what people wanted for similar things like this or if people prefer the PSF board approach of making more rolled-up proposals when things are not considered controversial. In the end we decided to give this approach a go. I know in my head I view this as a single topic to specify voting time frames and not two separate things, so that’s also why I thought about doing it this way.
There’s no real insight. During the last group of votes for core devs the question came up about how long the votes should be open. Some people said “how about a week?” People seemed happy with that, so that’s what we did. It seemed reasonable to write that down and that’s when I realized we would be bringing this up as a vote which also lacked a time frame, so we figured we might as well solve both of them simultaneously.
My memory is that previous semi-formal committers-list discussions about new core devs, with ± votes, seldom if ever went more than a week.
Thanks to everyone who voted! The ayes have it at 85% > 66%.
Um, shouldn’t those two numbers add up to 100% or less? 
I assume what @brettcannon meant is that 85% were in favour (15% against) and that’s more than the 66% needed to carry the vote?
Paul is correct.