Re: [python-committers] Transfer of power
Le 17/07/2018 à 04:07, Brett Cannon a écrit : > > This ties into the core dev sponsor idea that got floated where all > inexperienced PEP authors need someone to sign up to shepherd them > through the process. That way everything is more structured and, with > this idea, also more uniform. This sounds like a reasonable policy. We could stipulate that a non-core developer can't get a PEP examined if they didn't go through the shepherding process (which implies there exists a core developer motivated enough to shepherd them, which may help weed out the silliest ideas). Regards Antoine. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Transfer of power
> On 17 Jul 2018, at 02:02, Tim Peters wrote: > > [Tim] >> Guido's most visible (well, to us committers) BDFL role has been in >> "yes/no", "go/nogo" language/library design questions, which don't even >> overlap with the PSF's proper concerns. >> >> But I'm not sure it's fully appreciated just how active Guido has been in >> those at times. The "accepted/rejected" at the end of major PEPs is just a >> small part of that. Along the way, e.g., it's been pretty common to see a >> "Save your breath. That's not going to happen." from Guido to end a >> distracting alternative (sub)proposal persistently promoted by one (or a >> few) very active and/or loquacious posters. > [Jack Jansen] > >> This is a very good point. And it is a role that is not “formally encoded” >> anywhere, and one that I think cannot be formally encoded. >> >> And actually I wonder whether this role could be fulfilled by any >> person/committee/procedure other than Guido himself. Which means that in >> future we should prepare for doing without this role. Which will lead to >> more contentious issues being put in front of the >> whatever-body-replaces-the-bdfl, because the early weeding out isn’t going >> to happen. >> > I'm not quite as hopeless ;-) Most notions on python-ideas are dropped > voluntarily, after it's clear that they generate little interest - or massive > hostility ;-) > > For one that proceeds to a preliminary PEP, I think it would be wise for the > Elders (whatever it's called) to appoint a BDFL-workalike for that specific > PEP. Which may or may not be an Elder. That person would need to commit to > staying current with the PEP's progress, and would have final "yes/no", > "this/that", ... authority on all the design decisions on the way to > polishing the PEP. But not the final accept/reject decision (if the PEP > survives that long). I’m not hopeless either:-) But the point I was trying to make is that Guido has a standing _within the wider community_ that will cause people to sit and ponder his replies, in stead of quickly replying and going into the defensive. The Elders will probably miss that standing in the community at large, at least for the time being. So I think we should prepare for more and longer heated discussions, and make sure that the procedures for the eventual decision are such that people can generally live with the outcome and don’t turn their back on the community. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Transfer of power
Excerpts from Jack Jansen's message of 2018-07-17 11:33:22 +0200: > > > On 17 Jul 2018, at 02:02, Tim Peters wrote: > > > > [Tim] > >> Guido's most visible (well, to us committers) BDFL role has been in > >> "yes/no", "go/nogo" language/library design questions, which don't even > >> overlap with the PSF's proper concerns. > >> > >> But I'm not sure it's fully appreciated just how active Guido has been in > >> those at times. The "accepted/rejected" at the end of major PEPs is just > >> a small part of that. Along the way, e.g., it's been pretty common to see > >> a "Save your breath. That's not going to happen." from Guido to end a > >> distracting alternative (sub)proposal persistently promoted by one (or a > >> few) very active and/or loquacious posters. > > [Jack Jansen] > > > >> This is a very good point. And it is a role that is not “formally encoded” > >> anywhere, and one that I think cannot be formally encoded. > >> > >> And actually I wonder whether this role could be fulfilled by any > >> person/committee/procedure other than Guido himself. Which means that in > >> future we should prepare for doing without this role. Which will lead to > >> more contentious issues being put in front of the > >> whatever-body-replaces-the-bdfl, because the early weeding out isn’t going > >> to happen. > >> > > I'm not quite as hopeless ;-) Most notions on python-ideas are dropped > > voluntarily, after it's clear that they generate little interest - or > > massive hostility ;-) > > > > For one that proceeds to a preliminary PEP, I think it would be wise for > > the Elders (whatever it's called) to appoint a BDFL-workalike for that > > specific PEP. Which may or may not be an Elder. That person would need to > > commit to staying current with the PEP's progress, and would have final > > "yes/no", "this/that", ... authority on all the design decisions on the > > way to polishing the PEP. But not the final accept/reject decision (if the > > PEP survives that long). > > I’m not hopeless either:-) > > But the point I was trying to make is that Guido has a standing _within the > wider community_ that will cause people to sit and ponder his replies, in > stead of quickly replying and going into the defensive. The Elders will > probably miss that standing in the community at large, at least for the time > being. So I think we should prepare for more and longer heated discussions, > and make sure that the procedures for the eventual decision are such that > people can generally live with the outcome and don’t turn their back on the > community. I agree that having a consensus-based process that everyone agrees to use and abide by is important. Perhaps we can also take change the process to start eliminating the culture that leads to so much heat in the first place. Healthy debate is all well and good, but it seems like we've had a couple of examples of things getting out of hand recently. Doug ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] An alternative governance model
I’d like to propose an alternative model, and with it a succession plan, that IMHO hasn’t gotten enough discussion. It’s fairly radical in that it proposes to not actually change that much! TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that helps the BDFL in various capacities, with additional responsibilities. I also have someone specific in mind for the NBDFL, but you’ll have to read on for the big reveal. Why keep a singular BDFL? I think it’s clear that no one can completely replace Guido, and neither should we try, nor do we need to. The discussion to date has explored refactoring many of the roles that the BDFL has, and that’s all excellent, especially to reduce the burden and burnout factor of the NBDFL. But I think having a singular BDFL making the tough decisions, with the support and help of the community, is in the best interests of Python over the long term. A singular BDFL provides clear leadership. With a council of elders, it will be more difficult to communicate both to the Python community, and to the larger, more peripheral user base, that any particular individual has the authority to make decisions. Regardless of size, there would ultimately be some one person communicating any council decision. There will inevitably be ambiguity as to the authority of said decision. How will folks, especially on the periphery, know that Alice Jones or Bob Smith are members of the council and can speak authoritatively on decisions for the language? “Bob Smith, on Behalf of the GUIDO” is IMHO less obviously and unquestionably authoritative than “Alice Jones, BDFL”. This also comes into play for shutting down discussions early. With a committee, it’s possible that you’ll have some disagreement among the members as to whether a discussion is fruitful or not, whether it rehashes settled questions, or whether the change fits into the overall direction for Python’s evolution. Alice Jones may say “No, that’s not gonna happen” only to be overruled or undermined by Bob Smith’s “That’s a good idea”. Taken together, these fall under the umbrella of having one voice for the decision making process. It may be possible for consensus within the council to come across as a single voice, but I think it will generally be harder. A council also opens the door for more back-channel lobbying of a sympathetic member. Yes, such lobbying is possible with a BDFL, but at least there should be less contention. I also think a council will be much more risk adverse than a singular BDFL, and that’s not necessarily a good thing. While moratoriums and a more conservative approach to change may be appropriate at times, I would prefer those to be deliberate decisions for a specific purpose, rather than the unintended outcome of groupthink or lack of consensus. A singular BDFL with support from the community will have more authority to make decisions which probably will never be universally accepted, and much less prone to vapor lock due to lack of consensus or internal bickering. I hope Guido won’t mind me relating a comment of his that has really resonated with me over the last few days, and for which I think a singular BDFL will be much more adept at communicating and shepherding. The question for any new leader is: What is your vision for Python? This question keeps coming to mind as I think about how the evolution of the language will be governed over the next few years or decades. Yes, Python is a mature language, but it’s far from stagnant. Guido always had a very clear vision of what Python should be, where it should go, and how new proposed features (or other changes to the Python ecosystem) fit into that vision, even if he didn’t or couldn’t always clearly articulate them. The NBDFL will necessarily have a different vision than Guido, and I think even he would agree that that’s okay! A strong vision is better than no vision. Python must continue to grow and evolve if it is to stay relevant in a rapidly change technology environment. As an almost 30 year old language, Python is already facing challenges; how will that vision address those challenges, even if to explicitly choose the status quo? Will a council be able to articular, express, communicate, adapt, and follow through on that vision? Will a council be able to evaluate a proposed change as it supports or detracts from that vision? Will a council be able to break out of a primarily maintenance position, to actually move the language and its primary implementation forward? I’m not so sure. For these reasons I propose that we retain a singular BDFL. The formation of a formal Council is still a good idea! I just think that it shouldn’t be the ultimate arbiter of decisions for Python. So what would the Council do? - It would serve as a check on the BDFL. If Bob Smith were one day employed by Evil Corp. and started making decisions that were directl
Re: [python-committers] An alternative governance model
On 7/17/2018 10:02 PM, Barry Warsaw wrote: I’d like to propose an alternative model, and with it a succession plan, that IMHO hasn’t gotten enough discussion. It’s fairly radical in that it proposes to not actually change that much! TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that helps the BDFL in various capacities, with additional responsibilities. I also have someone specific in mind for the NBDFL, but you’ll have to read on for the big reveal. I've come to this same conclusion. I think Brett would be a good choice, and I'd support him, but I think the more important part is that it be a single person. And I think the succession plan is important, too. I think Łukasz was alluding to this earlier (or maybe I'm projecting): who's to say that the next BDFL is legitimate? If we put together a plan, and Guido blesses it, that makes the plan legitimate, and then the plan gets executed and makes NBDFL legitimate. Eric Why keep a singular BDFL? I think it’s clear that no one can completely replace Guido, and neither should we try, nor do we need to. The discussion to date has explored refactoring many of the roles that the BDFL has, and that’s all excellent, especially to reduce the burden and burnout factor of the NBDFL. But I think having a singular BDFL making the tough decisions, with the support and help of the community, is in the best interests of Python over the long term. A singular BDFL provides clear leadership. With a council of elders, it will be more difficult to communicate both to the Python community, and to the larger, more peripheral user base, that any particular individual has the authority to make decisions. Regardless of size, there would ultimately be some one person communicating any council decision. There will inevitably be ambiguity as to the authority of said decision. How will folks, especially on the periphery, know that Alice Jones or Bob Smith are members of the council and can speak authoritatively on decisions for the language? “Bob Smith, on Behalf of the GUIDO” is IMHO less obviously and unquestionably authoritative than “Alice Jones, BDFL”. This also comes into play for shutting down discussions early. With a committee, it’s possible that you’ll have some disagreement among the members as to whether a discussion is fruitful or not, whether it rehashes settled questions, or whether the change fits into the overall direction for Python’s evolution. Alice Jones may say “No, that’s not gonna happen” only to be overruled or undermined by Bob Smith’s “That’s a good idea”. Taken together, these fall under the umbrella of having one voice for the decision making process. It may be possible for consensus within the council to come across as a single voice, but I think it will generally be harder. A council also opens the door for more back-channel lobbying of a sympathetic member. Yes, such lobbying is possible with a BDFL, but at least there should be less contention. I also think a council will be much more risk adverse than a singular BDFL, and that’s not necessarily a good thing. While moratoriums and a more conservative approach to change may be appropriate at times, I would prefer those to be deliberate decisions for a specific purpose, rather than the unintended outcome of groupthink or lack of consensus. A singular BDFL with support from the community will have more authority to make decisions which probably will never be universally accepted, and much less prone to vapor lock due to lack of consensus or internal bickering. I hope Guido won’t mind me relating a comment of his that has really resonated with me over the last few days, and for which I think a singular BDFL will be much more adept at communicating and shepherding. The question for any new leader is: What is your vision for Python? This question keeps coming to mind as I think about how the evolution of the language will be governed over the next few years or decades. Yes, Python is a mature language, but it’s far from stagnant. Guido always had a very clear vision of what Python should be, where it should go, and how new proposed features (or other changes to the Python ecosystem) fit into that vision, even if he didn’t or couldn’t always clearly articulate them. The NBDFL will necessarily have a different vision than Guido, and I think even he would agree that that’s okay! A strong vision is better than no vision. Python must continue to grow and evolve if it is to stay relevant in a rapidly change technology environment. As an almost 30 year old language, Python is already facing challenges; how will that vision address those challenges, even if to explicitly choose the status quo? Will a council be able to articular, express, communicate, adapt, and follow through on that vision? Will a council be able to evaluate a proposed change as it supports or detracts from that vision?
Re: [python-committers] An alternative governance model
On Jul 17, 2018, at 22:15, Eric V. Smith wrote: > On 7/17/2018 10:02 PM, Barry Warsaw wrote: >> I’d like to propose an alternative model, and with it a succession plan, >> that IMHO hasn’t gotten enough discussion. It’s fairly radical in that it >> proposes to not actually change that much! >> TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors >> that helps the BDFL in various capacities, with additional responsibilities. >> I also have someone specific in mind for the NBDFL, but you’ll have to read >> on for the big reveal. > I've come to this same conclusion. I think Brett would be a good choice, and > I'd support him, but I think the more important part is that it be a single > person. +100. I think Python owes much of its success to both Guido's ongoing vision *and* his clear role as leader. Up to now, we have not had much experience governing by committee or council and I think it may be a mistake to try to implement that now (although we *do* have some successful experience with informal council of advisors models, for instance, in the release management area). While it wouldn't necessarily be a good choice for many (most?) open-source projects, I think the NBDFL-plus-advisors model would work well in the relatively congenial and respectful environment of the current Python committers community. That's not to say that we won't collectively decide down the road that we want to try something different but trying to keep this really important transition (i.e. from Guido) as simple as possible initially would be a really smart thing to do. > And I think the succession plan is important, too. I think Łukasz was > alluding to this earlier (or maybe I'm projecting): who's to say that the > next BDFL is legitimate? If we put together a plan, and Guido blesses it, > that makes the plan legitimate, and then the plan gets executed and makes > NBDFL legitimate. That, too. -- Ned Deily [email protected] -- [] ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] An alternative governance model
I wholeheartedly agree with Barry's suggestion. It offers a single person who can communicate the design vision. While the support of a council will help spread out the work and provides a great way to grow future leaders and a smooth transition if for any reason (family, work, health, etc.) the new BDFL has to take a break. On Tue, Jul 17, 2018, 7:38 PM Ned Deily wrote: > On Jul 17, 2018, at 22:15, Eric V. Smith wrote: > > On 7/17/2018 10:02 PM, Barry Warsaw wrote: > >> I’d like to propose an alternative model, and with it a succession > plan, that IMHO hasn’t gotten enough discussion. It’s fairly radical in > that it proposes to not actually change that much! > >> TL;DR: I propose keeping a singular BDFL and adding a Council of > Advisors that helps the BDFL in various capacities, with additional > responsibilities. I also have someone specific in mind for the NBDFL, but > you’ll have to read on for the big reveal. > > I've come to this same conclusion. I think Brett would be a good choice, > and I'd support him, but I think the more important part is that it be a > single person. > > +100. I think Python owes much of its success to both Guido's ongoing > vision *and* his clear role as leader. Up to now, we have not had much > experience governing by committee or council and I think it may be a > mistake to try to implement that now (although we *do* have some successful > experience with informal council of advisors models, for instance, in the > release management area). While it wouldn't necessarily be a good choice > for many (most?) open-source projects, I think the NBDFL-plus-advisors > model would work well in the relatively congenial and respectful > environment of the current Python committers community. That's not to say > that we won't collectively decide down the road that we want to try > something different but trying to keep this really important transition > (i.e. from Guido) as simple as possible initially would be a really smart > thing to do. > > > And I think the succession plan is important, too. I think Łukasz was > alluding to this earlier (or maybe I'm projecting): who's to say that the > next BDFL is legitimate? If we put together a plan, and Guido blesses it, > that makes the plan legitimate, and then the plan gets executed and makes > NBDFL legitimate. > > That, too. > > -- > Ned Deily > [email protected] -- [] > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] An alternative governance model
Barry, you offer truly compelling arguments for a new BDFL as GvR's successor -- FWIW, you've convinced me. And Brett would be an absolutely outstanding pick as that "new BDFL" -- on this, I need no convincing. Alex On Tue, Jul 17, 2018 at 7:08 PM Barry Warsaw wrote: > I’d like to propose an alternative model, and with it a succession plan, > that IMHO hasn’t gotten enough discussion. It’s fairly radical in that it > proposes to not actually change that much! > > TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors > that helps the BDFL in various capacities, with additional > responsibilities. I also have someone specific in mind for the NBDFL, but > you’ll have to read on for the big reveal. > > Why keep a singular BDFL? I think it’s clear that no one can completely > replace Guido, and neither should we try, nor do we need to. The > discussion to date has explored refactoring many of the roles that the BDFL > has, and that’s all excellent, especially to reduce the burden and burnout > factor of the NBDFL. But I think having a singular BDFL making the tough > decisions, with the support and help of the community, is in the best > interests of Python over the long term. > > A singular BDFL provides clear leadership. With a council of elders, it > will be more difficult to communicate both to the Python community, and to > the larger, more peripheral user base, that any particular individual has > the authority to make decisions. Regardless of size, there would > ultimately be some one person communicating any council decision. There > will inevitably be ambiguity as to the authority of said decision. How > will folks, especially on the periphery, know that Alice Jones or Bob Smith > are members of the council and can speak authoritatively on decisions for > the language? “Bob Smith, on Behalf of the GUIDO” is IMHO less obviously > and unquestionably authoritative than “Alice Jones, BDFL”. > > This also comes into play for shutting down discussions early. With a > committee, it’s possible that you’ll have some disagreement among the > members as to whether a discussion is fruitful or not, whether it rehashes > settled questions, or whether the change fits into the overall direction > for Python’s evolution. Alice Jones may say “No, that’s not gonna happen” > only to be overruled or undermined by Bob Smith’s “That’s a good idea”. > > Taken together, these fall under the umbrella of having one voice for the > decision making process. It may be possible for consensus within the > council to come across as a single voice, but I think it will generally be > harder. A council also opens the door for more back-channel lobbying of a > sympathetic member. Yes, such lobbying is possible with a BDFL, but at > least there should be less contention. > > I also think a council will be much more risk adverse than a singular > BDFL, and that’s not necessarily a good thing. While moratoriums and a > more conservative approach to change may be appropriate at times, I would > prefer those to be deliberate decisions for a specific purpose, rather than > the unintended outcome of groupthink or lack of consensus. A singular BDFL > with support from the community will have more authority to make decisions > which probably will never be universally accepted, and much less prone to > vapor lock due to lack of consensus or internal bickering. > > I hope Guido won’t mind me relating a comment of his that has really > resonated with me over the last few days, and for which I think a singular > BDFL will be much more adept at communicating and shepherding. The > question for any new leader is: > > What is your vision for Python? > > This question keeps coming to mind as I think about how the evolution of > the language will be governed over the next few years or decades. Yes, > Python is a mature language, but it’s far from stagnant. Guido always had > a very clear vision of what Python should be, where it should go, and how > new proposed features (or other changes to the Python ecosystem) fit into > that vision, even if he didn’t or couldn’t always clearly articulate them. > The NBDFL will necessarily have a different vision than Guido, and I think > even he would agree that that’s okay! A strong vision is better than no > vision. Python must continue to grow and evolve if it is to stay relevant > in a rapidly change technology environment. As an almost 30 year old > language, Python is already facing challenges; how will that vision address > those challenges, even if to explicitly choose the status quo? > > Will a council be able to articular, express, communicate, adapt, and > follow through on that vision? Will a council be able to evaluate a > proposed change as it supports or detracts from that vision? Will a > council be able to break out of a primarily maintenance position, to > actually move the language and its primary implementation forward? I’m not > so sure. > > For t
Re: [python-committers] An alternative governance model
I apologize if this has already been mentioned on a different thread, but something else I like about the BDFL model is that it avoids "design by committee." I think Python owes a lot of its success to its coherence as a language, which is in large part due to Guido's vision, as well as making the hard decisions along the way. Of course, it will be hard to fill his shoes, but fortunately we have many good people to choose from. The BDFL is in some ways the human embodiment of the Zen of Python, in that they're the last line of defense to ensure Python remains true to its Zen. --Chris On Tue, Jul 17, 2018 at 8:33 PM, Alex Martelli via python-committers wrote: > Barry, you offer truly compelling arguments for a new BDFL as GvR's > successor -- FWIW, you've convinced me. > > And Brett would be an absolutely outstanding pick as that "new BDFL" -- on > this, I need no convincing. > > > Alex > > On Tue, Jul 17, 2018 at 7:08 PM Barry Warsaw wrote: >> >> I’d like to propose an alternative model, and with it a succession plan, >> that IMHO hasn’t gotten enough discussion. It’s fairly radical in that it >> proposes to not actually change that much! >> >> TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors >> that helps the BDFL in various capacities, with additional responsibilities. >> I also have someone specific in mind for the NBDFL, but you’ll have to read >> on for the big reveal. >> >> Why keep a singular BDFL? I think it’s clear that no one can completely >> replace Guido, and neither should we try, nor do we need to. The discussion >> to date has explored refactoring many of the roles that the BDFL has, and >> that’s all excellent, especially to reduce the burden and burnout factor of >> the NBDFL. But I think having a singular BDFL making the tough decisions, >> with the support and help of the community, is in the best interests of >> Python over the long term. >> >> A singular BDFL provides clear leadership. With a council of elders, it >> will be more difficult to communicate both to the Python community, and to >> the larger, more peripheral user base, that any particular individual has >> the authority to make decisions. Regardless of size, there would ultimately >> be some one person communicating any council decision. There will >> inevitably be ambiguity as to the authority of said decision. How will >> folks, especially on the periphery, know that Alice Jones or Bob Smith are >> members of the council and can speak authoritatively on decisions for the >> language? “Bob Smith, on Behalf of the GUIDO” is IMHO less obviously and >> unquestionably authoritative than “Alice Jones, BDFL”. >> >> This also comes into play for shutting down discussions early. With a >> committee, it’s possible that you’ll have some disagreement among the >> members as to whether a discussion is fruitful or not, whether it rehashes >> settled questions, or whether the change fits into the overall direction for >> Python’s evolution. Alice Jones may say “No, that’s not gonna happen” only >> to be overruled or undermined by Bob Smith’s “That’s a good idea”. >> >> Taken together, these fall under the umbrella of having one voice for the >> decision making process. It may be possible for consensus within the >> council to come across as a single voice, but I think it will generally be >> harder. A council also opens the door for more back-channel lobbying of a >> sympathetic member. Yes, such lobbying is possible with a BDFL, but at >> least there should be less contention. >> >> I also think a council will be much more risk adverse than a singular >> BDFL, and that’s not necessarily a good thing. While moratoriums and a more >> conservative approach to change may be appropriate at times, I would prefer >> those to be deliberate decisions for a specific purpose, rather than the >> unintended outcome of groupthink or lack of consensus. A singular BDFL with >> support from the community will have more authority to make decisions which >> probably will never be universally accepted, and much less prone to vapor >> lock due to lack of consensus or internal bickering. >> >> I hope Guido won’t mind me relating a comment of his that has really >> resonated with me over the last few days, and for which I think a singular >> BDFL will be much more adept at communicating and shepherding. The question >> for any new leader is: >> >> What is your vision for Python? >> >> This question keeps coming to mind as I think about how the evolution of >> the language will be governed over the next few years or decades. Yes, >> Python is a mature language, but it’s far from stagnant. Guido always had a >> very clear vision of what Python should be, where it should go, and how new >> proposed features (or other changes to the Python ecosystem) fit into that >> vision, even if he didn’t or couldn’t always clearly articulate them. The >> NBDFL will necessarily have a different vision than Guido, and I th
Re: [python-committers] An alternative governance model
On Tue, Jul 17, 2018 at 7:02 PM, Barry Warsaw wrote: > > If you’ve read this far - thank you! Now for the big reveal. I think the > Next BDFL should be… (drum roll)… > > Brett Cannon > > To summarize: > > * We retain a singular BDFL to lead Python > * A Council is selected to serve as advisors to the BDFL, a selection > committee for succession, and a check against the BDFL. > I will register my +1 to this suggestion, and +1 to Brett's name. a) A singular vision is highly beneficial. Personally, just as a nitpick, I'd like to reserve the term BDFL to Guido, and choose a different term to signify the ultimate authority of the new leader. b) Yes, council and its resposibilities sounds a good new idea. > No one will serve forever, so a clear succession plan should be in place. I support this idea too, and the details should be well defined. Thank you, Senthil ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] An alternative governance model
[Barry Warsaw] > ... > * We retain a singular BDFL to lead Python > * A Council is selected to serve as advisors to the BDFL, a selection > committee for succession, and a check against the BDFL. > You made a fine case for that a single dictator is the best possible approach, for much the same reasons Emacs is the best possible editor. +1 Brett Cannon Not my first choice, but ... yup, I got the email back. Kim Jong Un is too busy providing field guidance to potato farms and trolley manufacturers this year :-( So that leaves Brett! However, to secure my full enthusiastic support he'll first need to pledge to make porting Python to Red Star OS[1] his #1 BDFL priority. Since a committee or a (ugh!) democracy would never do that, it would prove he has the pigheadedness required to be an effective dictator ;-) [1] https://en.wikipedia.org/wiki/Red_Star_OS ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] An alternative governance model
On Wed, Jul 18, 2018 at 11:17 AM Tim Peters wrote: > > > [Barry Warsaw] >> >> ... >> >> * We retain a singular BDFL to lead Python >> * A Council is selected to serve as advisors to the BDFL, a selection >> committee for succession, and a check against the BDFL. > > +1 to this idea including Brett as BDFL. Though I am wondering if anyone asked Brett about it? > You made a fine case for that a single dictator is the best possible > approach, for much the same reasons Emacs is the best possible editor. +1 > >> Brett Cannon > > > Not my first choice, but ... yup, I got the email back. Kim Jong Un is too > busy providing field guidance to potato farms and trolley manufacturers this > year :-( > > So that leaves Brett! However, to secure my full enthusiastic support he'll > first need to pledge to make porting Python to Red Star OS[1] his #1 BDFL > priority. Since a committee or a (ugh!) democracy would never do that, it > would prove he has the pigheadedness required to be an effective dictator ;-) > Red Star OS has Python in it iirc :) Means less work for Brett. Kushal -- Staff, Freedom of the Press Foundation CPython Core Developer Director, Python Software Foundation https://kushaldas.in ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] An alternative governance model
I agree a name other than BDFL should be chosen, especially since (as I understand it) Guido is still BDFL but just taking a permanent vacation, and the name implies there should only be one. Also, if we're considering particular people, I think Nick should also be considered. Should the position be decided before starting to decide who should fill it, though, or should it be decided with a particular person in mind? I feel like doing the former might be better, because that way we can also come up with the process for choosing the person, which we'll need at some point anyways. --Chris On Tue, Jul 17, 2018 at 10:55 PM, Kushal Das wrote: > On Wed, Jul 18, 2018 at 11:17 AM Tim Peters wrote: >> >> >> [Barry Warsaw] >>> >>> ... >>> >>> * We retain a singular BDFL to lead Python >>> * A Council is selected to serve as advisors to the BDFL, a selection >>> committee for succession, and a check against the BDFL. >> >> > +1 to this idea including Brett as BDFL. Though I am wondering if > anyone asked Brett about it? > >> You made a fine case for that a single dictator is the best possible >> approach, for much the same reasons Emacs is the best possible editor. +1 >> >>> Brett Cannon >> >> >> Not my first choice, but ... yup, I got the email back. Kim Jong Un is too >> busy providing field guidance to potato farms and trolley manufacturers this >> year :-( >> >> So that leaves Brett! However, to secure my full enthusiastic support he'll >> first need to pledge to make porting Python to Red Star OS[1] his #1 BDFL >> priority. Since a committee or a (ugh!) democracy would never do that, it >> would prove he has the pigheadedness required to be an effective dictator ;-) >> > > Red Star OS has Python in it iirc :) Means less work for Brett. > > > Kushal > -- > Staff, Freedom of the Press Foundation > CPython Core Developer > Director, Python Software Foundation > https://kushaldas.in > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
