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 directly detrimental to Python, the council should be able to effectively impeach. There should be checks and balances on this power, the BDFL shouldn’t continuously fear a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for when the BDFL is abusing their power.
The council would select the next BDFL if and when that time comes. No one will serve forever, so a clear succession plan should be in place. To avoid the tyranny of the majority, the council would serve similarly to a board of directors. They’d search for candidates, match them against well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL.
The council would serve as trusted advisors to the NBDFL. The BDFL won’t be out there all alone! The council will provide advice when requested, and back up the BDFL when needed. The council helps legitimize the BDFL and their decisions.
We can debate how the initial council is selected, its make up, number of members, term limits, etc. I think much of the current discussion about a BDFL-like council would satisfy the requirements for a Council of Advisors. It’s just that the roles and responsibilities would differ. The COA wouldn’t make the decisions, but it would help the BDFL make the best decisions possible, and have their back against any detractors.
I definitely have my own thoughts on an initial make-up of said council, but I’ll reserve that for later.
If you’ve read this far - thank you! Now for the big reveal. I think the Next BDFL should be… (drum roll)…
Brett Cannon
I’ve long said — somewhat in jest, since I never expected Guido to actually ever retire! — that Brett would be my choice for the next BDFL. I think he’s the perfect candidate, and he’s already demonstrated qualities that I think make him a fantastic leader. He’s smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills. He believes deeply in diversity and community. As he’s shown with the decisions to move first to Mercurial, then to git/GitLab, he isn't afraid to make difficult decisions that he knows not everyone will agree with (and I say that having advocated the losing choice more than once :). He’s not afraid to say what’s on his mind. I think he can clearly articulate a Vision. He shares many of these same qualities with Guido, while being a different person with different sensibilities. And that is not only fine, but IMHO a *good* thing. We can trust his stewardship, and he already has legitimacy as a senior decision maker in the Python ecosystem. He has a wide technical knowledge of Python and its C implementation, and yet he knows what he doesn’t know. He has good relationships with most core devs, and is a well-known voice within the wider community. He’ll be able to delegate where appropriate, and make definitive pronouncements where needed.
Before you ask, yes I did check with Brett before making this proposal and he didn’t shoot it down. He may have specific requirements for accepting the position, but I’ll let him articulate those. I’m confident they would come across as completely reasonable. :)
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.
That’s it in a nutshell. Thanks for listening.
Cheers, -Barry
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? 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 directly detrimental to Python, the council should be able to effectively impeach. There should be checks and balances on this power, the BDFL shouldn’t continuously fear a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for when the BDFL is abusing their power.
The council would select the next BDFL if and when that time comes. No one will serve forever, so a clear succession plan should be in place. To avoid the tyranny of the majority, the council would serve similarly to a board of directors. They’d search for candidates, match them against well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL.
The council would serve as trusted advisors to the NBDFL. The BDFL won’t be out there all alone! The council will provide advice when requested, and back up the BDFL when needed. The council helps legitimize the BDFL and their decisions.
We can debate how the initial council is selected, its make up, number of members, term limits, etc. I think much of the current discussion about a BDFL-like council would satisfy the requirements for a Council of Advisors. It’s just that the roles and responsibilities would differ. The COA wouldn’t make the decisions, but it would help the BDFL make the best decisions possible, and have their back against any detractors.
I definitely have my own thoughts on an initial make-up of said council, but I’ll reserve that for later.
If you’ve read this far - thank you! Now for the big reveal. I think the Next BDFL should be… (drum roll)…
Brett Cannon
I’ve long said — somewhat in jest, since I never expected Guido to actually ever retire! — that Brett would be my choice for the next BDFL. I think he’s the perfect candidate, and he’s already demonstrated qualities that I think make him a fantastic leader. He’s smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills. He believes deeply in diversity and community. As he’s shown with the decisions to move first to Mercurial, then to git/GitLab, he isn't afraid to make difficult decisions that he knows not everyone will agree with (and I say that having advocated the losing choice more than once :). He’s not afraid to say what’s on his mind. I think he can clearly articulate a Vision. He shares many of these same qualities with Guido, while being a different person with different sensibilities. And that is not only fine, but IMHO a *good* thing. We can trust his stewardship, and he already has legitimacy as a senior decision maker in the Python ecosystem. He has a wide technical knowledge of Python and its C implementation, and yet he knows what he doesn’t know. He has good relationships with most core devs, and is a well-known voice within the wider community. He’ll be able to delegate where appropriate, and make definitive pronouncements where needed.
Before you ask, yes I did check with Brett before making this proposal and he didn’t shoot it down. He may have specific requirements for accepting the position, but I’ll let him articulate those. I’m confident they would come across as completely reasonable. :)
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.
That’s it in a nutshell. Thanks for listening.
Cheers, -Barry
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/
On Jul 17, 2018, at 22:15, Eric V. Smith <eric@trueblade.com> 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 nad@python.org -- []
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 <nad@python.org> wrote:
On 7/17/2018 10:02 PM, Barry Warsaw wrote:
I’d like to propose an alternative model, and with it a succession
On Jul 17, 2018, at 22:15, Eric V. Smith <eric@trueblade.com> wrote: 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 nad@python.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/
I also agree 100% with Barry's proposal. I think he's absolutely right that one of the important features of Python (both the language and the community) is the single focus and vision of the BDFL, and reading Barry's mail crystallised for me the unease I felt about the proposals around a Council, which is precisely that they wouldn't provide that unified vision. Having a council acting as support for the NBDFL gives the best of both worlds.
Strong +1 all round.
I too would love to hear Brett's thoughts, but he definitely has my support if he feels able to take on the role.
Paul
On 18 July 2018 at 04:20, Carol Willing <willingc@gmail.com> wrote:
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 <nad@python.org> wrote:
On Jul 17, 2018, at 22:15, Eric V. Smith <eric@trueblade.com> 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 nad@python.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/
On Tue, Jul 17, 2018 at 8:15 PM Eric V. Smith <eric@trueblade.com> 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.
+1
IMHO, if we can have someone we can trust then a BDFL is the best option. Brett definitely fits that criteria for me. (Plus Canadians are "Benevolent" by definition, right?) Barry's proposal to have the council supporting (and guarding against) the BDFL gives the proposal better stability in the face of the unknown future.
-eric
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 <barry@python.org> 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 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 directly detrimental to Python, the council should be able to effectively impeach. There should be checks and balances on this power, the BDFL shouldn’t continuously fear a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for when the BDFL is abusing their power.
The council would select the next BDFL if and when that time comes. No one will serve forever, so a clear succession plan should be in place. To avoid the tyranny of the majority, the council would serve similarly to a board of directors. They’d search for candidates, match them against well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL.
The council would serve as trusted advisors to the NBDFL. The BDFL won’t be out there all alone! The council will provide advice when requested, and back up the BDFL when needed. The council helps legitimize the BDFL and their decisions.
We can debate how the initial council is selected, its make up, number of members, term limits, etc. I think much of the current discussion about a BDFL-like council would satisfy the requirements for a Council of Advisors. It’s just that the roles and responsibilities would differ. The COA wouldn’t make the decisions, but it would help the BDFL make the best decisions possible, and have their back against any detractors.
I definitely have my own thoughts on an initial make-up of said council, but I’ll reserve that for later.
If you’ve read this far - thank you! Now for the big reveal. I think the Next BDFL should be… (drum roll)…
Brett Cannon
I’ve long said — somewhat in jest, since I never expected Guido to actually ever retire! — that Brett would be my choice for the next BDFL. I think he’s the perfect candidate, and he’s already demonstrated qualities that I think make him a fantastic leader. He’s smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills. He believes deeply in diversity and community. As he’s shown with the decisions to move first to Mercurial, then to git/GitLab, he isn't afraid to make difficult decisions that he knows not everyone will agree with (and I say that having advocated the losing choice more than once :). He’s not afraid to say what’s on his mind. I think he can clearly articulate a Vision. He shares many of these same qualities with Guido, while being a different person with different sensibilities. And that is not only fine, but IMHO a *good* thing. We can trust his stewardship, and he already has legitimacy as a senior decision maker in the Python ecosystem. He has a wide technical knowledge of Python and its C implementation, and yet he knows what he doesn’t know. He has good relationships with most core devs, and is a well-known voice within the wider community. He’ll be able to delegate where appropriate, and make definitive pronouncements where needed.
Before you ask, yes I did check with Brett before making this proposal and he didn’t shoot it down. He may have specific requirements for accepting the position, but I’ll let him articulate those. I’m confident they would come across as completely reasonable. :)
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.
That’s it in a nutshell. Thanks for listening.
Cheers, -Barry
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/
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 <python-committers@python.org> 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 <barry@python.org> 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 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 directly detrimental to Python, the council should be able to effectively impeach. There should be checks and balances on this power, the BDFL shouldn’t continuously fear a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for when the BDFL is abusing their power.
The council would select the next BDFL if and when that time comes. No one will serve forever, so a clear succession plan should be in place. To avoid the tyranny of the majority, the council would serve similarly to a board of directors. They’d search for candidates, match them against well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL.
The council would serve as trusted advisors to the NBDFL. The BDFL won’t be out there all alone! The council will provide advice when requested, and back up the BDFL when needed. The council helps legitimize the BDFL and their decisions.
We can debate how the initial council is selected, its make up, number of members, term limits, etc. I think much of the current discussion about a BDFL-like council would satisfy the requirements for a Council of Advisors. It’s just that the roles and responsibilities would differ. The COA wouldn’t make the decisions, but it would help the BDFL make the best decisions possible, and have their back against any detractors.
I definitely have my own thoughts on an initial make-up of said council, but I’ll reserve that for later.
If you’ve read this far - thank you! Now for the big reveal. I think the Next BDFL should be… (drum roll)…
Brett Cannon
I’ve long said — somewhat in jest, since I never expected Guido to actually ever retire! — that Brett would be my choice for the next BDFL. I think he’s the perfect candidate, and he’s already demonstrated qualities that I think make him a fantastic leader. He’s smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills. He believes deeply in diversity and community. As he’s shown with the decisions to move first to Mercurial, then to git/GitLab, he isn't afraid to make difficult decisions that he knows not everyone will agree with (and I say that having advocated the losing choice more than once :). He’s not afraid to say what’s on his mind. I think he can clearly articulate a Vision. He shares many of these same qualities with Guido, while being a different person with different sensibilities. And that is not only fine, but IMHO a *good* thing. We can trust his stewardship, and he already has legitimacy as a senior decision maker in the Python ecosystem. He has a wide technical knowledge of Python and its C implementation, and yet he knows what he doesn’t know. He has good relationships with most core devs, and is a well-known voice within the wider community. He’ll be able to delegate where appropriate, and make definitive pronouncements where needed.
Before you ask, yes I did check with Brett before making this proposal and he didn’t shoot it down. He may have specific requirements for accepting the position, but I’ll let him articulate those. I’m confident they would come across as completely reasonable. :)
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.
That’s it in a nutshell. Thanks for listening.
Cheers, -Barry
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/
On Tue, Jul 17, 2018 at 7:02 PM, Barry Warsaw <barry@python.org> 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
[Senthil Kumaran <senthil@uthcode.com>]
...
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.
Finally - an important issue ;-)
I submit instead that Monty Python would _certainly_ have kept the BDFL title. The irony of having at least two living BDFLs is just too exquisite to resist :-)
But we can learn from other dictatorships too. For example, one of Kim Il Sung's many titles was "President". It was important for his son to get fancy titles too when he took over, so he was also called "President". And it was Kim Il Sung's title that changed, to "Eternal President". That gave him even more prestige.
If there can be only one BDFL, then Guido's title should change to EBDFL. On his resume he can explain that means "Emeritus BDFL", but we'll all know it means "Eternal BDFL" :-)
[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 ;-)
On Wed, Jul 18, 2018 at 11:17 AM Tim Peters <tim.peters@gmail.com> 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
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 <kushaldas@gmail.com> wrote:
On Wed, Jul 18, 2018 at 11:17 AM Tim Peters <tim.peters@gmail.com> 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 python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On 18 July 2018 at 16:42, Chris Jerdonek <chris.jerdonek@gmail.com> wrote:
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.
As much as I appreciate the vote of confidence, I'm actively working to reduce my open source commitments and responsibilities at the moment, not increase them. Burnout's a thing, y'all, especially when you have the attention span of a caffeinated squirrel and get involved in far more things than you could ever hope to see through to completion in a reasonable period of time :)
And that's my primary concern with any proposals to put a comparable level of stress to that which Guido has been handling for years on to another volunteer's shoulders: I don't think it's an even remotely reasonable thing to request of a community volunteer.
Guido was willing to do it for so long because Python was his creation, and he grew into the increasing demands of the BDFL role as time went by, but even he eventually reached the point of saying "I don't want to do this any more - the personal costs are outweighing the personal benefits". There's no way that a new individual in a comparable role to Guido's is going to have an easier time of it than Guido did, and a lot of good reasons to believe that they will find it significantly harder (not least of which is that Guido has been able to request 50% funded "BDFL-time" from his employers since he joined Google in 2005, and it's unlikely that a newcomer to the role would enjoy that benefit any time soon).
In the 2 terms I spent on the PSF board, one of the things I aimed to help Ewa work towards was making being on the Board less of a recipe for burnout, and I've done what I could to help make working on the Python packaging ecosystem less of a burnout factory as well. Before my time on the Board, other folks had already started the process of having paid PSF staff take on more PyCon US management responsibilities to help reduce the burden on folks volunteering for PyCon US leadership roles.
In that context, setting up a high profile volunteer leadership role that I'd expect to mainly let us burn out multiple people in succession really doesn't seem like a good response to a leading contributor deciding that it's time for them to step down :)
So while I'm in favour of the minimal PEP 1 tweaks needed to keep the volunteer-per-PEP BDFL-Delegate model going for the less controversial proposals that don't touch core parts of the language, I *don't* think filing Guido's name off and writing Brett's (or anyone else's) name in is the right answer for the deeper community governance questions we're asking ourselves, and I think we'd be squandering a rare opportunity to explore the alternatives if we instead sought to preserve the status quo too directly.
Yes, change is scary, and there's always a risk we'll find that we don't like the initial iteration of whatever we come up with, but that's just motivation to ensure that whatever system we come up with has mechanisms for change built into it (just as even the PSF's by-laws can be amended by a vote of the members).
Personally, I think the contributor council approach is likely to prove to be a good way to go (since it distributes the burden of responsibility amongst mutiple volunteers and doesn't leave anyone feeling obliged to be "on" all the time), and it would then be up to the initial members of that council to come up with a way to appropriately rotate any spokesperson responsibilities that came up.
I also think folks are placing too much weight on the notion of Guido as the primary spokesperson representing what the core contributors are thinking - if anyone were to be seen as occupying that role, I'd actually point to whoever takes the lead editor role for the What's New document in any given release, since most Pythonistas don't even think about the core development process until they're looking at a new release and asking themselves "Why on Earth did they add *that*?". (It could actually be an interesting trial addition to the PEP process to require that PEP authors include a draft What's New entry, as it forces you to step back from the intricacies of language and interpreter runtime design, and focus on the end user impact of a proposed change)
Cheers, Nick.
P.S. Since "What *do* you think is the upper limit on what's a reasonable request to make of a community volunteer?" is a natural follow-up question, I'm currently fairly comfortable with the scope of things like PSF Board membership, PSF Working Group membership, CPython release management, CPython module maintainership, and the packaging BDFL-Delegate responsibilities I recently handed over to Paul Moore (and I think that last one is borderline, and could stand to follow in CPython's footsteps if we can settle on a reasonable non-BDFL-dependent design management model).
P.P.S. Full disclosure for folks that weren't there: I proposed at the 2018 Python Language Summit that we institute a PEP 3003 style language moratarium for Python 3.8, to give the ripple effects arising from some of the recent language changes like type hinting, native coroutines, and f-strings a chance to settle down before we embarked on more language level changes like assignment expressions and None-aware operators - I think imposing such a moratorium would cost us very little in the long run, and give the wider community a chance to catch up on all of the benefits that 3.6 and 3.7 can offer them. While Guido really wasn't a fan of the idea, the fact that I believe we should be thinking about how to reduce the demand for language level churn rather than worrying too much about how to enable more of it does mean that I'm entirely comfortable with the idea of postponing any further syntax changes beyond PEP 572 to Python 3.9 or later.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Jul 20, 2018, 07:51 Nick Coghlan, <ncoghlan@gmail.com> wrote:
On 18 July 2018 at 16:42, Chris Jerdonek <chris.jerdonek@gmail.com> wrote:
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.
As much as I appreciate the vote of confidence, I'm actively working to reduce my open source commitments and responsibilities at the moment, not increase them. Burnout's a thing, y'all, especially when you have the attention span of a caffeinated squirrel and get involved in far more things than you could ever hope to see through to completion in a reasonable period of time :)
And that's my primary concern with any proposals to put a comparable level of stress to that which Guido has been handling for years on to another volunteer's shoulders: I don't think it's an even remotely reasonable thing to request of a community volunteer.
Guido was willing to do it for so long because Python was his creation, and he grew into the increasing demands of the BDFL role as time went by, but even he eventually reached the point of saying "I don't want to do this any more - the personal costs are outweighing the personal benefits". There's no way that a new individual in a comparable role to Guido's is going to have an easier time of it than Guido did, and a lot of good reasons to believe that they will find it significantly harder (not least of which is that Guido has been able to request 50% funded "BDFL-time" from his employers since he joined Google in 2005, and it's unlikely that a newcomer to the role would enjoy that benefit any time soon).
While I'm purposefully staying out of this thread as my name is currently so strongly associated with it and I don't want people thinking I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50% time at Microsoft if I asked for it (I already get a day/week plus email reading every day).
I also agreed to Barry's proposal under the expectation that I would still take a month off every year and one day a week like I do already. That plus a council of folks to help with the load makes me think I can handle the workload without having to sacrifice more personal time than I'm already comfortable doing now. I also think that we as a team and a community are a bit more aware of the issue of burnout thanks to Guido's retirement.
Plus Andrea said it was okay 😉 (The cat was indifferent.)
-Brett
In the 2 terms I spent on the PSF board, one of the things I aimed to help Ewa work towards was making being on the Board less of a recipe for burnout, and I've done what I could to help make working on the Python packaging ecosystem less of a burnout factory as well. Before my time on the Board, other folks had already started the process of having paid PSF staff take on more PyCon US management responsibilities to help reduce the burden on folks volunteering for PyCon US leadership roles.
In that context, setting up a high profile volunteer leadership role that I'd expect to mainly let us burn out multiple people in succession really doesn't seem like a good response to a leading contributor deciding that it's time for them to step down :)
So while I'm in favour of the minimal PEP 1 tweaks needed to keep the volunteer-per-PEP BDFL-Delegate model going for the less controversial proposals that don't touch core parts of the language, I *don't* think filing Guido's name off and writing Brett's (or anyone else's) name in is the right answer for the deeper community governance questions we're asking ourselves, and I think we'd be squandering a rare opportunity to explore the alternatives if we instead sought to preserve the status quo too directly.
Yes, change is scary, and there's always a risk we'll find that we don't like the initial iteration of whatever we come up with, but that's just motivation to ensure that whatever system we come up with has mechanisms for change built into it (just as even the PSF's by-laws can be amended by a vote of the members).
Personally, I think the contributor council approach is likely to prove to be a good way to go (since it distributes the burden of responsibility amongst mutiple volunteers and doesn't leave anyone feeling obliged to be "on" all the time), and it would then be up to the initial members of that council to come up with a way to appropriately rotate any spokesperson responsibilities that came up.
I also think folks are placing too much weight on the notion of Guido as the primary spokesperson representing what the core contributors are thinking - if anyone were to be seen as occupying that role, I'd actually point to whoever takes the lead editor role for the What's New document in any given release, since most Pythonistas don't even think about the core development process until they're looking at a new release and asking themselves "Why on Earth did they add *that*?". (It could actually be an interesting trial addition to the PEP process to require that PEP authors include a draft What's New entry, as it forces you to step back from the intricacies of language and interpreter runtime design, and focus on the end user impact of a proposed change)
Cheers, Nick.
P.S. Since "What *do* you think is the upper limit on what's a reasonable request to make of a community volunteer?" is a natural follow-up question, I'm currently fairly comfortable with the scope of things like PSF Board membership, PSF Working Group membership, CPython release management, CPython module maintainership, and the packaging BDFL-Delegate responsibilities I recently handed over to Paul Moore (and I think that last one is borderline, and could stand to follow in CPython's footsteps if we can settle on a reasonable non-BDFL-dependent design management model).
P.P.S. Full disclosure for folks that weren't there: I proposed at the 2018 Python Language Summit that we institute a PEP 3003 style language moratarium for Python 3.8, to give the ripple effects arising from some of the recent language changes like type hinting, native coroutines, and f-strings a chance to settle down before we embarked on more language level changes like assignment expressions and None-aware operators - I think imposing such a moratorium would cost us very little in the long run, and give the wider community a chance to catch up on all of the benefits that 3.6 and 3.7 can offer them. While Guido really wasn't a fan of the idea, the fact that I believe we should be thinking about how to reduce the demand for language level churn rather than worrying too much about how to enable more of it does mean that I'm entirely comfortable with the idea of postponing any further syntax changes beyond PEP 572 to Python 3.9 or later.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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/
On 20Jul2018 0858, Brett Cannon wrote:
While I'm purposefully staying out of this thread as my name is currently so strongly associated with it and I don't want people thinking I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50% time at Microsoft if I asked for it (I already get a day/week plus email reading every day).
I agree that this would likely happen. (Also that he's not a megalomaniac.)
I've been talking with our senior management about all this a bit over the last week, and the general mood is concern for Python's future if we spend an extended time without leadership. Microsoft's future these days certainly includes the Python ecosystem, and providing time for an employee to contribute freely in such a leadership role should be very easy to arrange.
And since most people are probably not aware of the "day job" breakdown we have, Brett does not spend his time working on Microsoft's policy directions on Python - that is largely me and some people who are not really known outside the company - so I wouldn't be concerned about Python being "forced into alignment" with anything except Visual Studio Code ;)
I also agreed to Barry's proposal under the expectation that I would still take a month off every year and one day a week like I do already. That plus a council of folks to help with the load makes me think I can handle the workload without having to sacrifice more personal time than I'm already comfortable doing now. I also think that we as a team and a community are a bit more aware of the issue of burnout thanks to Guido's retirement.
Plus Andrea said it was okay 😉 (The cat was indifferent.)
"Approval of his/her household" is actually a really good criteria for taking on this kind of role :)
Cheers, Steve
On Fri, Jul 20, 2018, 08:58 Brett Cannon <brett@python.org> wrote:
On Fri, Jul 20, 2018, 07:51 Nick Coghlan, <ncoghlan@gmail.com> wrote:
Guido was willing to do it for so long because Python was his creation, and he grew into the increasing demands of the BDFL role as time went by, but even he eventually reached the point of saying "I don't want to do this any more - the personal costs are outweighing the personal benefits". There's no way that a new individual in a comparable role to Guido's is going to have an easier time of it than Guido did, and a lot of good reasons to believe that they will find it significantly harder (not least of which is that Guido has been able to request 50% funded "BDFL-time" from his employers since he joined Google in 2005, and it's unlikely that a newcomer to the role would enjoy that benefit any time soon).
While I'm purposefully staying out of this thread as my name is currently so strongly associated with it and I don't want people thinking I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50% time at Microsoft if I asked for it (I already get a day/week plus email reading every day).
Is that only if you were named BDFL, or do you think they might also support that if you were named "Chief PEP Herder", or "Member of the steering council",or similar?
AFAICT Guido spent a lot of time behind the scenes moving PEPs along and generally keeping things organized. I think we might get a lot of value out of having more people with time to focus on these things, and it's not really limited to the BDFL. The Django project seems to benefit a lot from their fellows program [1], and in the recent grant the PSF got for PyPI, everyone was *very* happy that we spent money on a project manager [2]. (And at the risk of falling into megalovania myself, I've also written about this recently [3].)
So I don't have a specific proposal or anything, but maybe as part of this discussion we should exploring ways to get more dedicated time on CPython, through company's donating time, or sponsoring people through the PSF, or whatever makes sense.
-n
[1] https://www.djangoproject.com/weblog/2016/dec/28/fellowship-2016-retrospecti... [2] https://twitter.com/EWDurbin/status/968180960066928640 [3] https://vorpus.org/blog/the-unreasonable-effectiveness-of-investment-in-open...
On Fri, 20 Jul 2018 at 15:36 Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jul 20, 2018, 08:58 Brett Cannon <brett@python.org> wrote:
On Fri, Jul 20, 2018, 07:51 Nick Coghlan, <ncoghlan@gmail.com> wrote:
Guido was willing to do it for so long because Python was his creation, and he grew into the increasing demands of the BDFL role as time went by, but even he eventually reached the point of saying "I don't want to do this any more - the personal costs are outweighing the personal benefits". There's no way that a new individual in a comparable role to Guido's is going to have an easier time of it than Guido did, and a lot of good reasons to believe that they will find it significantly harder (not least of which is that Guido has been able to request 50% funded "BDFL-time" from his employers since he joined Google in 2005, and it's unlikely that a newcomer to the role would enjoy that benefit any time soon).
While I'm purposefully staying out of this thread as my name is
currently so strongly associated with it and I don't want people thinking I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50% time at Microsoft if I asked for it (I already get a day/week plus email reading every day).
Is that only if you were named BDFL, or do you think they might also support that if you were named "Chief PEP Herder", or "Member of the steering council",or similar?
It isn't really title and more about workload/responsibility. So if the title changed to "Chief PEP herder" but it was still on my shoulders to have final say then I don't expect an issue as they would understand what that means to me and my time. If I'm one of three on a council then I might still get more time but I'm not as sure; it's definitely possible, but not as much of a sure thing. If the group was 10 then probably not because that means I am just one of about a quarter of all authors over the past year.
AFAICT Guido spent a lot of time behind the scenes moving PEPs along and generally keeping things organized. I think we might get a lot of value out of having more people with time to focus on these things, and it's not really limited to the BDFL. The Django project seems to benefit a lot from their fellows program [1], and in the recent grant the PSF got for PyPI, everyone was *very* happy that we spent money on a project manager [2]. (And at the risk of falling into megalomania myself, I've also written about this recently [3].)
So I don't have a specific proposal or anything, but maybe as part of this discussion we should be exploring ways to get more dedicated time on CPython, through company's donating time, or sponsoring people through the PSF, or whatever makes sense.
I think that's a constant discussion to have which never really ends. People with more time to effectively contribute is always welcome. :)
-Brett
-n
[1] https://www.djangoproject.com/weblog/2016/dec/28/fellowship-2016-retrospecti... [2] https://twitter.com/EWDurbin/status/968180960066928640 [3] https://vorpus.org/blog/the-unreasonable-effectiveness-of-investment-in-open...
On Fri, Jul 20, 2018 at 3:50 PM, Brett Cannon <brett@python.org> wrote:
On Fri, 20 Jul 2018 at 15:36 Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jul 20, 2018, 08:58 Brett Cannon <brett@python.org> wrote:
While I'm purposefully staying out of this thread as my name is currently so strongly associated with it and I don't want people thinking I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50% time at Microsoft if I asked for it (I already get a day/week plus email reading every day).
Is that only if you were named BDFL, or do you think they might also support that if you were named "Chief PEP Herder", or "Member of the steering council",or similar?
It isn't really title and more about workload/responsibility. So if the title changed to "Chief PEP herder" but it was still on my shoulders to have final say then I don't expect an issue as they would understand what that means to me and my time. If I'm one of three on a council then I might still get more time but I'm not as sure; it's definitely possible, but not as much of a sure thing. If the group was 10 then probably not because that means I am just one of about a quarter of all authors over the past year.
Right, my point was more that "workload" and "authority" are related but not exactly the same :-). For example, if we ended up with a governance model in which final PEP acceptance is based on consensus or voting or something, then we wouldn't have a BDFL, but it still might be *very* helpful to have people with dedicated time to help shepherd PEPs through the process of building consensus, working out exactly what the points of disagreement were that needed to be voted on, mediating arguments that get out of hand, and so forth [1] -- that's what I was trying to handwave at with the "Chief PEP herder" title.
I think that's a constant discussion to have which never really ends. People with more time to effectively contribute is always welcome. :)
Sure, but there is something special about this moment too :-). If we think that funding positions like these would make a significant difference to the viability of our community post-Guido, then now is a time when we could go to companies and say "look, Python is going through this critical transition, it needs this kind of funding to survive and thrive, can you help?", and see how they respond.
I don't want to put you on the spot and I know you can't make promises on behalf of MS, so maybe I shouldn't have asked. But generally – we have some evidence that companies might be willing to fund someone to be the BDFL. It'd be useful to know whether companies would also be willing to fund crucial community work even if it didn't mean they got to boast about having the BDFL on their payroll.
-n
[1] personally I suspect that python's survival is going to depend much more on whether we have people doing this kind of work, than on which specific formal governance structure we end up with
-- Nathaniel J. Smith -- https://vorpus.org
On Jul 17, 2018, at 22:55, Kushal Das <kushaldas@gmail.com> wrote:
+1 to this idea including Brett as BDFL. Though I am wondering if anyone asked Brett about it?
I know my email was long, so easy to overlook, but I did ask Brett and he didn’t immediately say no. :)
-Barry
Hi Barry,
Le 18/07/2018 à 04:02, Barry Warsaw a écrit :
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.
Why do you think non-BDFL projects have a problem with """ambiguity as to the authority of said decision"""? What is your basis for that assertion?
I'm worried that you seem to be descending into magical thought, believing for some reason that nothing else than monarchy could ever work for a software project.
If you’ve read this far - thank you! Now for the big reveal. I think the Next BDFL should be… (drum roll)…
Brett Cannon
Since you're opening this can of worms, I'll say it:
- I'm -1 on a new dictator-for-life (*)
- I'm -1 on Brett Cannon as a new dictator-for-life
You're creating a huge problem here. Whatever dictator you come up with, not everyone will be ok with that choice. What are they supposed to do? If one doesn't think X is legitimate as a dictator, how does one keep contributing to the project? In other words, you are threatening to exclude people, perhaps seasoned contributors.
(*) (I'm leaving the "benevolent" part out, since clearly it was only tied to Guido's personality, not to any inherent statutory limitations)
I’ve long said — somewhat in jest, since I never expected Guido to actually ever retire! — that Brett would be my choice for the next BDFL. I think he’s the perfect candidate, and he’s already demonstrated qualities that I think make him a fantastic leader.
I bed to disagree, Barry. Brett is a good contributor, that doesn't make him legitimate as a dictator. Only Guido could be, and he has stepped down.
The amount of cheerleading here ("""smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills""") is embarrassing. What if we don't subscribe to your views of Brett's qualities: do you expect us to publicly criticize Brett so as to justify our opposition?
Your proposal is turning this discussion into some kind of Napoleonic plebiscite. This is frankly unpleasant :-/
Regards
Antoine.
On 07/18/2018 01:43 AM, Antoine Pitrou wrote:
Le 18/07/2018 à 04:02, Barry Warsaw a écrit :
If you’ve read this far - thank you! Now for the big reveal. I think the Next BDFL should be… (drum roll)…
Brett Cannon
Since you're opening this can of worms, I'll say it:
- I'm -1 on a new dictator-for-life (*)
- I'm -1 on Brett Cannon as a new dictator-for-life
You're creating a huge problem here. Whatever dictator you come up with, not everyone will be ok with that choice. What are they supposed to do? If one doesn't think X is legitimate as a dictator, how does one keep contributing to the project? In other words, you are threatening to exclude people, perhaps seasoned contributors.
I find this an empty argument. What were they supposed to do when PEPs they wanted were rejected, and PEPs they thought foolish accepted? If we go with a committee are we threatening to exclude those who think design-by-committee is not a legitamate method, or don't think it's members are legitimate choices?
No, we are not threatening anybody. The core-devs will make their choice, and those who don't like the result can leave or go as they will.
(*) (I'm leaving the "benevolent" part out, since clearly it was only tied to Guido's personality, not to any inherent statutory limitations)
I think that's a mistake. Clearly, the "benevolent" part is a major criteria for the dictator, triumvirate, CoE, or whatever we come up with, and Guido is not the only benevolent core-dev we have.
I’ve long said — somewhat in jest, since I never expected Guido to actually ever retire! — that Brett would be my choice for the next BDFL. I think he’s the perfect candidate, and he’s already demonstrated qualities that I think make him a fantastic leader.
I beg to disagree, Barry. Brett is a good contributor, that doesn't make him legitimate as a dictator. Only Guido could be, and he has stepped down.
I agree: being a good contributor does not ipso facto make for a good benevolent dictator.
I disagree that only Guido could be a good BDFL. I do agree that good BDFLs are rare.
The amount of cheerleading here ("""smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills""") is embarrassing. What if we don't subscribe to your views of Brett's qualities: do you expect us to publicly criticize Brett so as to justify our opposition?
I think one can oppose the NBDFL model without criticizing the proposed candidate. After all, if the model is rejected it doesn't matter who the candidates were. If the model is accepted, then I think a simple "I disagree with your assessment" would suffice, and you could nominate someone you felt was more qualified.
-- ~Ethan~
Hi Ethan,
Le 18/07/2018 à 11:49, Ethan Furman a écrit :
You're creating a huge problem here. Whatever dictator you come up with, not everyone will be ok with that choice. What are they supposed to do? If one doesn't think X is legitimate as a dictator, how does one keep contributing to the project? In other words, you are threatening to exclude people, perhaps seasoned contributors.
I find this an empty argument. What were they supposed to do when PEPs they wanted were rejected, and PEPs they thought foolish accepted?
I'm not sure what you mean? I may disagree with my governement's decisions without wanting to overthrow the whole regime (or, conversely, I may agree with some of a despot's decisions without finding him legitimate to make those decisions). Disagreeing with a PEP has nothing to do with this discussion, has it?
If we go with a committee are we threatening to exclude those who think design-by-committee is not a legitamate method, or don't think it's members are legitimate choices?
If we're talking about a dictator (this is Barry's proposal), we're not talking about someone that just makes language design decisions, as Victor pointed out.
Or if it is what we're talking about, the name is ill-chosen :-)
Regards
Antoine.
On 07/18/2018 03:04 AM, Antoine Pitrou wrote:
Hi Ethan,
Le 18/07/2018 à 11:49, Ethan Furman a écrit :
You're creating a huge problem here. Whatever dictator you come up with, not everyone will be ok with that choice. What are they supposed to do? If one doesn't think X is legitimate as a dictator, how does one keep contributing to the project? In other words, you are threatening to exclude people, perhaps seasoned contributors.
I find this an empty argument. What were they supposed to do when PEPs they wanted were rejected, and PEPs they thought foolish accepted?
I'm not sure what you mean? I may disagree with my governement's decisions without wanting to overthrow the whole regime (or, conversely, I may agree with some of a despot's decisions without finding him legitimate to make those decisions). Disagreeing with a PEP has nothing to do with this discussion, has it?
If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice illegitimate.
If we go with a committee are we threatening to exclude those who think design-by-committee is not a legitamate method, or don't think it's members are legitimate choices?
If we're talking about a dictator (this is Barry's proposal), we're not talking about someone that just makes language design decisions,
I was asking about how objecting to the currently chosen dictator would be any different from objecting to the currently chosen council members.
as Victor pointed out.
Where did he point this out? I don't see an email, although I might just be missing it.
-- ~Ethan~
Le 18/07/2018 à 17:58, Ethan Furman a écrit :
If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice illegitimate.
At this point we are not talking about a majority vote. All I see is a rushed plebiscite on a single governance model and a single person.
Regards
Antoine.
On 18Jul2018 0910, Antoine Pitrou wrote:
Le 18/07/2018 à 17:58, Ethan Furman a écrit :
If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice illegitimate.
At this point we are not talking about a majority vote. All I see is a rushed plebiscite on a single governance model and a single person.
The "plebiscite" is really about the question "should we *consider* appointing someone as NBDFL" - Barry's very first line of his email reads:
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!
The only thing I see happening now is sounding out opinions on the model. No decision is being taken yet.
Right now, I imagine Barry is testing the waters to see whether it's worth his time writing this up as a proposed PEP 2. Other people seem to be interested in also proposing alternative PEP 2s, and eventually we as a group will have to select one of them, no doubt by majority vote. And while Barry's long service to this group certainly adds weight to his opinion, it's also likely that we can filibuster for long enough until he retires and then ignore him completely :)
Your contributions to this part of the discussion are also very useful - we need to know what concerns people have, and often those concerns may not have occurred to those of us who approach it with a more idealistic idea of how everything will work out.
Nobody has really disputed the idea of codifying our new model as PEP 2. Until we have an actual text of PEP 2, I see no reason for concern that we are rushing anything.
Cheers, Steve
On Wed, Jul 18, 2018 at 10:44 AM Steve Dower <steve.dower@python.org> wrote:
Your contributions to this part of the discussion are also very useful - we need to know what concerns people have, and often those concerns may not have occurred to those of us who approach it with a more idealistic idea of how everything will work out.
This is a critical point, especially as we are without a BDFL to rely on for this discussion and decision. :) We need all the viewpoints, mutual respect, and patience.
-eric
On Jul 18, 2018, at 09:44, Steve Dower <steve.dower@python.org> wrote:
Right now, I imagine Barry is testing the waters to see whether it's worth his time writing this up as a proposed PEP 2. Other people seem to be interested in also proposing alternative PEP 2s, and eventually we as a group will have to select one of them, no doubt by majority vote. And while Barry's long service to this group certainly adds weight to his opinion, it's also likely that we can filibuster for long enough until he retires and then ignore him completely :)
One can only hope! :)
Cheers, -Barry
[Antoine Pitrou]
At this point we are not talking about a majority vote. All I see is a rushed plebiscite on a single governance model and a single person.
I view this as the "freewheeling brainstorming" initial part of the process. We've barely even mentioned who the plebes may be - is it just committers who have a say? If so, is that by definition precisely the members of this mailing list, or some broader or narrower definition? Or also some subset of the 5 classes of PSF membership? Etc. And regardless of how someone wants to answer that, who decides on who gets to "vote" to begin with? Under what authority?
IOW, we're several universes away from reaching a credible resolution.
In the meantime, a "+1" or "-1" from me really just means "let's keep this idea on the table" or "let's drop this one", respectively. Which carries no actual weight at all.
It's valuable to push back against ideas you don't like, and I'm glad you are!
I find this discussion really interesting from a social perspective. Let's keep it going for a while without jumping to any conclusions. It's too early to head down into one particular rabbit hole yet ;-)
There's no rush and if things crystallize only in a year's time, that's perfectly fine.
(And even better: We have Tim back with us for all that time to entertain us :-))
Cheers.
On 18.07.2018 18:55, Tim Peters wrote:
[Antoine Pitrou]
At this point we are not talking about a majority vote. All I see is a rushed plebiscite on a single governance model and a single person.
I view this as the "freewheeling brainstorming" initial part of the process. We've barely even mentioned who the plebes may be - is it just committers who have a say? If so, is that by definition precisely the members of this mailing list, or some broader or narrower definition? Or also some subset of the 5 classes of PSF membership? Etc. And regardless of how someone wants to answer that, who decides on who gets to "vote" to begin with? Under what authority?
IOW, we're several universes away from reaching a credible resolution.
In the meantime, a "+1" or "-1" from me really just means "let's keep this idea on the table" or "let's drop this one", respectively. Which carries no actual weight at all.
It's valuable to push back against ideas you don't like, and I'm glad you are!
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jul 18 2018)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On Jul 18, 2018, at 09:10, Antoine Pitrou <antoine@python.org> wrote:
At this point we are not talking about a majority vote. All I see is a rushed plebiscite on a single governance model and a single person.
Antoine, there’s nothing rushed about this. I made a proposal, and there’s a healthy debate going on. We don’t even know how the decisions will be made, or by whom yet.
Cheers, -Barry
On Jul 18, 2018, at 10:58 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice illegitimate.
A simple majority vote is wildly insufficient for this case. Python is a large project with many contributors and alienating maybe tens of them is not acceptable, especially if we are talking about a "for life" choice.
- Ł
Le 18/07/2018 à 18:36, Łukasz Langa a écrit :
On Jul 18, 2018, at 10:58 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice illegitimate.
A simple majority vote is wildly insufficient for this case. Python is a large project with many contributors and alienating maybe tens of them is not acceptable, especially if we are talking about a "for life" choice.
Thanks for saying this better than I could :-)
Regards
Antoine.
On Wed, Jul 18, 2018 at 9:38 AM, Antoine Pitrou <antoine@python.org> wrote:
Le 18/07/2018 à 18:36, Łukasz Langa a écrit :
A simple majority vote is wildly insufficient for this case. Python is a
large project with many contributors and alienating maybe tens of them is not acceptable, especially if we are talking about a "for life" choice.
Thanks for saying this better than I could :-)
I supported Barry's proposal. I can definitely understand Łukasz's and Antoine's stance here. One of the important part of Barry's proposal was removal of "for life" part.
Most of us are volunteers contributing to python. A leader with ultimate say on language design, governance burden to steer the comittee is going to be challenging and stressful for "anyone" in this model proposed by Barry.
Thank you, Senthil
On 07/18/2018 09:36 AM, Łukasz Langa wrote:
On Jul 18, 2018, at 10:58 AM, Ethan Furman wrote:
If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice illegitimate.
A simple majority vote is wildly insufficient for this case. Python is a large project with many contributors and alienating maybe tens of them is not acceptable, especially if we are talking about a "for life" choice.
Are you saying that we should use some method besides voting, or that a higher percentage of yea votes is required? If the latter, I have no problem with 66% or 75%.
-- ~Ethan~
On Jul 18, 2018, at 11:54 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
Are you saying that we should use some method besides voting, or that a higher percentage of yea votes is required? If the latter, I have no problem with 66% or 75%.
The cleanest way would be for Guido to choose but he already said he wants to stay out of the process.
With that in mind, one alternative is for the President of the PSF to choose ;-)
...so realistically the only alternative is a vote. Given the gravity of the situation (a decision on how future decisions are made; long-term consequences), I propose:
Define a committer as anybody with GitHub privileges. While not everybody on this mailing list decided to get GitHub credentials, they can do it at any point. At the same time, by defining the committer set as GitHub contributors, we solve the issue of inactive contributors. And this is important because...
Require 90% participation for the vote to be valid.
Require 90% votes in favor for the proposal to pass.
If 2. or 3. fail, back to the drawing board. I'd lower those requirements only after a few consecutive votes fail.
- Ł
Since 1179 (and with a few very minor exceptions in the centuries right after then -- none since 1612), the Catholic Church requires a super-majority of 2/3 to elect a new Pope. I don't see how the choice of a BDFL is so much more important to the Python community, than the choice of a Pope is to the Catholic Church; thus, requiring 90% rather than "just" 2/3 seems unwarranted.
In fact, a 90% requirement gets dangerously close to a requirement for unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and thus end the session and nullify every decision made in the session. As https://en.wikipedia.org/wiki/Liberum_veto puts it, "Many historians hold that the liberum veto was a major cause of the deterioration of the Commonwealth political system" all the way to the partitions of Poland.
Let's steer well clear of this: those who cannot remember the past, etc, etc...
Alex
On Wed, Jul 18, 2018 at 11:07 AM Łukasz Langa <lukasz@langa.pl> wrote:
On Jul 18, 2018, at 11:54 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
Are you saying that we should use some method besides voting, or that a higher percentage of yea votes is required? If the latter, I have no problem with 66% or 75%.
The cleanest way would be for Guido to choose but he already said he wants to stay out of the process.
With that in mind, one alternative is for the President of the PSF to choose ;-)
...so realistically the only alternative is a vote. Given the gravity of the situation (a decision on how future decisions are made; long-term consequences), I propose:
Define a committer as anybody with GitHub privileges. While not everybody on this mailing list decided to get GitHub credentials, they can do it at any point. At the same time, by defining the committer set as GitHub contributors, we solve the issue of inactive contributors. And this is important because...
Require 90% participation for the vote to be valid.
Require 90% votes in favor for the proposal to pass.
If 2. or 3. fail, back to the drawing board. I'd lower those requirements only after a few consecutive votes fail.
- Ł
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/
On Jul 18, 2018, at 1:23 PM, Alex Martelli <aleax@google.com> wrote:
Since 1179 (and with a few very minor exceptions in the centuries right after then -- none since 1612), the Catholic Church requires a super-majority of 2/3 to elect a new Pope. I don't see how the choice of a BDFL is so much more important to the Python community, than the choice of a Pope is to the Catholic Church; thus, requiring 90% rather than "just" 2/3 seems unwarranted.
This is a good point. Moreover, I'm sure Monty Python-wise it's only fitting for us to base our rules on a papal conclave.
If we do, then it looks like 2/3 it is. However, historically cardinal participation rates were really high so I'd like to keep the 90% participation rule there.
I do find it a bit problematic that a papal conclave doesn't vote "yes/no" but rather just places names for a predefined position using predefined rules.
In fact, a 90% requirement gets dangerously close to a requirement for unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and thus end the session and nullify every decision made in the session.
Oh, you know how to hit close to home! However, there's a big difference between one vote vetoing the ruling and ten (as there's 100+ GitHub committers now IIRC).
But yeah, if the Vatican is fine with two thirds, it sounds like we could, too. By the way, if we're already studying Polish parliamentary rules, 2/3 agreement is needed to make constitution changes.
- Ł
Let's be clear that we're not yet at the stage where we can vote for anything, let alone how to vote.
Barry made one proposal, that's all.
Last week someone suggested doing research of other governance models. We should still do that before we even start voting on anything.
Mariatta
On Wed, Jul 18, 2018 at 2:04 PM Łukasz Langa <lukasz@langa.pl> wrote:
On Jul 18, 2018, at 1:23 PM, Alex Martelli <aleax@google.com> wrote:
Since 1179 (and with a few very minor exceptions in the centuries right after then -- none since 1612), the Catholic Church requires a super-majority of 2/3 to elect a new Pope. I don't see how the choice of a BDFL is so much more important to the Python community, than the choice of a Pope is to the Catholic Church; thus, requiring 90% rather than "just" 2/3 seems unwarranted.
This is a good point. Moreover, I'm sure Monty Python-wise it's only fitting for us to base our rules on a papal conclave.
If we do, then it looks like 2/3 it is. However, historically cardinal participation rates were really high so I'd like to keep the 90% participation rule there.
I do find it a bit problematic that a papal conclave doesn't vote "yes/no" but rather just places names for a predefined position using predefined rules.
In fact, a 90% requirement gets dangerously close to a requirement for unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and thus end the session and nullify every decision made in the session.
Oh, you know how to hit close to home! However, there's a big difference between one vote vetoing the ruling and ten (as there's 100+ GitHub committers now IIRC).
But yeah, if the Vatican is fine with two thirds, it sounds like we could, too. By the way, if we're already studying Polish parliamentary rules, 2/3 agreement is needed to make constitution changes.
- Ł
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/
On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
Let's be clear that we're not yet at the stage where we can vote for anything, let alone how to vote.
I don't understand what you mean. Before we get to vote on a variant of PEP 2, we need to decide how we are supposed to perform that vote. This needs to be decided before we discuss councils, dictators, and so on because it's all moot if there is no accepted way to agree which governance model we want.
Last week someone suggested doing research of other governance models. We should still do that before we even start voting on anything.
Yes, agreed, absolutely! But these are two separate concerns. I'm interested in establishing how we decide which model fits us.
- Ł
On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote: Let's be clear that we're not yet at the stage where we can vote for anything, let alone how to vote.
On Wed, Jul 18, 2018 at 6:03 PM Łukasz Langa <lukasz@langa.pl> wrote:
I don't understand what you mean. Before we get to vote on a variant of PEP 2, we need to decide how we are supposed to perform that vote. This needs to be decided before we discuss councils, dictators, and so on because it's all moot if there is no accepted way to agree which governance model we want.
Humans do so love to argue!
Both the decision-making process and the candidate decisions are reasonable to discuss; there's no intrinsic ordering constraint for reasonable discussion. We need to decide on the decision-making mechanism before the decision can be made, but that's it.
PEP 2 is (currently) the "Procedure for Adding New Modules". Though superseded, recycling the PEP number seems out of character with the RFC process from which we derived the PEP process. Let's be cautious about recycling like that; integers are cheap.
-Fred
-- Fred L. Drake, Jr. <fred at fdrake.net> "A storm broke loose in my mind." --Albert Einstein
On Jul 18, 2018, at 7:06 PM, Fred Drake <fred@fdrake.net> wrote:
PEP 2 is (currently) the "Procedure for Adding New Modules". Though superseded, recycling the PEP number seems out of character with the RFC process from which we derived the PEP process. Let's be cautious about recycling like that; integers are cheap.
Amusingly, I went through the low numbered PEPs as a result of this, and found https://www.python.org/dev/peps/pep-0010/ <https://www.python.org/dev/peps/pep-0010/>.
On Jul 18, 2018, at 16:06, Fred Drake <fred@fdrake.net> wrote:
PEP 2 is (currently) the "Procedure for Adding New Modules". Though superseded, recycling the PEP number seems out of character with the RFC process from which we derived the PEP process. Let's be cautious about recycling like that; integers are cheap.
Dang, so it is. :(
I don’t want to recycle numbers, so we’ll likely end up taking the next available low ones.
Cheers, -Barry
Next available is PEP lucky number 13 🙂
Mariatta
On Wed, Jul 18, 2018 at 4:14 PM Barry Warsaw <barry@python.org> wrote:
On Jul 18, 2018, at 16:06, Fred Drake <fred@fdrake.net> wrote:
PEP 2 is (currently) the "Procedure for Adding New Modules". Though superseded, recycling the PEP number seems out of character with the RFC process from which we derived the PEP process. Let's be cautious about recycling like that; integers are cheap.
Dang, so it is. :(
I don’t want to recycle numbers, so we’ll likely end up taking the next available low ones.
Cheers, -Barry
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/
On Wed, Jul 18, 2018 at 7:16 PM Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
Next available is PEP lucky number 13 🙂
As an integer, it has no known problems. What could possibly go wrong? ;-) To bad safe, make sure it lands on a Friday.
-Fred
-- Fred L. Drake, Jr. <fred at fdrake.net> "A storm broke loose in my mind." --Albert Einstein
On Wed, Jul 18, 2018 at 4:09 PM Fred Drake <fred@fdrake.net> wrote:
On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote: Let's be clear that we're not yet at the stage where we can vote for anything, let alone how to vote.
On Wed, Jul 18, 2018 at 6:03 PM Łukasz Langa <lukasz@langa.pl> wrote:
I don't understand what you mean. Before we get to vote on a variant of PEP 2, we need to decide how we are supposed to perform that vote. This needs to be decided before we discuss councils, dictators, and so on because it's all moot if there is no accepted way to agree which governance model we want.
Humans do so love to argue!
No we don't! (cfr http://www.montypython.net/scripts/argument.php)...
Alex
On Jul 18, 2018, at 17:31, Alex Martelli via python-committers <python-committers@python.org> wrote:
Humans do so love to argue!
No we don't! (cfr http://www.montypython.net/scripts/argument.php)...
I guess that means we do love getting hit on the head…
-Barry
Is it necessary to put exact percentages here?
I think a BDFL-replacement should have the support of a large majority of the community. I would expect anyone who would be considered as BDFL in the first place would voluntarily step down once this is no longer the case. I don’t think it is necessary to clearly define what “large majority” means, nor what “community” means.
If the Python community ever gets to the level infighting of Borgia popes versus de Medici popes I think things have deteriorated to a level that it won’t make much difference anyways.
I’m not 100% convinced I like Barry’s idea of a formal Council as the board of the community, but on the other hand I don’t have a good alternative (except for the anarchist village shouting match, but that has serious issues).
Jack
On 18-Jul-2018, at 23:04 , Łukasz Langa <lukasz@langa.pl> wrote:
On Jul 18, 2018, at 1:23 PM, Alex Martelli <aleax@google.com> wrote:
Since 1179 (and with a few very minor exceptions in the centuries right after then -- none since 1612), the Catholic Church requires a super-majority of 2/3 to elect a new Pope. I don't see how the choice of a BDFL is so much more important to the Python community, than the choice of a Pope is to the Catholic Church; thus, requiring 90% rather than "just" 2/3 seems unwarranted.
This is a good point. Moreover, I'm sure Monty Python-wise it's only fitting for us to base our rules on a papal conclave.
If we do, then it looks like 2/3 it is. However, historically cardinal participation rates were really high so I'd like to keep the 90% participation rule there.
I do find it a bit problematic that a papal conclave doesn't vote "yes/no" but rather just places names for a predefined position using predefined rules.
In fact, a 90% requirement gets dangerously close to a requirement for unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and thus end the session and nullify every decision made in the session.
Oh, you know how to hit close to home! However, there's a big difference between one vote vetoing the ruling and ten (as there's 100+ GitHub committers now IIRC).
But yeah, if the Vatican is fine with two thirds, it sounds like we could, too. By the way, if we're already studying Polish parliamentary rules, 2/3 agreement is needed to make constitution changes.
- Ł
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/
-- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman
[starting a new thread]
On Wed, 18 Jul 2018 at 14:04 Łukasz Langa <lukasz@langa.pl> wrote:
On Jul 18, 2018, at 1:23 PM, Alex Martelli <aleax@google.com> wrote:
Since 1179 (and with a few very minor exceptions in the centuries right after then -- none since 1612), the Catholic Church requires a super-majority of 2/3 to elect a new Pope. I don't see how the choice of a BDFL is so much more important to the Python community, than the choice of a Pope is to the Catholic Church; thus, requiring 90% rather than "just" 2/3 seems unwarranted.
This is a good point. Moreover, I'm sure Monty Python-wise it's only fitting for us to base our rules on a papal conclave.
If we do, then it looks like 2/3 it is. However, historically cardinal participation rates were really high so I'd like to keep the 90% participation rule there.
To put hard numbers to this, there are 91 people with commit rights ATM and 171 potential people based on the bugs.python.org committers list. So that means we will require anywhere from 82 to 154 people to vote. To me that seems unreachable on either end of the scale.
While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote).
-Brett
I do find it a bit problematic that a papal conclave doesn't vote "yes/no" but rather just places names for a predefined position using predefined rules.
In fact, a 90% requirement gets dangerously close to a requirement for unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and thus end the session and nullify every decision made in the session.
Oh, you know how to hit close to home! However, there's a big difference between one vote vetoing the ruling and ten (as there's 100+ GitHub committers now IIRC).
But yeah, if the Vatican is fine with two thirds, it sounds like we could, too. By the way, if we're already studying Polish parliamentary rules, 2/3 agreement is needed to make constitution changes.
- Ł
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/
On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett@python.org> wrote:
While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote).
It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory.
Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support:
- this makes the decision authoritative ("the committers have spoken");
- this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote").
If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team.
- Ł
By the way, should the vote be public or secret? For such an important (and sensitive) matter, perhaps it would be wise for it to be secret.
Regards
Antoine.
Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett@python.org> wrote:
While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote).
It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory.
Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support:
- this makes the decision authoritative ("the committers have spoken");
- this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote").
If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team.
- Ł
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/
I hate cabals. I prefer to keep everything open and transparent, as this mailing list is public (even if only core developers are allowed to post).
Which drawback do you see of making the votes public?
Victor
2018-07-19 0:26 GMT+02:00 Antoine Pitrou <antoine@python.org>:
By the way, should the vote be public or secret? For such an important (and sensitive) matter, perhaps it would be wise for it to be secret.
Regards
Antoine.
Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett@python.org> wrote:
While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote).
It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory.
Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support:
- this makes the decision authoritative ("the committers have spoken");
- this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote").
If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team.
- Ł
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/
Le 19/07/2018 à 00:29, Victor Stinner a écrit :
I hate cabals. I prefer to keep everything open and transparent, as this mailing list is public (even if only core developers are allowed to post).
Even if posting is public, you won't know whether there is a cabal or not (unless you are part of the cabal -- I hope you aren't, are you? ;-)).
Which drawback do you see of making the votes public?
Let's say I'm being asked if X should be a « next BDFL » (or Council member, etc.) and I vote no publicly. What is my position if X is elected? How will my vote be interpreted? Will I get discriminated against (even unconsciously) just because I didn't choose that person?
There are all kinds of pressures (or self-censorship phenomena) that can occur with public voting.
(votes by elected representatives, conversely, are public, because being elected it's important for the electors to know what the representatives truly stand for)
Regards
Antoine.
Victor
2018-07-19 0:26 GMT+02:00 Antoine Pitrou <antoine@python.org>:
By the way, should the vote be public or secret? For such an important (and sensitive) matter, perhaps it would be wise for it to be secret.
Regards
Antoine.
Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett@python.org> wrote:
While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote).
It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory.
Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support:
- this makes the decision authoritative ("the committers have spoken");
- this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote").
If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team.
- Ł
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/
Le 19/07/2018 à 00:36, Antoine Pitrou a écrit :
Le 19/07/2018 à 00:29, Victor Stinner a écrit :
I hate cabals. I prefer to keep everything open and transparent, as this mailing list is public (even if only core developers are allowed to post).
Even if posting is public, you won't know whether there is a cabal or not (unless you are part of the cabal -- I hope you aren't, are you? ;-)).
Sorry: s/posting/voting/
2018-07-19 0:36 GMT+02:00 Antoine Pitrou <antoine@python.org>:
Let's say I'm being asked if X should be a « next BDFL » (or Council member, etc.) and I vote no publicly. What is my position if X is elected? How will my vote be interpreted? Will I get discriminated against (even unconsciously) just because I didn't choose that person?
I see. I understood that we were more discussing the governance model than voting for a specific BDFL: I'm not convinced yet that we need a BDFL :-)
Victor
The PSF uses a good voting system where votes are secret. I see no reason not to reuse this infra.
-- Best regards, Łukasz Langa
On Jul 18, 2018, at 5:26 PM, Antoine Pitrou <antoine@python.org> wrote:
By the way, should the vote be public or secret? For such an important (and sensitive) matter, perhaps it would be wise for it to be secret.
Regards
Antoine.
Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett@python.org> wrote:
While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote).
It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory.
Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support:
- this makes the decision authoritative ("the committers have spoken");
- this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote").
If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team.
- Ł
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/
Excerpts from Łukasz Langa's message of 2018-07-18 17:31:40 -0500:
The PSF uses a good voting system where votes are secret. I see no reason not to reuse this infra.
-- Best regards, Łukasz Langa
This feels like a case where a consensus-based voting system may be better than one that depends on amassing raw votes.
https://civs.cs.cornell.edu is a hosted version of Condorcet that is reliable, easy to use, and allows for public review of the ballots (without associating them with the person casting them).
Doug
On Jul 18, 2018, at 6:18 PM, Łukasz Langa <lukasz@langa.pl> wrote:
On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett@python.org> wrote:
While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote).
It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory.
Given that we don’t have a lot of levers in our tool chest to compel voting, what would you propose we do if we get only a 35% participation rate? We can’t drag people to the polls, the most we can really do is either keep running elections and hope you hit whatever threshold you decide on, or you start removing people who can vote until you’ve removed enough people that the people who are participating now make up whatever your target participation rate is.
The first choice there strikes me as unrealistic. Hope is not a strategy, and I fail to see why repeatedly offering the same vote multiple times is likely to increase the participation rate. In fact, I think it’s likely to decease it as people get tired of having to do it over again and just start giving up and viewing it as noise.
The second choice seems… dishonest to me? You’re not really increasing the participation of the vote, you’re just juicing the numbers to make the participation rate higher. It’s selectively defining who is eligible to vote to make the numbers look better.
Is there another option I’m missing to compel people to vote?
Taking a step back, there are two reasons I stress the importance of (almost) everybody voicing their support:
- this makes the decision authoritative ("the committers have spoken”);
I think this is largely a non-issue. In the US we do not have mandatory elections, and I don’t see very many people challenging the authority of said elections due to the large percentage of non-voters. The most I generally see if people scolding those who don’t vote.
- this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote”).
Unless you require 100% voting participation, it doesn’t ensure this, it just makes it less likely. If you target 90%, then a full 10% of the people could have been excluded due to poor timing.
I don’t think it’s possible to fully eliminate this risk, but I think the best possible way of handling it is to advertise the vote well in advance, and allow the vote itself to take place over a reasonable amount of time. The more advance notice, and the larger the window of time is to actually vote in, the less likely timing becomes an issue. Just to pluck some random times out of the air, if you advertise the voting for 3 months and allow voting to happen any time in a months time, that gives people a full 4 months they will have to be completely unavailable to have no idea the voting is happening, and be unable to access a computer for a handful of minutes to actually do the vote at all in a month.
If you feel like this is unrealistic because most of our committers aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team.
On Wed, 18 Jul 2018 at 15:46 Donald Stufft <donald@stufft.io> wrote:
On Jul 18, 2018, at 6:18 PM, Łukasz Langa <lukasz@langa.pl> wrote:
On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett@python.org> wrote:
While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote).
It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory.
Given that we don’t have a lot of levers in our tool chest to compel voting, what would you propose we do if we get only a 35% participation rate? We can’t drag people to the polls, the most we can really do is either keep running elections and hope you hit whatever threshold you decide on, or you start removing people who can vote until you’ve removed enough people that the people who are participating now make up whatever your target participation rate is.
The first choice there strikes me as unrealistic. Hope is not a strategy, and I fail to see why repeatedly offering the same vote multiple times is likely to increase the participation rate. In fact, I think it’s likely to decease it as people get tired of having to do it over again and just start giving up and viewing it as noise.
The second choice seems… dishonest to me? You’re not really increasing the participation of the vote, you’re just juicing the numbers to make the participation rate higher. It’s selectively defining who is eligible to vote to make the numbers look better.
Is there another option I’m missing to compel people to vote?
Taking a step back, there are two reasons I stress the importance of
(almost) everybody voicing their support:
- this makes the decision authoritative ("the committers have spoken”);
I think this is largely a non-issue. In the US we do not have mandatory elections, and I don’t see very many people challenging the authority of said elections due to the large percentage of non-voters. The most I generally see if people scolding those who don’t vote.
- this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote”).
Unless you require 100% voting participation, it doesn’t ensure this, it just makes it less likely. If you target 90%, then a full 10% of the people could have been excluded due to poor timing.
I don’t think it’s possible to fully eliminate this risk, but I think the best possible way of handling it is to advertise the vote well in advance, and allow the vote itself to take place over a reasonable amount of time. The more advance notice, and the larger the window of time is to actually vote in, the less likely timing becomes an issue. Just to pluck some random times out of the air, if you advertise the voting for 3 months and allow voting to happen any time in a months time, that gives people a full 4 months they will have to be completely unavailable to have no idea the voting is happening, and be unable to access a computer for a handful of minutes to actually do the vote at all in a month.
I think this is a reasonable way to deal with the situation.
We will also need to see how many proposals we have and how similar they are, else we might have to talk about ranked ballot.
There are plenty of precedents for mandatory voting, but the enforcement mechanisms (if any) appear not to be applicable to our case. Note the "if any": several countries declare voting a citizen's duty (in their Constitution or otherwise) but don't actually enforce this duty in any way. For example, that's the case in the United States: if you apply for naturalization you will be quizzed on many things, including "what are the duties of a citizen", and one of the latter is "participate in the democratic process" which includes voting -- but if you don't, no enforcement action is taken against you. In contrast, if you get a jury summons (jury duty being another of those citizen duties) and repeatedly fail to show up, you may end up in jail -- now THAT is enforcement of the duty (and no Python community organism has, nor should have, such power of enforcement.
In Italy, where voting is declared to be a duty in the Constitution, at the start of the Republic you'd get (until next election) a stamp of "non ha votato" ("did not vote") in your publicly accessible judiciary record (it would come up in any background search -- and, in a country where firing employees was notoriously hard, some opined that such a flaw might be grounds for dismissal if the employer so wished, although I've never heard of it happening). That was abolished 25 years ago, in part because it was randomly/capriciously enforced (many judicial districts were too otherwise-busy to go through voting records and apply/remove the stamp!-). So, now, Italy is in the vast camp of countries declaring voting a duty (Italy's constitution was not changed on this subject) but not enforcing the "duty" at all (indeed, failing to show up to vote is now often advocated by adversaries of referendums, which have a 50% minimum participation threshold to be valid and may well be easier to defeat by getting people to just not show up -- since many others won't anyway for other reasons -- than by getting them to vote against).
Since I originally brought up a parallel between "which BDFL" voting, and a Papal conclave, I would be remiss to fail to mention that since 1274 the Cardinals are locked up "with a key" ("cum clave") until a Pope does get elected -- usually a good-enough incentive to vote (though once the citizens of the town where the conclave was held had to decide after a few failed votes to only send in bread and water -- and later, said citizens removed the roof of the palace where the Cardinals were locked up, hoping that rain may speed up the proceedings). Colorful, but, again, not really applicable in our case.
What's left? The "public naming and shaming" Italy used until a quarter century ago might work -- just make a little site listing the committers who, while having a right to vote, haven't voted (yet). A VERY long voting period might also help -- amendments to the US Constitution originally had unlimited times for ratification (the 27th amendment, originally the 2nd one proposed in 1789, was ratified 202 years after proposal), though these days 7 years is a more customary time limit for ratification. Not sure if these are good ideas.
Another possibility is to avoid having separate thresholds for participation and approval (US constitution amendments work that way -- with the specifics being a threshold only for approval out of all States, not how many States have voted for or against). I.e, if we decide 2/3 is OK, a proposal might be approved if 2/3 of *eligible* voters have voted for it -- no matter how many of the remaining 1/3 have voted against, or not (yet?) voted at all (since, if 100% of eligible voters could be bothered to vote, once the proposal gets 2/3 of the votes in favor, it does not matter whether the remaining 1/3 vote against, abstain, or whatever). This is not mutually exclusive with other ideas (of which, out of what I've mentioned, the viable ones -- though not necessarily wise! -- would be "public naming" of non-voters, and VERY long voting periods).
Lastly, I suspect two votes should be separated: (1) what model we adopt (BDFL, ruling triumvirate, whatever); (2) the model having been chosen, WHO is going to serve (as BDFL, as triumvirate member, and so on)...
Alex
On Wed, Jul 18, 2018 at 3:46 PM Donald Stufft <donald@stufft.io> wrote:
On Jul 18, 2018, at 6:18 PM, Łukasz Langa <lukasz@langa.pl> wrote:
On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett@python.org> wrote:
While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote).
It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory.
Given that we don’t have a lot of levers in our tool chest to compel voting, what would you propose we do if we get only a 35% participation rate? We can’t drag people to the polls, the most we can really do is either keep running elections and hope you hit whatever threshold you decide on, or you start removing people who can vote until you’ve removed enough people that the people who are participating now make up whatever your target participation rate is.
The first choice there strikes me as unrealistic. Hope is not a strategy, and I fail to see why repeatedly offering the same vote multiple times is likely to increase the participation rate. In fact, I think it’s likely to decease it as people get tired of having to do it over again and just start giving up and viewing it as noise.
The second choice seems… dishonest to me? You’re not really increasing the participation of the vote, you’re just juicing the numbers to make the participation rate higher. It’s selectively defining who is eligible to vote to make the numbers look better.
Is there another option I’m missing to compel people to vote?
Taking a step back, there are two reasons I stress the importance of
(almost) everybody voicing their support:
- this makes the decision authoritative ("the committers have spoken”);
I think this is largely a non-issue. In the US we do not have mandatory elections, and I don’t see very many people challenging the authority of said elections due to the large percentage of non-voters. The most I generally see if people scolding those who don’t vote.
- this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote”).
Unless you require 100% voting participation, it doesn’t ensure this, it just makes it less likely. If you target 90%, then a full 10% of the people could have been excluded due to poor timing.
I don’t think it’s possible to fully eliminate this risk, but I think the best possible way of handling it is to advertise the vote well in advance, and allow the vote itself to take place over a reasonable amount of time. The more advance notice, and the larger the window of time is to actually vote in, the less likely timing becomes an issue. Just to pluck some random times out of the air, if you advertise the voting for 3 months and allow voting to happen any time in a months time, that gives people a full 4 months they will have to be completely unavailable to have no idea the voting is happening, and be unable to access a computer for a handful of minutes to actually do the vote at all in a month.
If you feel like this is unrealistic because most of our committers
aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team.
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/
[can I just say how much I've missed having both you and Tim around, Alex? 😃]
On Wed, Jul 18, 2018, 17:28 Alex Martelli via python-committers, < python-committers@python.org> wrote:
There are plenty of precedents for mandatory voting, but the enforcement mechanisms (if any) appear not to be applicable to our case. Note the "if any": several countries declare voting a citizen's duty (in their Constitution or otherwise) but don't actually enforce this duty in any way. For example, that's the case in the United States: if you apply for naturalization you will be quizzed on many things, including "what are the duties of a citizen", and one of the latter is "participate in the democratic process" which includes voting -- but if you don't, no enforcement action is taken against you. In contrast, if you get a jury summons (jury duty being another of those citizen duties) and repeatedly fail to show up, you may end up in jail -- now THAT is enforcement of the duty (and no Python community organism has, nor should have, such power of enforcement.
And that lack of enforcement power is what makes me worry about mandatory participation to make a vote considered legitimate.
In Italy, where voting is declared to be a duty in the Constitution, at the start of the Republic you'd get (until next election) a stamp of "non ha votato" ("did not vote") in your publicly accessible judiciary record (it would come up in any background search -- and, in a country where firing employees was notoriously hard, some opined that such a flaw might be grounds for dismissal if the employer so wished, although I've never heard of it happening). That was abolished 25 years ago, in part because it was randomly/capriciously enforced (many judicial districts were too otherwise-busy to go through voting records and apply/remove the stamp!-). So, now, Italy is in the vast camp of countries declaring voting a duty (Italy's constitution was not changed on this subject) but not enforcing the "duty" at all (indeed, failing to show up to vote is now often advocated by adversaries of referendums, which have a 50% minimum participation threshold to be valid and may well be easier to defeat by getting people to just not show up -- since many others won't anyway for other reasons -- than by getting them to vote against).
Since I originally brought up a parallel between "which BDFL" voting, and a Papal conclave, I would be remiss to fail to mention that since 1274 the Cardinals are locked up "with a key" ("cum clave") until a Pope does get elected -- usually a good-enough incentive to vote (though once the citizens of the town where the conclave was held had to decide after a few failed votes to only send in bread and water -- and later, said citizens removed the roof of the palace where the Cardinals were locked up, hoping that rain may speed up the proceedings). Colorful, but, again, not really applicable in our case.
What's left? The "public naming and shaming" Italy used until a quarter century ago might work -- just make a little site listing the committers who, while having a right to vote, haven't voted (yet). A VERY long voting period might also help -- amendments to the US Constitution originally had unlimited times for ratification (the 27th amendment, originally the 2nd one proposed in 1789, was ratified 202 years after proposal), though these days 7 years is a more customary time limit for ratification. Not sure if these are good ideas.
Another possibility is to avoid having separate thresholds for participation and approval (US constitution amendments work that way -- with the specifics being a threshold only for approval out of all States, not how many States have voted for or against). I.e, if we decide 2/3 is OK, a proposal might be approved if 2/3 of *eligible* voters have voted for it -- no matter how many of the remaining 1/3 have voted against, or not (yet?) voted at all (since, if 100% of eligible voters could be bothered to vote, once the proposal gets 2/3 of the votes in favor, it does not matter whether the remaining 1/3 vote against, abstain, or whatever). This is not mutually exclusive with other ideas (of which, out of what I've mentioned, the viable ones -- though not necessarily wise! -- would be "public naming" of non-voters, and VERY long voting periods).
That is a good point of clarification. If we did super-majority, is it of all counted *votes* or all possible *voters*? We might be surprised by the participation levels, or we might be disappointed. So we might have to go on what we think is reasonable, try it, and if there's a threshold requirement then be prepared to have to vote again (and again ...) until the threshold is met (or we lower the threshold 😁).
Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91) to have made a commit you have look back 7 years of commit history (that will include non-core folks and those who don't have privileges anymore).
Lastly, I suspect two votes should be separated: (1) what model we adopt (BDFL, ruling triumvirate, whatever); (2) the model having been chosen, WHO is going to serve (as BDFL, as triumvirate member, and so on)...
I'm assuming that's how we will want to structure it as probably any of these proposals will specify how someone(s) will be chosen.
-Brett
Alex
On Wed, Jul 18, 2018 at 3:46 PM Donald Stufft <donald@stufft.io> wrote:
On Jul 18, 2018, at 6:18 PM, Łukasz Langa <lukasz@langa.pl> wrote:
On Jul 18, 2018, at 4:56 PM, Brett Cannon <brett@python.org> wrote:
While I am totally fine with a super-majority of votes for something to be accepted, I don't think the minimum participation requirement will work. If people simply choose not to vote then they choose not to (we have no way to really compel people to vote).
It could be easily added to the list of things expected from a core contributor. It's not like this is a laborious chore, neither is it happening often. There are countries where voting is mandatory.
Given that we don’t have a lot of levers in our tool chest to compel voting, what would you propose we do if we get only a 35% participation rate? We can’t drag people to the polls, the most we can really do is either keep running elections and hope you hit whatever threshold you decide on, or you start removing people who can vote until you’ve removed enough people that the people who are participating now make up whatever your target participation rate is.
The first choice there strikes me as unrealistic. Hope is not a strategy, and I fail to see why repeatedly offering the same vote multiple times is likely to increase the participation rate. In fact, I think it’s likely to decease it as people get tired of having to do it over again and just start giving up and viewing it as noise.
The second choice seems… dishonest to me? You’re not really increasing the participation of the vote, you’re just juicing the numbers to make the participation rate higher. It’s selectively defining who is eligible to vote to make the numbers look better.
Is there another option I’m missing to compel people to vote?
Taking a step back, there are two reasons I stress the importance of
(almost) everybody voicing their support:
- this makes the decision authoritative ("the committers have spoken”);
I think this is largely a non-issue. In the US we do not have mandatory elections, and I don’t see very many people challenging the authority of said elections due to the large percentage of non-voters. The most I generally see if people scolding those who don’t vote.
- this ensures that we haven't omitted somebody due to poor timing ("I was on a sabbatical and couldn't vote”).
Unless you require 100% voting participation, it doesn’t ensure this, it just makes it less likely. If you target 90%, then a full 10% of the people could have been excluded due to poor timing.
I don’t think it’s possible to fully eliminate this risk, but I think the best possible way of handling it is to advertise the vote well in advance, and allow the vote itself to take place over a reasonable amount of time. The more advance notice, and the larger the window of time is to actually vote in, the less likely timing becomes an issue. Just to pluck some random times out of the air, if you advertise the voting for 3 months and allow voting to happen any time in a months time, that gives people a full 4 months they will have to be completely unavailable to have no idea the voting is happening, and be unable to access a computer for a handful of minutes to actually do the vote at all in a month.
If you feel like this is unrealistic because most of our committers
aren't currently active, I hear you. But what I like even less is claiming that "we, the core team" made a decision when, say, just 35% of us voted. In such case it would be easier for those of us who disagree to claim the decision doesn't really represent the views of the greater core team.
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/
Hi Brett,
On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon <brett@python.org> wrote:
[can I just say how much I've missed having both you and Tim around, Alex? 😃]
Heh, good to hear!-)
Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91)
Uh, sorry, but -- even were you to become BDFL, you don't get to Pronounce
on arithmetic: 2/3 of 91 is 60 (plus a fraction), nowhere near "roughly" 84
(at least not in the US with our Imperial system; does it work any
differently in Canada with Metric?-)...
Alex
On Wed, Jul 18, 2018, 18:09 Alex Martelli, <aleax@google.com> wrote:
Hi Brett,
On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon <brett@python.org> wrote:
[can I just say how much I've missed having both you and Tim around, Alex? 😃]
Heh, good to hear!-)
Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91)
Uh, sorry, but -- even were you to become BDFL, you don't get to Pronounce on arithmetic: 2/3 of 91 is 60 (plus a fraction), nowhere near "roughly" 84 (at least not in the US with our
Imperialsystem; does it work any differently in Canada with Metric?-)...
Sorry, the 82 in my head was from when Lukasz proposed 90%. That's what I get for replying to emails on the bus after a very stressful day at work.
-Brett
Alex
On Wed, Jul 18, 2018, 18:49 Brett Cannon, <brett@python.org> wrote:
On Wed, Jul 18, 2018, 18:09 Alex Martelli, <aleax@google.com> wrote:
Hi Brett,
On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon <brett@python.org> wrote:
[can I just say how much I've missed having both you and Tim around, Alex? 😃]
Heh, good to hear!-)
Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91)
Uh, sorry, but -- even were you to become BDFL, you don't get to Pronounce on arithmetic: 2/3 of 91 is 60 (plus a fraction), nowhere near "roughly" 84 (at least not in the US with our
Imperialsystem; does it work any differently in Canada with Metric?-)...Sorry, the 82 in my head was from when Lukasz proposed 90%. That's what I get for replying to emails on the bus after a very stressful day at work.
And I just checked with the proper number and it goes back about 4 years to 2014.
-Brett
-Brett
Alex
On Wed, Jul 18, 2018 at 10:36 AM Łukasz Langa <lukasz@langa.pl> wrote:
A simple majority vote is wildly insufficient for this case. Python is a large project with many contributors and alienating maybe tens of them is not acceptable, especially if we are talking about a "for life" choice.
+1
-eric
On Jul 18, 2018, at 03:04, Antoine Pitrou <antoine@python.org> wrote:
If we're talking about a dictator (this is Barry's proposal), we're not talking about someone that just makes language design decisions, as Victor pointed out.
I’m talking about a singular leader who has the responsibility and vision to direct Python for as long as they are able and want to. Just as Guido left tons of decisions to others (including this one :), so will the next BDFL. Exactly what that mix of delegation will look like is, in my proposal, up to the NBDFL.
-Barry
On Jul 18, 2018, at 02:49, Ethan Furman <ethan@stoneleaf.us> wrote:
(*) (I'm leaving the "benevolent" part out, since clearly it was only tied to Guido's personality, not to any inherent statutory limitations)
I think that's a mistake. Clearly, the "benevolent" part is a major criteria for the dictator, triumvirate, CoE, or whatever we come up with, and Guido is not the only benevolent core-dev we have.
+1 - completely agree. “Benevolence” is critical IMHO.
-Barry
On Wed, Jul 18, 2018 at 2:43 AM Antoine Pitrou <antoine@python.org> wrote:
Le 18/07/2018 à 04:02, Barry Warsaw a écrit :
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.
Why do you think non-BDFL projects have a problem with """ambiguity as to the authority of said decision"""? What is your basis for that assertion?
I'm worried that you seem to be descending into magical thought, believing for some reason that nothing else than monarchy could ever work for a software project.
tl;dr We worry too much :)
While I do not feel quite the same way on your point, Antoine, I'm glad you brought this up. A blanket policy of monarchy would be a serious problem at the point that a BDFL goes "rogue". However, a blanket opposition to monarchy leads to its own problems. Relative to the BDFL's power, context is significant here.
There is apparently a lot of support (mine included) for Barry's proposal. However, we might be blinded, now and in general, to the possibility of a rogue BDFL by the availability of good candidates (that "clearly" would not go rogue) in the present and struggle to imagine a time that there isn't such a candidate or that we were wrong about them. In fact, IIUC some reputable core devs do not feel like there's any such candidate now (no disrespect, Brett), based on what they expect a BDFL to be. We need to respect that and consider that viewpoint. Regardless of when it happens (if ever), what will happen in the future when we don't have anyone suitable? One danger is that we will install someone un-suitable because "we've always had a BDFL". But what is that "danger"? What impact could a rogue BDFL have?
Before diving in to that, consider that change has a directly proportional relationship with disruption. Disruption to any organization has a pretty high cost, so the effect should be carefully considered before deciding to make changes (which is what we're doing, hopefully). In our case, figuring out how to proceed post-Guido-as-BDFL, we should make sure there's a good reason to change our "governance model". [Really quick: python-dev is rather ad-hoc as an org, so calling it a "governance model" is a bit misleading.] We've been operating (successfully) for decades with a BDFL. As others have indicated, Python greatly owes its success to having a BDFL. Assuming we find a suitable replacement (I think we can), why otherwise disrupt things? "this is our chance to change so we should" is an extremely weak argument on its own (and a dangerous one), as is "monarchs are always bad". There needs to be a stronger reason (one that applies concretely to us). Otherwise, at the least "status quo wins a stalemate" here. Arguably the best course of action would be to change as little as possible.
All that said, I strongly affirm that we should not dismiss concerns and differing opinions. We need to consider them and be respectful. We must resist the temptation to say "let's be real, that isn't something we need to worry about". That's why I'm glad you said what you did, Antoine. It made me think about a few aspects of the status quo that may be worth addressing sooner rather than later. Along those lines, I consider the following questions to be significant. I'll address them a little, but not conclusively.
- what makes a good BDFL?
- what do we do when we can't find a suitable candidate?
- what negative impact can a BDFL have?
- how do we mitigate that impact? how do we deal with a "bad" BDFL?
In my mind the key question is #3 (see my comments below).
- what makes a good BDFL?
This is already being discussed in other threads, e.g. about the "roles" of the BDFL. I'll add that the BDFL is someone we trust to lead Python into the future, even when it's hard and even when we strongly disagree with them. As a core team we rely on the BDFL to help us make hard technical decisions.
However, I supposed I hadn't considered it before, but the BDFL has a much more significant role. The Python community is in many ways a reflection of Guido and a result of his leadership (much more than technical leadership). Consequently, a new BDFL must be someone who reflects where we want the community to be.
- what do we do when we can't find a suitable candidate?
This is worth figuring out. It isn't something we've discussed much. I expect most folks feel like it will never be an issue. I suppose they're right. At the point there isn't a suitable candidate, we have larger problems to address. :)
- what negative impact can a BDFL have?
I was primarily thinking about a "rogue" BDFL, rather that about mistakes an otherwise good one might make. The big question is what does it mean for the BDFL to go "rogue". It definitely isn't "making a decision the people don't agree with" as Guido has done that plenty of times (to our benefit). :) In my mind, the main bad that the BDFL can do is to hurt the community. Their possible negative technical impact is small and highly recoverable.
As the leader of Python, the BDFL is in a position to hurt the project; by offending the Python community, by making Python less appealing to new users, by alienating existing contributors, and by discouraging new contributors. While the BDFL has the final say in changes to the language (through the PEP process), this isn't something easily abused nor hard to repair. Furthermore, the BDFL is otherwise already quite limited in authority and power. For instance, relative to the code they have no special standing; they are one among many committers.
- how do we mitigate that impact? how do we deal with a "bad" BDFL?
People make mistakes. We should expect the BDFL to make them too. We should also expect them to care deeply about Python (as well as align relatively closely with the community). We can deal with their mistakes. :)
However, if the BDFL turns out to be not as capable as we expected (no judgement, Brett) or appears to be purposefully hurting Python then we'd need to act. On the one hand we'd need to deal with the BDFL directly, likely replacing them or more broadly restructuring. On the other had we'd have to deal with the community consequences (the four listed in point #3). The latter is the one with deeper consequences. TBH, the same is true of any structure we apply (e.g. council, majority rule).
I suppose the most we could plan for would be quickly removing a rogue BDFL (but without such a plan hanging over a good BDFL's head). I'd consider Barry's proposal of advisers to be in the right direction. That said, as with #2 this is probably not something that will ever come up.
(Other approaches to project governance might also help mitigate the equivalent effect of a rogue BDFL on the community. However, they make the technical decision-making side of things worse. There are serious trade-offs when more people are involved in the decision-making. I consider sticking with a BDFL worth it.)
You're creating a huge problem here. Whatever dictator you come up with, not everyone will be ok with that choice. What are they supposed to do? If one doesn't think X is legitimate as a dictator, how does one keep contributing to the project? In other words, you are threatening to exclude people, perhaps seasoned contributors.
This is a real issue we need to solve. I'm not sure what we can do though. Not everyone will be happy with any approach we take. That's frustrating because I highly doubt anyone here wants anyone else to feel excluded. I challenge all of us to make this a priority as we consider an approach for replacing Guido. (Hopefully my other comments reflect this priority!)
(*) (I'm leaving the "benevolent" part out, since clearly it was only tied to Guido's personality, not to any inherent statutory limitations)
The "benevolent" part is critical though. Without it none of the rest would work for us. Perhaps I've misunderstood your point? FWIW, the word "dictator" has a lot of negative connotation that does not match our usage in BDFL. I don't mean to suggest that's the only concern here, but would it help to use a different name than BDFL? IIRC, it's either a clever Monty Python reference or a tongue-in-cheek expression from Barry 20 years ago that stuck.
What if we don't subscribe to your views of Brett's qualities: do you expect us to publicly criticize Brett so as to justify our opposition?
Fair enough. I don't mean to put Barry or Brett in an uncomfortable position here, but at the point where we're discussing potential BDFL candidates, we need to be just as open and honest about concerns as about qualifications. However, perhaps we're premature in discussing candidates (before we've decided to stick with a BDFL). While I too would support Brett, I agree that tying Brett to the BDFL proposal makes the discussion harder when there is opposition, which obviously there is. So we should probably focus just on the BDFL proposal itself and then move on to the candidates once (if) that's settled.
Your proposal is turning this discussion into some kind of Napoleonic plebiscite. This is frankly unpleasant :-/
:(
We definitely need to be honest (and respectful) here so thanks for expressing that. I'm hopeful we can all work together to find a solution that will benefit Python going forward. Let's take this as an opportunity to understand each other's viewpoints and get on the same page. Let's build on the basis that we have in common.
In summary, we're a relatively as-hoc, unorganized group without much structure to bind us down. This has worked because we've had an effective BDFL. Even if we get things wrong now by changing minimally, there is no real blocker to fixing things later (except *maybe* momentum). However if we add a bunch of structure there's a risk that we'll find it hard to undo. Ultimately, we should be careful about premature optimization.
-eric
On Jul 18, 2018, at 10:13, Eric Snow <ericsnowcurrently@gmail.com> wrote:
Regardless of when it happens (if ever), what will happen in the future when we don't have anyone suitable? One danger is that we will install someone un-suitable because "we've always had a BDFL". But what is that "danger"? What impact could a rogue BDFL have?
I’m not concerned about that, and not just because I’m secretly wishing for a filibuster until I get to join Guido on the Isle of Former Pythonistas Who Know Prefer To Sip Margaritas In Peace and Quiet and No Internet.
Grooming suitable future leaders is critical to the relevance of Python for the next 30 years. I’m confident that when the time comes, there will be obvious choices, just as there has been for Release Managers. And if there really isn’t then future archeologists will point to this thread and say “maybe now we can experiment with a Supreme Council”.
- what makes a good BDFL?
- what do we do when we can't find a suitable candidate?
- what negative impact can a BDFL have?
- how do we mitigate that impact? how do we deal with a "bad" BDFL?
I’d like to add: how do we ensure that we will have many suitable candidates if and when the time comes to choose the N+1BDFL?
However, I supposed I hadn't considered it before, but the BDFL has a much more significant role. The Python community is in many ways a reflection of Guido and a result of his leadership (much more than technical leadership). Consequently, a new BDFL must be someone who reflects where we want the community to be.
To me, that’s the “vision” question, but I think the BDFL doesn’t just reflect the communities wishes, because “the community” will never agree 100% on anything. Which, FTR, I think is okay. The BDFL uses their intuition, compassion, and experience to move Python forward according to their vision for what the language should be, deeply informed by —but not subservient to— the opinions of all its users and developers, because that’s essentially impossible.
- what do we do when we can't find a suitable candidate?
This is worth figuring out. It isn't something we've discussed much. I expect most folks feel like it will never be an issue. I suppose they're right. At the point there isn't a suitable candidate, we have larger problems to address. :)
Indeed. I’d say that we should be proactive so that we never get into that position, by beginning to groom future NBDFLs now.
- what negative impact can a BDFL have?
I was primarily thinking about a "rogue" BDFL, rather that about mistakes an otherwise good one might make. The big question is what does it mean for the BDFL to go "rogue". It definitely isn't "making a decision the people don't agree with" as Guido has done that plenty of times (to our benefit). :) In my mind, the main bad that the BDFL can do is to hurt the community. Their possible negative technical impact is small and highly recoverable.
That’s a good point, except that there is usually a window of practical recoverability. For example, once Python 3.8 is released, PEP 572 will be very very difficult to undo.
- how do we mitigate that impact? how do we deal with a "bad" BDFL?
People make mistakes. We should expect the BDFL to make them too. We should also expect them to care deeply about Python (as well as align relatively closely with the community). We can deal with their mistakes. :)
However, if the BDFL turns out to be not as capable as we expected (no judgement, Brett) or appears to be purposefully hurting Python then we'd need to act. On the one hand we'd need to deal with the BDFL directly, likely replacing them or more broadly restructuring. On the other had we'd have to deal with the community consequences (the four listed in point #3). The latter is the one with deeper consequences. TBH, the same is true of any structure we apply (e.g. council, majority rule).
I suppose the most we could plan for would be quickly removing a rogue BDFL (but without such a plan hanging over a good BDFL's head). I'd consider Barry's proposal of advisers to be in the right direction. That said, as with #2 this is probably not something that will ever come up.
Thanks Eric, these are good points to consider.
The "benevolent" part is critical though. Without it none of the rest would work for us. Perhaps I've misunderstood your point? FWIW, the word "dictator" has a lot of negative connotation that does not match our usage in BDFL. I don't mean to suggest that's the only concern here, but would it help to use a different name than BDFL? IIRC, it's either a clever Monty Python reference or a tongue-in-cheek expression from Barry 20 years ago that stuck.
I’d put my money on Uncle Timmy coining that term, but maybe you’re on to something here. Okay, let’s call our leader “Dinsdale”. As in, who will be the Next Dinsdale?
Fair enough. I don't mean to put Barry or Brett in an uncomfortable position here, but at the point where we're discussing potential BDFL candidates, we need to be just as open and honest about concerns as about qualifications. However, perhaps we're premature in discussing candidates (before we've decided to stick with a BDFL). While I too would support Brett, I agree that tying Brett to the BDFL proposal makes the discussion harder when there is opposition, which obviously there is. So we should probably focus just on the BDFL proposal itself and then move on to the candidates once (if) that's settled.
FWIW, I would not expect PEP 2 to name a Next Dinsdale, er BDFL, er…
I have been thinking that PEP 3 would serve as the Historical Record of Past And Future Leaders.
We definitely need to be honest (and respectful) here so thanks for expressing that. I'm hopeful we can all work together to find a solution that will benefit Python going forward. Let's take this as an opportunity to understand each other's viewpoints and get on the same page. Let's build on the basis that we have in common.
In summary, we're a relatively as-hoc, unorganized group without much structure to bind us down. This has worked because we've had an effective BDFL. Even if we get things wrong now by changing minimally, there is no real blocker to fixing things later (except *maybe* momentum). However if we add a bunch of structure there's a risk that we'll find it hard to undo. Ultimately, we should be careful about premature optimization.
Well put! I’d also caution against excessive pessimism. :)
Cheers, -Barry
[Barry Warsaw, on the origin of BDFL]
I’d put my money on Uncle Timmy coining that term,
Don't be insulting, Barry. I have no patience - let alone love - for frivolous wordplay.
It wasn't me, but Guido doesn't remember either. Here's his best guess:
https://www.artima.com/weblogs/viewpost.jsp?thread=235725
Short course: BDFL first appeared in a 1995 email sent by Ken Manheimer summarizing a PSA meeting. Guido was apparently named at that meeting as
*First Interim Benevolent Dicator* [sic]* for Life*
and
While I can't prove my title (with or without the First Interim prefix) was
never used before, I'm pretty certain that it originated in this meeting. Given what I know of how their minds work, it was most likely invented by Ken Manheimer or Barry Warsaw, though it may well have been a joint invention by all present.
Some titles just _fit_. Like Kim Jong Il's
Great Man, Who Is a Man of Deeds
and
Dear Leader, who is a perfect incarnation of the appearance that a leader should have
More inspiring ideas where those came from:
https://en.wikipedia.org/wiki/List_of_Kim_Jong-il%27s_titles
On Jul 18, 2018, at 01:43, Antoine Pitrou <antoine@python.org> wrote:
Why do you think non-BDFL projects have a problem with """ambiguity as to the authority of said decision"""? What is your basis for that assertion?
With more people empowered to make a binding decision as part of a Supreme Council, there will be more uncertainty in the authority of the person pronouncing. Part of that will be because the pronouncement can come from any of the member of the Council, and part may come from more turnover in the Council membership. I’m not at all concerned about *us* accepting that authoritative decision because we are are deeply invested in Python’s governance. But I claim that the vast majority of Python users are not, so while they recognize Guido’s name as the (former) leader, I question whether they will be able to have the same certainty in the authority of a decision coming from 3 or 5 people who’s names they are not familiar with. With a singular leader, it will be easier to communicate the authority of that leader.
So yeah, maybe it’s a PR problem, but it’s still important nonetheless.
I'm worried that you seem to be descending into magical thought, believing for some reason that nothing else than monarchy could ever work for a software project.
We’re not talking about software project governance in general, we’re talking about Python specifically. And Python has had a strong singular leader with a clear vision for its entire nearly 30 year life. Yes, I personally question whether a Supreme Council will work for Python.
Since you're opening this can of worms, I'll say it:
- I'm -1 on a new dictator-for-life (*)
Let me be clear: “BDFL” is a convenient term with a well-known meaning. In fact, I believe *we* coined that term that’s now often used in other open source projects. But as Guido has eloquently demonstrated, the “For Life” part really means “For As Long As They Want To Do It”. In other words, it’s just a title for the job. In my proposal, it really means “For As Long As They Want To Do It And They Don’t Do Something Evil Enough To Get Impeached”. I’m spelling that title with the initialism “BDFL” :)
- I'm -1 on Brett Cannon as a new dictator-for-life
Of one thing I have absolutely no doubt: no decision in Python will ever be unanimous! That kind of proves my point as to why a singular leader is necessary. :)
You're creating a huge problem here. Whatever dictator you come up with, not everyone will be ok with that choice. What are they supposed to do? If one doesn't think X is legitimate as a dictator, how does one keep contributing to the project? In other words, you are threatening to exclude people, perhaps seasoned contributors.
How is that any different with a Supreme Council rather than a singular leader? Whatever makeup of the Council we come up with, not everyone will be okay with those choices. What are they supposed to do?
Ultimately you’re right. There are zillions of reasons not to contribute to Python, so having no confidence in its leadership is just one more. Fortunately, only you get to decide whether your reasons not to contribute outweigh your reasons to contribute. And further, it’s open source, so you are *always* welcome to fork. Look at Devuan <https://en.wikipedia.org/wiki/Devuan>.
I’ve long said — somewhat in jest, since I never expected Guido to actually ever retire! — that Brett would be my choice for the next BDFL. I think he’s the perfect candidate, and he’s already demonstrated qualities that I think make him a fantastic leader.
I bed to disagree, Barry. Brett is a good contributor, that doesn't make him legitimate as a dictator. Only Guido could be, and he has stepped down.
The amount of cheerleading here ("""smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills""") is embarrassing. What if we don't subscribe to your views of Brett's qualities: do you expect us to publicly criticize Brett so as to justify our opposition?
Also fortunately, I don’t get to unilaterally decide this! I get to propose a plan, make my arguments, try to persuade, and cast my one vote — hopefully, depending on the criteria. Just like all of you. :)
(Maybe we don’t count anybody who has more hair on his chin now than his head when he first started using Python, in which case, I’m definitely forking what I’ll call UncleTimmython).
Cheers, -Barry
Le 18/07/2018 à 19:51, Barry Warsaw a écrit :
On Jul 18, 2018, at 01:43, Antoine Pitrou <antoine@python.org> wrote:
Why do you think non-BDFL projects have a problem with """ambiguity as to the authority of said decision"""? What is your basis for that assertion?
With more people empowered to make a binding decision as part of a Supreme Council, there will be more uncertainty in the authority of the person pronouncing.
I don't really follow you. If you have a collegial body (a Council), it's the Council as a whole that has the authority to pronounce. Not any singular member of the Council (unless the Council functions as a miniature monarchy, that is). So the "person pronouncing" is the Council.
(Imagine a parliamentary regime: when a parliament decides on a law, it's the parliament's authority that makes the law valid in the eyes of every citizen. It does not matter which representatives exactly voted on a given piece of law.)
Of one thing I have absolutely no doubt: no decision in Python will ever be unanimous! That kind of proves my point as to why a singular leader is necessary. :)
That doesn't prove anything. A dictator is not needed to make up for the lack of unanimity (fortunately! otherwise we would all live under dictatorships...).
You're creating a huge problem here. Whatever dictator you come up with, not everyone will be ok with that choice. What are they supposed to do? If one doesn't think X is legitimate as a dictator, how does one keep contributing to the project? In other words, you are threatening to exclude people, perhaps seasoned contributors.
How is that any different with a Supreme Council rather than a singular leader? Whatever makeup of the Council we come up with, not everyone will be okay with those choices. What are they supposed to do?
Well, there is a large difference between a dictator-for-life and, for example, a collegial body that gets renewed from time to time. The latter is probably easier to compromise with, even for those who don't like its makeup.
Regards
Antoine.
On 07/17/2018 07:02 PM, Barry Warsaw wrote:
TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that helps the BDFL in various capacities, with additional responsibilities.
Having a singular BDFL certainly has its advantages, and from my interactions with Brett I certainly would have no qualms about supporting him in that role.
More in-line devil's advocate comments below.
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”.
If the council appointments are for life, it shouldn't take too long to figure out.
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”.
I suspect that will occasionally happen -- I don't know that it's a big enough issue to make the NBDFL model the obvious choice.
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 think this is the crux of the argument: getting a group of people, even a small one, to agree on a singular vision can be very difficult.
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.
Community support can be mercurial, and should not be relied upon as an underpinning of our governance model.
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.
I am sure that those questions will be difficult for a BDFL, a council, a membership majority, or whatever system we choose.
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 directly detrimental to Python, the council should be able to effectively impeach. There should be checks and balances on this power, the BDFL shouldn’t continuously fear a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for when the BDFL is abusing their power.
In other words, a more complicated tyranny of the majority.
- The council would select the next BDFL if and when that time comes. No one will serve forever, so a clear succession plan should be in place. To avoid the tyranny of the majority, the council would serve similarly to a board of directors. They’d search for candidates, match them against well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL.
Why should the council have that power? If the core-devs are selecting the NBDFL now, I see no reason why we shouldn't in the future as well.
- The council would serve as trusted advisors to the NBDFL. The BDFL won’t be out there all alone! The council will provide advice when requested, and back up the BDFL when needed. The council helps legitimize the BDFL and their decisions.
This doesn't sound significantly different from just a council without a BDFL. Besides which, whichever model we choose, the fact that we chose it should be legitimizing enough.
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 think an NBDFL model could work, but I find the supplemental CoA unnecessary. If we are worried about Evil Corp subverting our BDFL, then we could go with NBDF10years (or something) instead (with possible/probable reinstatement).
Thank you, Barry, for taking the time to put your thoughts into words!
-- ~Ethan~
On Jul 18, 2018, at 03:31, Ethan Furman <ethan@stoneleaf.us> wrote:
I think this is the crux of the argument: getting a group of people, even a small one, to agree on a singular vision can be very difficult.
Yep.
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.
Community support can be mercurial, and should not be relied upon as an underpinning of our governance model.
No? I think it’s critical.
Here’s a thought experiment: Pretend that PEP 572 were in front of the Supreme Council. How do you think the discussions would go? Would your opinion for or against be weighed with sufficient deliberation? Would the PEP have undergone the rewrites it did in order to address the concerns early on? Would you have confidence in the decision of the Council, whether it went your way or not? If you lost the argument, how would you react? How would any of that be different with a singular leader? Would it matter to you if that leader was not Guido?
Cheers, -Barry
participants (25)
-
Alex Martelli -
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Carol Willing -
Chris Jerdonek -
Donald Stufft -
Doug Hellmann -
Eric Snow -
Eric V. Smith -
Ethan Furman -
Fred Drake -
Jack Jansen -
Kushal Das -
M.-A. Lemburg -
Mariatta Wijaya -
Nathaniel Smith -
Ned Deily -
Nick Coghlan -
Paul Moore -
Senthil Kumaran -
Steve Dower -
Tim Peters -
Victor Stinner -
Łukasz Langa