Re: [python-committers] Reminder of BDFL succession timeline + CFP
Thanks all for voicing your concerns and all the feedback. So far I hear people opposing the strict deadline because they're afraid it means we'll be making rush decisions for the sake of meeting deadlines. Well here are my reasonings of why I'm setting deadlines and timelines: We all know it, discussions in mailing list can go on forever. And now that we don't have a BDFL who will shut down and end discussions, these things can really go literally forever. Therefore we should timebox these discussions. I believe that none of us actually want Python without governance and without decision forever. The Python community is waiting for core developers to come together and figure out Guido's successor. For myself, January 1, 2019 is reasonable deadline, it will be 6 months since Guido announced his permanent vacation. In separate thread, it seems that we're in agreement that Oct 1, 2018 for deadline to come up with proposals of governance model. So then, what needs to happen between Oct 1 to Jan 1? (3 months period?) How do we go from "here are the proposed governance model" into "we have selected the successor(s)"? Clearly, if we want to have decision by Jan 1, people can't still be arguing about governance model on Dec 31st. If we're going to vote on things, people need to know when they need to show up to vote. We probably need someone to volunteer and set up the voting system, or get in touch with The PSF for setting it up, and maybe account for flexibilities in case there are last minute technical difficulties and so on. All of these require coordination and concerted effort. >From there, I've started breaking down the different phases of how this will go, and also allowing ample time for people to catch up and read their emails. For example, in my timeline, I suggested 2 weeks time of voting in each round. In reality, voting is probably just going to take a few clicks on a website, not 2 full weeks. I'm just drawing from my own personal experience of having organize and coordinate a group of volunteers. What I've learned is that the group will be more successful when each volunteers know their roles, responsibilities, the goal of the group, and in a lot of cases, they need to know when they should deliver and complete their task. Python core devs are all volunteers, living in different timezones, in different part of the world, and we all have other commitments to our employer and family. But right now we all have responsibilities to come up with a plan of succession for this community. It was the last task Guido gave to us before retiring as BDFL. These timelines are not meant for you to rush and make decision last minute just because there is a deadline. On contrary, I hope that by knowing these timelines ahead of time, you all can account for these dates, you can be responsible, and if needed, adjust and plan ahead your volunteering schedule surrounding these dates. If you are proposing a governance model, and someone else here have questions about it, it will be appreciated if you can respond in timely manner, and not wait 4 months before you respond. Similarly, if you have question and concern or just want to argue about a proposed governance model, you should do it sooner, within these timeboxed periods, and not wait until 2020, and don't wait until last minute either. You'll need to give time for the proposer to respond to you. (again we all live in different timezones). I'm also guessing that not everyone here is planning to come up with 100 different proposals, and not everyone here wants to argue at all. Perhaps some of you are just waiting for the ballot to arrive in the email? There is value in knowing in advance of when you need to vote, so you can plan on watching their mailbox, or alert us if they didn't receive the ballot. I hope by knowing these timelines people can be more considerate with each other, and that they'll be able to express their thoughts more effectively in emails. Without clear deadlines, sure there is less pressure of not rushing into making decisions, but it also allows for discussions to stall forever. I also don't want people to come up with yet a new proposal every other week. So I still would like us to have clear deadlines and timebox this whole succession process. "clear" does not need to be "strict". What I will try to do is to post reminders here, a week before the expected "deadline" and ask if people need extensions, and we'll extend the dates accordingly. (similar to what Python release managers normally do). But maybe the extension will be for only another one week or two, not forever. What do people think about this? It seems like several people (Barry, Brett, Steven) and myself are ok with January 1, 2019 as the a deadline of choosing the successor. For those opposing the deadlines, do you have a different date in mind? Here are my proposed timeboxes again, adjusted to AoE timezone, and including Barry's guidance of using PEP 8k+
Re: [python-committers] Reminder of BDFL succession timeline + CFP
Le 05/08/2018 à 10:50, Ronald Oussoren via python-committers a écrit : > > >> On 4 Aug 2018, at 11:36, Steven D'Aprano wrote: > >> When Australia's prime minister disappeared, it took two days to swear >> in a replacement and less than a month to call a new election. > > But that was easy: Most countries have predetermined procedures to deal with > such scenarios. Indeed, this is conflating changing leadership (under the same regime where it's normal to change leaders from time to time) with regime change. Regards Antoine. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
> On 4 Aug 2018, at 11:36, Steven D'Aprano wrote: > When Australia's prime minister disappeared, it took two days to swear > in a replacement and less than a month to call a new election. But that was easy: Most countries have predetermined procedures to deal with such scenarios. Ronald ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Thu, Aug 02, 2018 at 09:22:44AM +0100, Paul Moore wrote: > On Thu, 2 Aug 2018 at 08:50, Steven D'Aprano wrote: > > > Indeed. A hard deadline concentrates the mind. It doesn't need to be > > tomorrow, I think your choosen dates are a great balance, neither too > > quick nor too drawn out. > > But it also encourages people (particularly people with limited free > time) to rush decisions, and focus on "getting something done in > time", rather than "doing the right thing". Balancing those two > pressures is not easy, and the balance point varies significantly > between individuals. A proposal is not an agreement to accept that proposal. If people submit rushed, poor quality proposals, they will likely not be accepted. And if they are, we have nobody to blame but ourselves. Can't blame Facebook and fake news if we vote badly :-) The longer we push out any such deadline, the more likely people will simply forget about it, or delay until the week before and then have to rush a poorly delivered proposal (or no proposal at all). > > If Python is still rudderless by Christmas, I think we have failed. > > Do you really consider Python "rudderless" at the moment? *shrug* I'm not married to that specific word, but we have no BDFL and no mechanism in place for making big decisions about the language. What term would you use? Certainly day to day development continues as normal. Bugs get fixed, minor releases get released, PRs get reviewed, etc. That's great and a credit to the core developers. But this thread suggests that if we're not careful, we could get bogged down for many months just deciding on the mechanism we use to decide what to do next. That's why I like Mariatta's concrete proposal to set some firm dates for action. In my opinion, if people can't find an hour or four to write up a concrete proposal for choosing a new Dictator/Despot/Council/whatever in eight weeks, they're not likely to find the time/motivation in eight months either. > I honestly think that describing the current situation as "rudderless" > and a "failure" if it carries on, is a pretty big exaggeration. Christmas is almost five months away. Do you think that it is acceptable for such a small group as us to take five months and still not have decided on a new leadership model? That's a matter of personal opinion and I accept we can differ on tolerance for bikeshedding. How many months, or years, before you personally would call it a failure? When Australia's prime minister disappeared, it took two days to swear in a replacement and less than a month to call a new election. https://en.wikipedia.org/wiki/Harold_Holt#Disappearance Obviously the stakes are higher for national governments, we can afford to be more leisurely about the process, but I don't think we should let it drag on and on. I think that Christmas is more than sufficient. If you don't, how long do you feel will be? This isn't a rhetorical question. I'm not wedded to this time frame -- if you think we need six months, I'm listening. If you think we need six years, forget it :-) It's been three weeks since Guido's retirement, approaching a month. We agree that we need some sort of leadership model, and we know that there's a risk of the process devolving into endless argument with no progress, or just fading away into inactivity, unless managed. In my opinion agreeing on concrete deadlines, not too rushed but certainly not too far away either, is a good first step at managing this. -- Steve ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Aug 1, 2018, at 12:41, Mariatta Wijaya wrote: > > Since this is like a CFP I figured we should clarify what's expected the > proposal, and I also wanted to be more detailed in the timeline. > > Oct 1 00:00:00 UTC: Deadline of coming up with proposals of governance model. Thanks for writing this up Mariatta. I think it’s very useful to put stakes in the ground so that these discussions don’t drag on forever. I agree with those who say that the status quo is an implicit choice of governance models, and I think we shouldn’t operate under implicit rules for too long. Like Brett, I often have folks coming up to me and asking me what’s going on, and when Python will decide on a governance model. Let’s not underestimate the message this sends to the outside world. OTOH, we do have some flexibility in the timeline, and I still believe that we have flexibility in the governance model over the long term. I’ve no doubt that no matter what we choose, the debate will continue, with ebbs and flows as situations arise. That may even lead to new (or adjusted) governance models in the future, and that’s fine! Unlike with Python itself, we aren’t bound to strict backward compatibility. :) That said, I think it’s worthwhile capturing the proposed governance models in PEPs so that we all know exactly what we’re debating. October 1st for that round of PEP submissions is quite reasonable IMHO. Procedurally, I suggest we segregate governance model PEPs in their own 4th digit namespace (e.g. like the way Python 3k started at the 3000s). 8 seems like a good number; we reserve the lower 8ks for “special” PEPs (the problem statement, the choice, the voting procedure, etc.). We can be a little more loose on the voting schedule, but like Brett, I would like to have a decision by the end of 2018, even if that decision is an explicit choice of status quo. Cheers, -Barry signature.asc Description: Message signed with OpenPGP ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
> On Aug 3, 2018, at 02:19, Yury Selivanov wrote: > > OTOH, it would be great if we can at least set a date to start the > discussion so that everybody can plan for it and join. That's the > only way to keep the discussion open and equally accessible for > everyone. If we do nothing, then naturally, those core devs who know > each other personally will start forming their opinion in isolated > groups. Many people will feel that they are completely removed from > the decision process and will end up in a very uncomfortable position. Hmm, you’re right. Not having any sort of timeline or process will mean that lots of stakeholders will not know about any discussions and feel left out by the end. Some sort of a schedule would ameliorate that. Jack ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On 8/2/2018 8:01 PM, Yury Selivanov wrote: On Thu, Aug 2, 2018 at 4:43 PM Brett Cannon wrote: On Wed, 1 Aug 2018 at 17:58 Yury Selivanov wrote: On Wed, Aug 1, 2018 at 8:29 PM Mariatta Wijaya wrote: [..] I'm open to extend the dates, and even wait another year if we need to. Or do folks want to come up with a completely different process than what I've proposed? In the end, I just want to know whether we will come to decision before 2019, 2020, 2021, 2022, .. ? IMHO we should tweak the proposal to include just *one date for now*: we want everybody interested to post their proposals by October 1st (we can shift it + 2 weeks if people are on vacations right now). I was actually going to email suggesting this but Mariatta beat me to the subject. :) I think you've confused Mariatta with me here :) For me, I think aiming for October 1st to get the initial proposals in is a good goal. Yeah it looks like people don't oppose having October 1st as our first *soft* sync point as long as we don't set any other deadlines right now. To sum up: * We want everybody who has ideas about future Python governance model to submit their initial proposals by that date. * The discussion will start around October 1st and we'll figure out what we do next (and when) based on its outcome. I think this plan is reasonably relaxed, but at the same time will gently motivate us to move forward. I agree. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Thu, Aug 2, 2018 at 3:55 PM Jack Jansen wrote: > > Nathaniel, you strike the nail on the head here. > > The reason Guido as BDFL and therefore ultimate authority on what “python” is > worked because it is organic: it is not set down in strict rules and > regulations and timelines and percentages of votes and what not. It works > because a very large fraction of the community accepts it. (And I know I’m > mixing past and present tense and I’m doing it on purpose:-) > > We need to come up with a new governance model, and I think that a > rules-and-regulations model is not a model that Python will thrive by. On the > contrary, I think it has the danger of moving people into a > rules-and-regulations mindset, and therefore lead to all sorts of decisions > being viewed in a “political” light, where before they wouldn’t be. > > And my worry is that be introducing deadlines and all that in the process > there is the danger that we will inexorably move to a strict governance > model. I would much prefer a process where we go here/there/everywhere and > slowly a consensus builds up. I agree and that's why I also don't like the idea of having a strict set of deadlines for voting on something that hasn't even been proposed yet. OTOH, it would be great if we can at least set a date to start the discussion so that everybody can plan for it and join. That's the only way to keep the discussion open and equally accessible for everyone. If we do nothing, then naturally, those core devs who know each other personally will start forming their opinion in isolated groups. Many people will feel that they are completely removed from the decision process and will end up in a very uncomfortable position. Yury ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Thu, Aug 2, 2018 at 4:43 PM Brett Cannon wrote: > > On Wed, 1 Aug 2018 at 17:58 Yury Selivanov wrote: >> >> On Wed, Aug 1, 2018 at 8:29 PM Mariatta Wijaya >> wrote: >> [..] >> > I'm open to extend the dates, and even wait another year if we need to. >> > Or do folks want to come up with a completely different process than what >> > I've proposed? >> > >> > In the end, I just want to know whether we will come to decision before >> > 2019, 2020, 2021, 2022, .. ? >> >> IMHO we should tweak the proposal to include just *one date for now*: >> we want everybody interested to post their proposals by October 1st >> (we can shift it + 2 weeks if people are on vacations right now). > > > I was actually going to email suggesting this but Mariatta beat me to the > subject. :) > I think you've confused Mariatta with me here :) > For me, I think aiming for October 1st to get the initial proposals in is a > good goal. Yeah it looks like people don't oppose having October 1st as our first *soft* sync point as long as we don't set any other deadlines right now. To sum up: * We want everybody who has ideas about future Python governance model to submit their initial proposals by that date. * The discussion will start around October 1st and we'll figure out what we do next (and when) based on its outcome. I think this plan is reasonably relaxed, but at the same time will gently motivate us to move forward. Yury ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Thu, 2 Aug 2018 at 00:24 Ronald Oussoren via python-committers < python-committers@python.org> wrote: > > > > On 2 Aug 2018, at 01:06, Yury Selivanov wrote: > > > > On Wed, Aug 1, 2018 at 6:44 PM Mariatta Wijaya > > wrote: > >> > > > >> Currently any undecided PEP is stalled, and no one can pronounce on > them. > > > > And maybe that's OK for a few months? I don't recall Guido ever > > accepting PEPs promptly. :) Setting strict deadlines really seems > > like a last-resort option. > > That, and it might be acceptable to start with a consensus based model for > accepting PEPs at first. That would help in getting it clearer what we > really need going forward (which as several people have stated is more than > just deciding on PEPs). That would mean that contentious PEPs would have > to wait longer, but that isn’t necessarily a bad idea. > So basically you want to see if we can find consensus on using consensus for PEPs? ;) Or put another way, basically this seems to suggest giving the consensus/voting approach a chance without specifically saying you want to give other proposals on how to model PEPs a chance as well because deciding by consensus is still a governance model. Personally I would rather say that we are in a language moratorium until we resolve this governance situation and if that means Python 3.8 is a boring release then so be it. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Wed, 1 Aug 2018 at 17:58 Yury Selivanov wrote: > On Wed, Aug 1, 2018 at 8:29 PM Mariatta Wijaya > wrote: > [..] > > Please don't misunderstand my wanting to set up a deadlines and process > as wanting to rush things. > > Absolutely, I understand, I didn't want to imply that "[name] is > rushing the process". Sorry if I sounded this way. I do have an > impression, though, that a large population of core devs is OK with > deadlines and the other sizable population doesn't understand why we > need a strict schedule right now. > For me I want to start laying out goals (or at least an initial goal) because I don't want to procrastinate because this happens to be a hard problem. I don't think any dates have to quite be all-or-nothing, but I can also see this dragging on if we don't start to guiding ourselves towards some resolution at some point. I'll also mention that I'm looking to keep this moving this forward because unlike Yury's experience as EuroPython, people have been asking me when this is going to be resolved, not that we are moving too fast. > > > I'm open to extend the dates, and even wait another year if we need to. > > Or do folks want to come up with a completely different process than > what I've proposed? > > > > In the end, I just want to know whether we will come to decision before > 2019, 2020, 2021, 2022, .. ? > > IMHO we should tweak the proposal to include just *one date for now*: > we want everybody interested to post their proposals by October 1st > (we can shift it + 2 weeks if people are on vacations right now). > I was actually going to email suggesting this but Mariatta beat me to the subject. :) For me, I think aiming for October 1st to get the initial proposals in is a good goal. If it looks like people need some more time then that's fine and they can ask for it and we can all agree to extend it, but we first need to (a) get to October 1, and (b) people actually end up needing more time :) . As of right now no one has concretely said that October 1 won't work for them (it's actually October 1 specifically because Victor asked for that date so he could make a proposal due to his vacation in August). So for me, going forward with the goal of October 1 for people proposing governance models seems reasonable and we can re-assess as we get closer to that date. > > The discussion will inevitably start as soon as we have a couple > proposals on the table. Some proposals will be withdrawn, some will > require tweaks, people also might come up with new proposals. We can > then decide what our next steps (and deadlines!) considering what will > be the outcome of these first debates. > +1 ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
Nathaniel, you strike the nail on the head here. The reason Guido as BDFL and therefore ultimate authority on what “python” is worked because it is organic: it is not set down in strict rules and regulations and timelines and percentages of votes and what not. It works because a very large fraction of the community accepts it. (And I know I’m mixing past and present tense and I’m doing it on purpose:-) We need to come up with a new governance model, and I think that a rules-and-regulations model is not a model that Python will thrive by. On the contrary, I think it has the danger of moving people into a rules-and-regulations mindset, and therefore lead to all sorts of decisions being viewed in a “political” light, where before they wouldn’t be. And my worry is that be introducing deadlines and all that in the process there is the danger that we will inexorably move to a strict governance model. I would much prefer a process where we go here/there/everywhere and slowly a consensus builds up. Jack Sent from my iPad > On Aug 1, 2018, at 23:22, Nathaniel Smith wrote: > > On Wed, Aug 1, 2018 at 12:41 PM, Mariatta Wijaya > wrote: >> Since this is like a CFP I figured we should clarify what's expected the >> proposal, and I also wanted to be more detailed in the timeline. >> >> Oct 1 00:00:00 UTC: Deadline of coming up with proposals of governance >> model. >> >> To be included in the proposal: >> - explanation and reasoning of the governance model >> - expected roles and responsibilities >> - candidate for the role need not be included at this time, since we're only >> choosing the governance model. Depending on the governance model chosen, we >> might have different people to be nominated. There will be a separate >> process for nominating the candidate. >> - the term of governance: is it for life? 5 years? 10 years? >> >> Who can submit the proposal? >> Python core developers. Individual core devs can submit a proposal, or >> co-author the proposal with another core dev. >> >> How to submit the proposal? >> Proposal should be in a form of a PEP, and merged into peps repo before Oct >> 1 00:00:00 UTC. Proposals not merged after Oct 1 00:00:00 UTC will not be >> considered. >> >> Oct 1 - Nov 15: Review period. >> All core developers will review the PEPs, and ask any questions to the PEP >> author. This timeline allows for enough time for all core devs to carefully >> review each PEPs, and for authors to respond. >> >> There will be two parts of this: >> >> Review phase 1: Oct 1- Nov 1: Allow changes and tweaks to the proposed PEPs. >> I figured people will have questions and will need to clarify the PEPs >> during this period. But if we want the PEP to be final by Oct 1, that's fine >> by me. maybe allow typo fixes still. >> >> Review phase 2: Nov 1 00:00:00 UTC: No more changes to the above PEPs. >> No more tweaks to these PEPs. PRs to these PEPs should be rejected. >> This is the final chance to carefully review all governance PEPs, and >> formulate your decisions. > > I'm worried that this whole plan is a bad idea. > > This kind of process with deadlines, proposals, votes, etc., is an > excellent way to take legitimacy and make it visible. That's a > valuable thing, and addresses an important problem. But it's not the > problem I'm most worried about here. > > As engineers, we know that every design has trade-offs, and that goes > for governance as well. Having a universally acclaimed BDFL like Guido > has many tremendous advantages. But it also has one tremendous > disadvantage: because we always knew Guido would make the final > decision, and that we could always appeal to him when things didn't go > the way we like, python-dev has never had to learn to work out > disagreements and get along. > > Now we have to figure that out: the legitimacy of any new governance > system is ultimately going to have to rest on the consensus of the > core devs. The only way I know to get that is by taking the time to > work through the difficult conversations. If these deadlines just > encourage people to keep moving and engaging, then that's great. But I > worry that if we impose a cut-off like this up front, then we'll take > that as an excuse to skip doing that work, because there's no time, > and if someone disagrees it's easier to vote than to actually engage > and work it out. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > ___ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
2018-08-01 23:10 GMT+02:00 M.-A. Lemburg : > So let's ponder some more about ideas we could use to > get there and perhaps watch some Monty Python movies for > inspiration ;-) Monty Python's Life of Brian is an obvious tutorial how to select a BDFL where FL means for life ;-) Victor ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Thu, 2 Aug 2018 at 08:50, Steven D'Aprano wrote: > Indeed. A hard deadline concentrates the mind. It doesn't need to be > tomorrow, I think your choosen dates are a great balance, neither too > quick nor too drawn out. But it also encourages people (particularly people with limited free time) to rush decisions, and focus on "getting something done in time", rather than "doing the right thing". Balancing those two pressures is not easy, and the balance point varies significantly between individuals. > If Python is still rudderless by Christmas, I think we have failed. Do you really consider Python "rudderless" at the moment? I only really see two threads (excluding this one ;-)) that could give that impression - "None-aware operators", where the discussion was deliberately re-opened when Guido stepped down, to have a debate in the absence of a BDFL (a decision which I personally feel was ill-advised, but which IMO excludes it from any consideration in this context) and the discussion on optimising PyCFunction (which is highly technical, and has 2 specialists disagreeing - that's pretty much guaranteed to drag on for a while). Most things are carrying on as usual (with a certain level of people wondering what will happen, but not in a way that's blocking activity). I honestly think that describing the current situation as "rudderless" and a "failure" if it carries on, is a pretty big exaggeration. Maybe at worst, Python 3.8 will be relatively light on new features, but that's not necessarily a bad thing (and yes, I understand that's a decision by inaction. but personally I'm OK with it). Not so much a moratorium, as "taking a breath". Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Thu, 2 Aug 2018 at 01:58, Yury Selivanov wrote: > > On Wed, Aug 1, 2018 at 8:29 PM Mariatta Wijaya > wrote: > [..] > > Please don't misunderstand my wanting to set up a deadlines and process as > > wanting to rush things. > > Absolutely, I understand, I didn't want to imply that "[name] is > rushing the process". Sorry if I sounded this way. I do have an > impression, though, that a large population of core devs is OK with > deadlines and the other sizable population doesn't understand why we > need a strict schedule right now. I think this is an important point. I'm also -1 on a strict timetable here - I agree with the points Marc-Andre and Nathaniel made, and I don't want to see us rushing into a decision. It actually strikes me that the disparity here (with some people wanting to keep the process moving and get something sorted so we can get back to normal, and others wanting to let things take their time and not force a decision simply because "we need to decide") is an excellent test case for how we make decisions in the future. If we can't reach a mutually satisfactory agreement on how to move forward on this, I don't have high hopes for the possibility of our choice of governance model being acceptable to everyone. > > I'm open to extend the dates, and even wait another year if we need to. > > Or do folks want to come up with a completely different process than what > > I've proposed? > > > > In the end, I just want to know whether we will come to decision before > > 2019, 2020, 2021, 2022, .. ? At the moment, I'm not even sure I want to know that much. For now, what I want to know is how things are going to feel now that we don't have Guido acting as BDFL. That's going to take time to assess, but until we have done that, I don't see how we (as a community) can have any sort of good idea about what sort of governance works for us. What I'd like to understand from the people advocating a fixed timetable and agreed dates, is what *actual* problem does fixing dates solve? Are bpo discussions being held up for lack of a BDFL? Are people not committing changes? Certainly we're not accepting PEPs at the moment, but it's not like PEPs work on a rapid timescale anyway - and if the problem is that without a BDFL, the discussions feel directionless, then that's a *specific* problem we can solve without needing to agree a governance model (it's the "guiding discussions" aspect of Guido's role, as opposed to the "BDFL" part). Paul ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Wed, Aug 01, 2018 at 05:29:00PM -0700, Mariatta Wijaya wrote: > Please don't misunderstand my wanting to set up a deadlines and process as > wanting to rush things. > I'm open to extend the dates, and even wait another year if we need to. Please no. Leaving things in limbo for a handful of months is one thing, a year or more is not. In a year, we will have completely lost all momentum on this. Deciding on a model for Python's future ought not to be an endurance competition, where the winner is the one who can wait the longest until everyone else has moved on. Failing to choose a model to drive the future of Python in a reasonable time is a choice in itself. If folks want to actively propose a policy of (temporary or permanent) stability (a.k.a. stagnation) for the Python language, let them do so. I'm sure that would be popular to many people. It might even win a democratic vote. Dragging this process out for a year or more is, de facto, such a policy (regardless of whether it was intended as such) and such a policy ought to be decided openly, not accidentally or by stealth. > Or do folks want to come up with a completely different process than what > I've proposed? > > In the end, I just want to know whether we will come to decision before > 2019, 2020, 2021, 2022, .. ? Indeed. A hard deadline concentrates the mind. It doesn't need to be tomorrow, I think your choosen dates are a great balance, neither too quick nor too drawn out. If Python is still rudderless by Christmas, I think we have failed. -- Steve ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
> On 2 Aug 2018, at 01:06, Yury Selivanov wrote: > > On Wed, Aug 1, 2018 at 6:44 PM Mariatta Wijaya > wrote: >> > >> Currently any undecided PEP is stalled, and no one can pronounce on them. > > And maybe that's OK for a few months? I don't recall Guido ever > accepting PEPs promptly. :) Setting strict deadlines really seems > like a last-resort option. That, and it might be acceptable to start with a consensus based model for accepting PEPs at first. That would help in getting it clearer what we really need going forward (which as several people have stated is more than just deciding on PEPs). That would mean that contentious PEPs would have to wait longer, but that isn’t necessarily a bad idea. FWIW I agree with Nathaniel and Marc-Andre. Ronald ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Wed, Aug 1, 2018 at 8:29 PM Mariatta Wijaya wrote: [..] > Please don't misunderstand my wanting to set up a deadlines and process as > wanting to rush things. Absolutely, I understand, I didn't want to imply that "[name] is rushing the process". Sorry if I sounded this way. I do have an impression, though, that a large population of core devs is OK with deadlines and the other sizable population doesn't understand why we need a strict schedule right now. > I'm open to extend the dates, and even wait another year if we need to. > Or do folks want to come up with a completely different process than what > I've proposed? > > In the end, I just want to know whether we will come to decision before 2019, > 2020, 2021, 2022, .. ? IMHO we should tweak the proposal to include just *one date for now*: we want everybody interested to post their proposals by October 1st (we can shift it + 2 weeks if people are on vacations right now). The discussion will inevitably start as soon as we have a couple proposals on the table. Some proposals will be withdrawn, some will require tweaks, people also might come up with new proposals. We can then decide what our next steps (and deadlines!) considering what will be the outcome of these first debates. Yury ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
> > IIRC we always promoted core devs by popular vote, so I don't think > this would be a problem. Do we have any candidates that are currently > waiting for us deciding on a governance model? If this new governance model will include core devs being able to vote on PEPs, then I will have different opinion on how I want to vote or promote any new core dev. And maybe that's OK for a few months? I don't recall Guido ever > accepting PEPs promptly. :) Setting strict deadlines really seems > like a last-resort option. Please don't misunderstand my wanting to set up a deadlines and process as wanting to rush things. I'm open to extend the dates, and even wait another year if we need to. Or do folks want to come up with a completely different process than what I've proposed? In the end, I just want to know whether we will come to decision before 2019, 2020, 2021, 2022, .. ? Mariatta On Wed, Aug 1, 2018 at 4:06 PM Yury Selivanov wrote: > On Wed, Aug 1, 2018 at 6:44 PM Mariatta Wijaya > wrote: > > > > > > Thank you for the responses and concerns. > > > > I do want to keep this discussion open and ongoing, and I still think > that we do need a set deadline on things. > > I talked to a few core developers recently (at EuroPython and over > messengers) and I had an impression that some of them don't like an > idea of making a decision faster than everybody has a chance to say > their word. Some of them are shy to publicly object to having strict > deadlines, some probably haven't yet seen this thread, some don't have > time to engage right now. You also see a few -1s in this very thread. > All in all, I really don't understand why we need to hurry here. > > > Currently any undecided PEP is stalled, and no one can pronounce on them. > > And maybe that's OK for a few months? I don't recall Guido ever > accepting PEPs promptly. :) Setting strict deadlines really seems > like a last-resort option. > > > And we probably won't/can't promote any new core devs until we have new > governance. > > IIRC we always promoted core devs by popular vote, so I don't think > this would be a problem. Do we have any candidates that are currently > waiting for us deciding on a governance model? > > Yury > ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Wed, Aug 1, 2018 at 6:44 PM Mariatta Wijaya wrote: > > > Thank you for the responses and concerns. > > I do want to keep this discussion open and ongoing, and I still think that we > do need a set deadline on things. I talked to a few core developers recently (at EuroPython and over messengers) and I had an impression that some of them don't like an idea of making a decision faster than everybody has a chance to say their word. Some of them are shy to publicly object to having strict deadlines, some probably haven't yet seen this thread, some don't have time to engage right now. You also see a few -1s in this very thread. All in all, I really don't understand why we need to hurry here. > Currently any undecided PEP is stalled, and no one can pronounce on them. And maybe that's OK for a few months? I don't recall Guido ever accepting PEPs promptly. :) Setting strict deadlines really seems like a last-resort option. > And we probably won't/can't promote any new core devs until we have new > governance. IIRC we always promoted core devs by popular vote, so I don't think this would be a problem. Do we have any candidates that are currently waiting for us deciding on a governance model? Yury ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
Thank you for the responses and concerns. I do want to keep this discussion open and ongoing, and I still think that we do need a set deadline on things. Currently any undecided PEP is stalled, and no one can pronounce on them. And we probably won't/can't promote any new core devs until we have new governance. Someone brought up the idea where core devs would be able to decide/vote on PEPs and that would affect how we promote core devs. I hope that having these dates will encourage all of us to prioritize this issue and coming up with a solution. If the deadline of January 1st is too short, please propose alternate dates, but it should not be "whenever". We may very well end up not having any kind of governance body > initially and use a simple democratic voting scheme for any > issues which may arise. I see this as one proposal of a governance body, and it's acceptable if you want to propose that we go this route for X years and re-evaluate it again. It should be ok for us to choose one governance model this time, but decide on something else next. Mariatta ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Wed, Aug 1, 2018 at 5:26 PM Nathaniel Smith wrote: [..] > Now we have to figure that out: the legitimacy of any new governance > system is ultimately going to have to rest on the consensus of the > core devs. The only way I know to get that is by taking the time to > work through the difficult conversations. If these deadlines just > encourage people to keep moving and engaging, then that's great. But I > worry that if we impose a cut-off like this up front, then we'll take > that as an excuse to skip doing that work, because there's no time, > and if someone disagrees it's easier to vote than to actually engage > and work it out. +1. I don't like this idea of having strict deadlines that we must follow no matter what. IMO it would be better to set a "recommended date" (Oct 1st is fine) for submitting governance proposals. We can start discussing them publicly after Oct 1st, and will set a strict deadline for voting when we are all comfortable. Yury ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
I think Nathaniel and Marc-André are speaking wisely here. Sorry, I've not much to add ;-) Regards Antoine. Le 01/08/2018 à 23:22, Nathaniel Smith a écrit : > On Wed, Aug 1, 2018 at 12:41 PM, Mariatta Wijaya > wrote: >> Since this is like a CFP I figured we should clarify what's expected the >> proposal, and I also wanted to be more detailed in the timeline. >> >> Oct 1 00:00:00 UTC: Deadline of coming up with proposals of governance >> model. >> >> To be included in the proposal: >> - explanation and reasoning of the governance model >> - expected roles and responsibilities >> - candidate for the role need not be included at this time, since we're only >> choosing the governance model. Depending on the governance model chosen, we >> might have different people to be nominated. There will be a separate >> process for nominating the candidate. >> - the term of governance: is it for life? 5 years? 10 years? >> >> Who can submit the proposal? >> Python core developers. Individual core devs can submit a proposal, or >> co-author the proposal with another core dev. >> >> How to submit the proposal? >> Proposal should be in a form of a PEP, and merged into peps repo before Oct >> 1 00:00:00 UTC. Proposals not merged after Oct 1 00:00:00 UTC will not be >> considered. >> >> Oct 1 - Nov 15: Review period. >> All core developers will review the PEPs, and ask any questions to the PEP >> author. This timeline allows for enough time for all core devs to carefully >> review each PEPs, and for authors to respond. >> >> There will be two parts of this: >> >> Review phase 1: Oct 1- Nov 1: Allow changes and tweaks to the proposed PEPs. >> I figured people will have questions and will need to clarify the PEPs >> during this period. But if we want the PEP to be final by Oct 1, that's fine >> by me. maybe allow typo fixes still. >> >> Review phase 2: Nov 1 00:00:00 UTC: No more changes to the above PEPs. >> No more tweaks to these PEPs. PRs to these PEPs should be rejected. >> This is the final chance to carefully review all governance PEPs, and >> formulate your decisions. > > I'm worried that this whole plan is a bad idea. > > This kind of process with deadlines, proposals, votes, etc., is an > excellent way to take legitimacy and make it visible. That's a > valuable thing, and addresses an important problem. But it's not the > problem I'm most worried about here. > > As engineers, we know that every design has trade-offs, and that goes > for governance as well. Having a universally acclaimed BDFL like Guido > has many tremendous advantages. But it also has one tremendous > disadvantage: because we always knew Guido would make the final > decision, and that we could always appeal to him when things didn't go > the way we like, python-dev has never had to learn to work out > disagreements and get along. > > Now we have to figure that out: the legitimacy of any new governance > system is ultimately going to have to rest on the consensus of the > core devs. The only way I know to get that is by taking the time to > work through the difficult conversations. If these deadlines just > encourage people to keep moving and engaging, then that's great. But I > worry that if we impose a cut-off like this up front, then we'll take > that as an excuse to skip doing that work, because there's no time, > and if someone disagrees it's easier to vote than to actually engage > and work it out. > > -n > ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Wed, Aug 1, 2018 at 12:41 PM, Mariatta Wijaya wrote: > Since this is like a CFP I figured we should clarify what's expected the > proposal, and I also wanted to be more detailed in the timeline. > > Oct 1 00:00:00 UTC: Deadline of coming up with proposals of governance > model. > > To be included in the proposal: > - explanation and reasoning of the governance model > - expected roles and responsibilities > - candidate for the role need not be included at this time, since we're only > choosing the governance model. Depending on the governance model chosen, we > might have different people to be nominated. There will be a separate > process for nominating the candidate. > - the term of governance: is it for life? 5 years? 10 years? > > Who can submit the proposal? > Python core developers. Individual core devs can submit a proposal, or > co-author the proposal with another core dev. > > How to submit the proposal? > Proposal should be in a form of a PEP, and merged into peps repo before Oct > 1 00:00:00 UTC. Proposals not merged after Oct 1 00:00:00 UTC will not be > considered. > > Oct 1 - Nov 15: Review period. > All core developers will review the PEPs, and ask any questions to the PEP > author. This timeline allows for enough time for all core devs to carefully > review each PEPs, and for authors to respond. > > There will be two parts of this: > > Review phase 1: Oct 1- Nov 1: Allow changes and tweaks to the proposed PEPs. > I figured people will have questions and will need to clarify the PEPs > during this period. But if we want the PEP to be final by Oct 1, that's fine > by me. maybe allow typo fixes still. > > Review phase 2: Nov 1 00:00:00 UTC: No more changes to the above PEPs. > No more tweaks to these PEPs. PRs to these PEPs should be rejected. > This is the final chance to carefully review all governance PEPs, and > formulate your decisions. I'm worried that this whole plan is a bad idea. This kind of process with deadlines, proposals, votes, etc., is an excellent way to take legitimacy and make it visible. That's a valuable thing, and addresses an important problem. But it's not the problem I'm most worried about here. As engineers, we know that every design has trade-offs, and that goes for governance as well. Having a universally acclaimed BDFL like Guido has many tremendous advantages. But it also has one tremendous disadvantage: because we always knew Guido would make the final decision, and that we could always appeal to him when things didn't go the way we like, python-dev has never had to learn to work out disagreements and get along. Now we have to figure that out: the legitimacy of any new governance system is ultimately going to have to rest on the consensus of the core devs. The only way I know to get that is by taking the time to work through the difficult conversations. If these deadlines just encourage people to keep moving and engaging, then that's great. But I worry that if we impose a cut-off like this up front, then we'll take that as an excuse to skip doing that work, because there's no time, and if someone disagrees it's easier to vote than to actually engage and work it out. -n -- Nathaniel J. Smith -- https://vorpus.org ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
Thanks for your action plan, Mariatta, but I'm -1 on having strict timelines for these processes. We need to gradually approach a new model as we've done in the past decades and not push for any possibly borked model right from the start. The processes for this need to stay flexible, easy to adapt and include the possibility for failure. There is no rush for any such model. There is no need to select anyone for life or longer periods: e.g. we may want to change the whole model after 2 years - what are we then going to do with those persons ? We may very well end up not having any kind of governance body initially and use a simple democratic voting scheme for any issues which may arise. FWIW, I don't see anyone in the core development team with the necessary language design skills, vision or intuition to provide an overarching scheme for the future of Python and I don't expect that we'll find such people any time soon. What we do have is a good number of smart people with expert domain knowledge. We should build on those for the time being until we have grown a vision for the future to provide more direction. So let's ponder some more about ideas we could use to get there and perhaps watch some Monty Python movies for inspiration ;-) Cheers, -- Marc-Andre Lemburg On 01.08.2018 21:41, Mariatta Wijaya wrote: > Since this is like a CFP I figured we should clarify what's expected the > proposal, and I also wanted to be more detailed in the timeline. > > *Oct 1 00:00:00 UTC:* Deadline of coming up with proposals of governance > model. > > To be included in the proposal: > - explanation and reasoning of the governance model > - expected roles and responsibilities > - candidate for the role need not be included at this time, since we're > only choosing the governance model. Depending on the governance model > chosen, we might have different people to be nominated. There will be a > separate process for nominating the candidate. > - the term of governance: is it for life? 5 years? 10 years? > > Who can submit the proposal? > Python core developers. Individual core devs can submit a proposal, or > co-author the proposal with another core dev. > > How to submit the proposal? > Proposal should be in a form of a PEP, and merged into peps repo before Oct > 1 00:00:00 UTC. Proposals not merged after Oct 1 00:00:00 UTC will not be > considered. > > *Oct 1 - Nov 15: Review period.* > All core developers will review the PEPs, and ask any questions to the PEP > author. This timeline allows for enough time for all core devs to carefully > review each PEPs, and for authors to respond. > > There will be two parts of this: > > *Review phase 1: Oct 1- Nov 1:* Allow changes and tweaks to the proposed > PEPs. > I figured people will have questions and will need to clarify the PEPs > during this period. But if we want the PEP to be final by Oct 1, that's > fine by me. maybe allow typo fixes still. > > *Review phase 2: Nov 1 00:00:00 UTC*: No more changes to the above PEPs. > No more tweaks to these PEPs. PRs to these PEPs should be rejected. > This is the final chance to carefully review all governance PEPs, and > formulate your decisions. > > *Nov 15 00:00:00 UTC: Voting for new governance model starts, and will go > for 2 weeks* > Send reminders for folks to vote. > > Who can vote: > Only core developers can vote. > > *Vote will be anonymous.* > *We will use the system used to elect PSF board members.* > > > *Dec 1 00:00:00 UTC: Voting ended*. > The most voted proposal will be accepted. > Depending on the chosen governance model, we'll begin nominating candidates > to fill the role(s). > > *Dec 10 00:00:00 UTC Deadline for nominating candidates to fill the role* > Maybe just one PEP to list all the nominations, instead of separate PEPs of > each candidates. > > Who can nominate: Python core developers > Who can be nominated: Python core developers > > *Dec 15 00:00:00 UTC Voting for new successor starts* > (Depends on the governance model chosen on Dec 1) > > *Who can vote:* > *Only core developers can vote.* > > *Vote will be anonymous.* > *We will use the system used to elect PSF board members.* > > *Jan 1 00:00:00 UTC Voting for new successor ends.* Most voted candidate(s) > is chosen. > > The PSF's Code of Conduct applies to all interactions with core devs > regarding this process, including interactions in any mailing lists, zulip, > IRC, twitter, GitHub, backchannels. > > Questions > 1. For the purpose of eligibility (for voting or writing the PEP), who are > considered as "core developers"? Anyone in python-committers? Anyone on > Python Core GitHub team? Anyone with commit bit? What about core developers > of alternate implementation (PyPy, IronPython, etc) > > 2. Are people ok UTC timezone? > > 3. Should this be a PEP? > > Mariatta > > > > ___ > python-committers mailing list > python-committers@python.org >
Re: [python-committers] Reminder of BDFL succession timeline + CFP
Thanks! AoE timezone works for me. In that case, let's use AoE instead of UTC. Mariatta On Wed, Aug 1, 2018 at 1:36 PM Thomas Wouters wrote: > > > On Wed, Aug 1, 2018 at 12:42 PM Mariatta Wijaya > wrote: > >> 2. Are people ok UTC timezone? >> > > FYI, for the PSF elections and similar deadlines, we use the AoE timezone: > https://www.timeanddate.com/time/zones/aoe -- it makes it harder for > people to miss the deadline for timezone reasons. > > -- > Thomas Wouters > > Hi! I'm an email virus! Think twice before sending your email to help me > spread! > ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Wed, Aug 1, 2018 at 12:42 PM Mariatta Wijaya wrote: > 2. Are people ok UTC timezone? > FYI, for the PSF elections and similar deadlines, we use the AoE timezone: https://www.timeanddate.com/time/zones/aoe -- it makes it harder for people to miss the deadline for timezone reasons. -- Thomas Wouters Hi! I'm an email virus! Think twice before sending your email to help me spread! ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Reminder of BDFL succession timeline + CFP
Since this is like a CFP I figured we should clarify what's expected the proposal, and I also wanted to be more detailed in the timeline. *Oct 1 00:00:00 UTC:* Deadline of coming up with proposals of governance model. To be included in the proposal: - explanation and reasoning of the governance model - expected roles and responsibilities - candidate for the role need not be included at this time, since we're only choosing the governance model. Depending on the governance model chosen, we might have different people to be nominated. There will be a separate process for nominating the candidate. - the term of governance: is it for life? 5 years? 10 years? Who can submit the proposal? Python core developers. Individual core devs can submit a proposal, or co-author the proposal with another core dev. How to submit the proposal? Proposal should be in a form of a PEP, and merged into peps repo before Oct 1 00:00:00 UTC. Proposals not merged after Oct 1 00:00:00 UTC will not be considered. *Oct 1 - Nov 15: Review period.* All core developers will review the PEPs, and ask any questions to the PEP author. This timeline allows for enough time for all core devs to carefully review each PEPs, and for authors to respond. There will be two parts of this: *Review phase 1: Oct 1- Nov 1:* Allow changes and tweaks to the proposed PEPs. I figured people will have questions and will need to clarify the PEPs during this period. But if we want the PEP to be final by Oct 1, that's fine by me. maybe allow typo fixes still. *Review phase 2: Nov 1 00:00:00 UTC*: No more changes to the above PEPs. No more tweaks to these PEPs. PRs to these PEPs should be rejected. This is the final chance to carefully review all governance PEPs, and formulate your decisions. *Nov 15 00:00:00 UTC: Voting for new governance model starts, and will go for 2 weeks* Send reminders for folks to vote. Who can vote: Only core developers can vote. *Vote will be anonymous.* *We will use the system used to elect PSF board members.* *Dec 1 00:00:00 UTC: Voting ended*. The most voted proposal will be accepted. Depending on the chosen governance model, we'll begin nominating candidates to fill the role(s). *Dec 10 00:00:00 UTC Deadline for nominating candidates to fill the role* Maybe just one PEP to list all the nominations, instead of separate PEPs of each candidates. Who can nominate: Python core developers Who can be nominated: Python core developers *Dec 15 00:00:00 UTC Voting for new successor starts* (Depends on the governance model chosen on Dec 1) *Who can vote:* *Only core developers can vote.* *Vote will be anonymous.* *We will use the system used to elect PSF board members.* *Jan 1 00:00:00 UTC Voting for new successor ends.* Most voted candidate(s) is chosen. The PSF's Code of Conduct applies to all interactions with core devs regarding this process, including interactions in any mailing lists, zulip, IRC, twitter, GitHub, backchannels. Questions 1. For the purpose of eligibility (for voting or writing the PEP), who are considered as "core developers"? Anyone in python-committers? Anyone on Python Core GitHub team? Anyone with commit bit? What about core developers of alternate implementation (PyPy, IronPython, etc) 2. Are people ok UTC timezone? 3. Should this be a PEP? Mariatta ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
