Hi,

2018-07-12 16:57 GMT+02:00 Guido van Rossum guido@python.org:

Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions.

Thank you for having solved the long standing issue of the PEP 572: taking a decision was the only way to stop the flood of emails on mailing lists (python-dev for the latest one)!

I'm sure that it was super hard and painful to take a decision on the PEP, especially the most unpopular decision... approving it! I'm not sure how it happened, but I started to like the new syntax :-)

I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own.

Wow! That's huge! One day, Larry Hastings told me that Python is your project ("toy"? I don't recall), but sometimes you let us to play with it :-) Thank you for having let us to play with it! Thank you for your 25 years of service as a BDFL!

I am not going to appoint a successor.

So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?

The decisions that most matter are probably

• How are PEPs decided
• How are new core devs inducted

For PEPs, I already told you in private about the PHP process to take a decision on a RFC: vote where the majority wins. I like that. The vote is reserved to core developers. I would like to experiment that in Python. I expect that only some core developers would vote depending on the PEP, since we are no experts in everything. For example, I'm not following anything about distutils and I'm happy that Nick Coghlan and now Paul Moore handle these PEPs!

https://twitter.com/ncoghlan_dev/status/1015420826177265665

Nick Coghlan‏: "End of an era: after ~5 years, I decided that it's time to hand over the responsibilities of default Python packaging interoperability PEP approval. Paul Moore has graciously agreed to take on that task: https://mail.python.org/mm3/archives/list/distutils-sig@python.org/thread/QT... "

I'm not sure what to do in case of equal number of votes. Maybe we need a dictator per PEP. Or at least per area of the code :-) We already have kind of experts per area.

I'll still be here, but I'm trying to let you all figure something out for yourselves. I'm tired, and need a very long break.

A well deserved break ;-)

Victor

I think it would be worth studying the governance structure (*) of a bunch of open source projects picked according to a set of criteria:

• major project in # of users and contributors
• non BDFL-governed
• mostly volunteer-driven
• with an established decision process for major enhancements

(*) (e.g. as an informational PEP)

Regards

Antoine.

Le 12/07/2018 à 17:55, Christian Heimes a écrit :

On 2018-07-12 16:57, Guido van Rossum wrote:

...

Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions.

I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own.

After all that's eventually going to happen regardless -- there's still that bus lurking around the corner, and I'm not getting younger... (I'll spare you the list of medical issues.)

I am not going to appoint a successor.

So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?

Thanks for being our beloved BDFL for so many years!

The mail doesn't come to an suprise, although I didn't think it would hit my inbox this year or next year. I've been pondering about possible succession for you for a while. In my opinion we need some trusted entity to have final say. Otherwise we are going to waste^H^H^H^H^H spend too much time in bike shedding. But I don't see one clear person to take your place as BDFL.

How about a form of presbyterian polity in the form of a triumvirate or quintumvirate? (For those with a lucky childhood that didn't involve Latin and Greek: ruling of elders with three or five powerful individuals). It would spread the load and responsibilities between multiple core devs.

I would consider (in alphabetical order) Barry, Brett, Mariatta, Mark, Nick, or Victor as potential members. Each persons has been a core dev for a long time and would brings a unique perspective into the quintumvirate. For example Mark Shannon has an academic background in language design.

Regards, Christian

---

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 12/07/18 15:57, Guido van Rossum wrote:

Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions.

I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own.

Thanks for all your work. You should be very proud of all you have achieved.

I expect I am not alone on this list in saying that Python has changed my life, and mostly for the better :)

After all that's eventually going to happen regardless -- there's still that bus lurking around the corner, and I'm not getting younger... (I'll spare you the list of medical issues.)

I am not going to appoint a successor.

So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?

I'm not worried about the day to day decisions in the issue tracker or on GitHub. Very rarely I get asked for an opinion, and usually it's not actually important. So this can just be dealt with as it has always been.

The decisions that most matter are probably

• How are PEPs decided
• How are new core devs inducted

We may be able to write up processes for these things as PEPs (maybe those PEPs will form a kind of constitution). But here's the catch. I'm going to try and let you all (the current committers) figure it out for yourselves.

Note that there's still the CoC -- if you don't like that document your only option might be to leave this group voluntarily. Perhaps there are issues to decide like when should someone be kicked out (this could be banning people from python-dev or python-ideas too, since those are also covered by the CoC).

Finally. A reminder that the archives of this list are public (https://mail.python.org/pipermail/python-committers/) although membership is closed (limited to core devs).

I'll still be here, but I'm trying to let you all figure something out for yourselves. I'm tired, and need a very long break.

Enjoy your break. You deserve it.

Cheers, Mark.

On Thu, 12 Jul 2018 at 07:58 Guido van Rossum guido@python.org wrote:

Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions.

I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own.

Like Christian, I was hoping we had a couple more years of your direct guidance, but I understand how the PEP 572 situation accelerated things. :(

After all that's eventually going to happen regardless -- there's still that bus lurking around the corner, and I'm not getting younger... (I'll spare you the list of medical issues.)

I am not going to appoint a successor.

So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?

I'm not worried about the day to day decisions in the issue tracker or on GitHub. Very rarely I get asked for an opinion, and usually it's not actually important. So this can just be dealt with as it has always been.

The decisions that most matter are probably

• How are PEPs decided
• How are new core devs inducted

We may be able to write up processes for these things as PEPs (maybe those PEPs will form a kind of constitution). But here's the catch. I'm going to try and let you all (the current committers) figure it out for yourselves.

At this point I've seen proposed:

• Christian's proposal for a triumvirate (and thanks for the vote of confidence, Christian, to be on said cabal/committee :)
• Victor's proposal of voting for every PEP
• Do essentially a literary review of how other projects handle this

For me, I think a key asset that Guido has provided for us as a BDFL is consistency in design/taste. Design by committee through voting does not appeal to me at all as that can too easily lead to shifts in preferences and not have the nice cohesion we have with the language's overall design, especially considering that there will always be subjective choices to make (someone has to eventually choose the colour of the shed). People, including me, have also pointed out that by having Guido to look up to you we have had a very consistent view of how the community should behave and that too has been an asset. IOW I don't like Victor's proposal. ;)

What that means is I think we should either have another BDFL or go with Christian's triumvirate suggestion in the name of general consistency and guidance (and I personally don't like the four-person suggestion simply because you can't break ties).

There's also no objective way to choose any of this unfortunately, so I suspect this is going to be based on gut feel of what we think will work for a couple of decades (using the word "experiment" with our design governance model scares me since we are not talking about little decisions here like whether to backport a fix). If people still want to put into the time to research other approaches I can understand that I will personally listen with an open mind, but based on my personal reflections on this topic over the years in preparation of having to eventually deal with this inevitability, my choice is dictator or triumvirate.

Note that there's still the CoC -- if you don't like that document your only option might be to leave this group voluntarily. Perhaps there are issues to decide like when should someone be kicked out (this could be banning people from python-dev or python-ideas too, since those are also covered by the CoC).

I joined the PSF's CoC committee in hopes of coming up with a proposal by the end of the year for fleshing out details of enforcement, etc., so my hope is this will eventually get resolved.

-Brett

Finally. A reminder that the archives of this list are public ( https://mail.python.org/pipermail/python-committers/) although membership is closed (limited to core devs).

I'll still be here, but I'm trying to let you all figure something out for yourselves. I'm tired, and need a very long break.

-- --Guido van Rossum (python.org/~guido)

---

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/

Thank you, Guido. This is a sad day for me personally; I really hoped you'd lead Python for a few more years. On the other hand, Python is in good hands, you've built a large enough and diverse community around it!

As for the new governing model, I imagine that we don't need to make any decisions *right now*. As Victor suggested, core devs can simply count +1/-1 on any language feature and we'll see how it goes. Or maybe the first such vote should be on the new governing model? :) I really hope that we won't have an excruciating debate on the mailing list about the governing model though; maybe we can discuss it on the upcoming core dev sprint.

Yury

On Thu, Jul 12, 2018 at 10:58 AM Guido van Rossum guido@python.org wrote:

Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions.

I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own.

After all that's eventually going to happen regardless -- there's still that bus lurking around the corner, and I'm not getting younger... (I'll spare you the list of medical issues.)

I am not going to appoint a successor.

So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?

I'm not worried about the day to day decisions in the issue tracker or on GitHub. Very rarely I get asked for an opinion, and usually it's not actually important. So this can just be dealt with as it has always been.

The decisions that most matter are probably

• How are PEPs decided
• How are new core devs inducted

We may be able to write up processes for these things as PEPs (maybe those PEPs will form a kind of constitution). But here's the catch. I'm going to try and let you all (the current committers) figure it out for yourselves.

Note that there's still the CoC -- if you don't like that document your only option might be to leave this group voluntarily. Perhaps there are issues to decide like when should someone be kicked out (this could be banning people from python-dev or python-ideas too, since those are also covered by the CoC).

Finally. A reminder that the archives of this list are public (https://mail.python.org/pipermail/python-committers/) although membership is closed (limited to core devs).

I'll still be here, but I'm trying to let you all figure something out for yourselves. I'm tired, and need a very long break.

-- --Guido van Rossum (python.org/~guido)

---

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/

-- Yury

I'd like to point out that the N-virate idea doesn't handle a key issue: once you have a N-virate, how do you evolve its composition according to the implication and motivation of its members - but also to remarks or frustation by non-virate contributors (especially new contributors who will feel there's a perpetual category they're locked out of)? Do you just wait for people to gently step down when required?

One key point about Guido is that not only he's the founder of the project, but he's been consistently be there all the time, with almost no interruptions. I don't think any of us can claim such an uninterrupted presence, neither in the past, nor in the long future.

The suggestion about studying other projects was not to do a "literary review" but simply to look at what works well for other projects.

Regards

Antoine.

Le 12/07/2018 à 18:48, Brett Cannon a écrit :

On Thu, 12 Jul 2018 at 07:58 Guido van Rossum mailto:guido@python.org> wrote:

Now that PEP 572 is done, I don't ever want to have to fight so hard
for a PEP and find that so many people despise my decisions.

I would like to remove myself entirely from the decision process.
I'll still be there for a while as an ordinary core dev, and I'll
still be available to mentor people -- possibly more available. But
I'm basically giving myself a permanent vacation from being BDFL,
and you all will be on your own.

Like Christian, I was hoping we had a couple more years of your direct guidance, but I understand how the PEP 572 situation accelerated things. :(

After all that's eventually going to happen regardless -- there's
still that bus lurking around the corner, and I'm not getting
younger... (I'll spare you the list of medical issues.)

I am not going to appoint a successor.

So what are you all going to do? Create a democracy? Anarchy? A
dictatorship? A federation?

I'm not worried about the day to day decisions in the issue tracker
or on GitHub. Very rarely I get asked for an opinion, and usually
it's not actually important. So this can just be dealt with as it
has always been.

The decisions that most matter are probably
- How are PEPs decided
- How are new core devs inducted

We may be able to write up processes for these things as PEPs (maybe
those PEPs will form a kind of constitution). But here's the catch.
I'm going to try and let you all (the current committers) figure it
out for yourselves.

At this point I've seen proposed:

• Christian's proposal for a triumvirate (and thanks for the vote of confidence, Christian, to be on said cabal/committee :)
• Victor's proposal of voting for every PEP
• Do essentially a literary review of how other projects handle this

For me, I think a key asset that Guido has provided for us as a BDFL is consistency in design/taste. Design by committee through voting does not appeal to me at all as that can too easily lead to shifts in preferences and not have the nice cohesion we have with the language's overall design, especially considering that there will always be subjective choices to make (someone has to eventually choose the colour of the shed). People, including me, have also pointed out that by having Guido to look up to you we have had a very consistent view of how the community should behave and that too has been an asset. IOW I don't like Victor's proposal. ;)

What that means is I think we should either have another BDFL or go with Christian's triumvirate suggestion in the name of general consistency and guidance (and I personally don't like the four-person suggestion simply because you can't break ties).

There's also no objective way to choose any of this unfortunately, so I suspect this is going to be based on gut feel of what we think will work for a couple of decades (using the word "experiment" with our design governance model scares me since we are not talking about little decisions here like whether to backport a fix). If people still want to put into the time to research other approaches I can understand that I will personally listen with an open mind, but based on my personal reflections on this topic over the years in preparation of having to eventually deal with this inevitability, my choice is dictator or triumvirate.

Note that there's still the CoC -- if you don't like that document
your only option might be to leave this group voluntarily. Perhaps
there are issues to decide like when should someone be kicked out
(this could be banning people from python-dev or python-ideas too,
since those are also covered by the CoC).

I joined the PSF's CoC committee in hopes of coming up with a proposal by the end of the year for fleshing out details of enforcement, etc., so my hope is this will eventually get resolved.

-Brett

Finally. A reminder that the archives of this list are public
(https://mail.python.org/pipermail/python-committers/) although
membership is closed (limited to core devs).

I'll still be here, but I'm trying to let you all figure something
out for yourselves. I'm tired, and need a very long break.

-- 
--Guido van Rossum (python.org/~guido <http://python.org/~guido>)
_______________________________________________
python-committers mailing list
python-committers@python.org <mailto: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 12Jul2018 0958, Antoine Pitrou wrote:

I'd like to point out that the N-virate idea doesn't handle a key issue: once you have a N-virate, how do you evolve its composition according to the implication and motivation of its members - but also to remarks or frustation by non-virate contributors (especially new contributors who will feel there's a perpetual category they're locked out of)? Do you just wait for people to gently step down when required?

One of the important things we will have to do is define the scope of any long-term appointees. For example, saying "we have an N-virate that decides on PEPs" is very different from saying "we have an N-virate that decides on the PEP approver (formerly BDFL-delegates)". The latter does not necessarily lock anyone out from being a critical part of Python's future, but it does avoid endless arguments about selecting who is responsible with deciding.

I'm honestly not very sympathetic towards "locking out" new contributors from literally leading a project. As you say below, few of us can claim as long and as uninterrupted a presence in this project as Guido, but many of us can certainly claim more "right" to a say than some random person who probably ought to build a few of their own languages before deeming themselves worthy to significantly influence a well established one.

One key point about Guido is that not only he's the founder of the project, but he's been consistently be there all the time, with almost no interruptions. I don't think any of us can claim such an uninterrupted presence, neither in the past, nor in the long future.

This is the main reason for having more than one person be on the critical path for significant changes. It is easier to replace 33% of a group without losing continuity than to replace 100%.

For me, I would like the release manager to also take on some of the responsibility for new features in their releases. Perhaps holding one position in an N-virate for the current RM (who continue rotating every two releases) is a good way to keep things fresh?

Cheers, Steve

On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou antoine@python.org wrote:

I'd like to point out that the N-virate idea doesn't handle a key issue: once you have a N-virate, how do you evolve its composition according to the implication and motivation of its members - but also to remarks or frustation by non-virate contributors (especially new contributors who will feel there's a perpetual category they're locked out of)? Do you just wait for people to gently step down when required?

One way would be to re-elect them every 5 or so years. Essentially, an N-virate is a dictator-like entity for a few years.

Yury

Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400:

On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou antoine@python.org wrote:

...

I'd like to point out that the N-virate idea doesn't handle a key issue: once you have a N-virate, how do you evolve its composition according to the implication and motivation of its members - but also to remarks or frustation by non-virate contributors (especially new contributors who will feel there's a perpetual category they're locked out of)? Do you just wait for people to gently step down when required?

One way would be to re-elect them every 5 or so years. Essentially, an N-virate is a dictator-like entity for a few years.

Yury

We've had good luck in the OpenStack community tying leadership to release cycles. It causes elections more often (our cycles are 6 months long), but people tend to step up for several cycles in a row so that hasn't been a cause of excessive turnover. Having frequent opportunities for folks to step down gracefully when they need or want to also means no one feels like they are signing up for an indefinite time commitment.

For a multi-person group, staggered elections where only a portion of the group is up for election at one time, also provides some consistency when there is turnover.

Doug

On Thu, 12 Jul 2018 at 10:42 Eric Snow ericsnowcurrently@gmail.com wrote:

On Thu, Jul 12, 2018 at 10:55 AM Yury Selivanov yselivanov.ml@gmail.com wrote:

...

Thank you, Guido. This is a sad day for me personally; I really hoped you'd lead Python for a few more years. On the other hand, Python is in good hands, you've built a large enough and diverse community around it!

+1

Thank you for putting so much time, effort, and care into both the language and its community! We cannot thank you enough.

...

As for the new governing model, I imagine that we don't need to make any decisions *right now*. As Victor suggested, core devs can simply count +1/-1 on any language feature and we'll see how it goes. Or maybe the first such vote should be on the new governing model? :) I really hope that we won't have an excruciating debate on the mailing list about the governing model though; maybe we can discuss it on the upcoming core dev sprint.

In the short term we could appoint a *temporary* triumvirate to fill in as BDFL (with the intent to re-assess the situation in September if we haven't resolved on a permanent solution by then). That would allow us to maintain business-as-usual (and try out a triumvirate). If we go that route then I'd recommend Brett, Nick, and Barry.

Thanks for the vote of confidence. :)

One other idea if we go the BDFL or triumvirate route is we could ask Guido to choose (if he's willing). I think Guido's key point is he wants us to choose how we want to keep this team going, but that may not preclude us to essentially naming him BDFL-delegate in this instance. :)

On Thu, Jul 12, 2018 at 11:55 AM Brett Cannon brett@python.org wrote:

One other idea if we go the BDFL or triumvirate route is we could ask Guido to choose (if he's willing). I think Guido's key point is he wants us to choose how we want to keep this team going, but that may not preclude us to essentially naming him BDFL-delegate in this instance. :)

+1

-eric

On Thu, Jul 12, 2018 at 1:50 PM Brett Cannon brett@python.org wrote: [..]

...

One way would be to re-elect them every 5 or so years. Essentially, an N-virate is a dictator-like entity for a few years.

But that doesn't help deal with inconsistency since that just means we have consistency for 2 releases and then we start all over again. If you're suggesting someone forcibly rotates out every 5 years then that's different since that adds in some consistency thanks to the remaining two members.

My worry is that not everybody can stick to to be with Python for a few decades like Guido. Ideally, there should be a mechanism for both leaving the N-virate and being appointed to it.

Another worry -- Guido knows mostly everything about all aspects of Python design in all fields. To illustrate my point, I'm particularly worried about async/await, asyncio/trio/twisted ecosystem -- so far it seems that it's only Guido and I who've spent a huge chunk of their time maintaining (or caring about) it. We have many other critical fields besides async: general language design, packaging, scientific ecosystem, web (partially overlaps with async), performance, etc. Essentially we need to build our N-virate to have knowledgable representatives (formally known as BDFL-delegates) from all of those fields, otherwise the language can stop evolving in some important directions.

IOW I don't see anyone (or some group of 3) who is as well-versed in everything on Guido's level. That can be solved if Guido agrees to join the permanent N-virate though :)

Yury

Le 12/07/2018 à 19:55, Brett Cannon a écrit :

One other idea if we go the BDFL or triumvirate route is we could ask Guido to choose (if he's willing). I think Guido's key point is he wants us to choose how we want to keep this team going, but that may not preclude us to essentially naming him BDFL-delegate in this instance. :)

That might be a minority view, but I don't think anyone except Guido would be legitimate as a Python BDFL. Not even Tim or Barry ;-)

Regards

Antoine.

On Thu, 12 Jul 2018 at 11:02 Yury Selivanov yselivanov.ml@gmail.com wrote:

On Thu, Jul 12, 2018 at 1:50 PM Brett Cannon brett@python.org wrote: [..]

...

...

One way would be to re-elect them every 5 or so years. Essentially, an N-virate is a dictator-like entity for a few years.

But that doesn't help deal with inconsistency since that just means we have consistency for 2 releases and then we start all over again. If you're suggesting someone forcibly rotates out every 5 years then that's different since that adds in some consistency thanks to the remaining two members.

My worry is that not everybody can stick to to be with Python for a few decades like Guido. Ideally, there should be a mechanism for both leaving the N-virate and being appointed to it.

I'm assuming that's what would be the next step if we decide this N-virate approach is agreed to. Like when you talk about every 5 years, can people stand back up and just consistently re-join, or is is 5 years and then you have to rotate out?

Another worry -- Guido knows mostly everything about all aspects of Python design in all fields. To illustrate my point, I'm particularly worried about async/await, asyncio/trio/twisted ecosystem -- so far it seems that it's only Guido and I who've spent a huge chunk of their time maintaining (or caring about) it. We have many other critical fields besides async: general language design, packaging, scientific ecosystem, web (partially overlaps with async), performance, etc. Essentially we need to build our N-virate to have knowledgable representatives (formally known as BDFL-delegates) from all of those fields, otherwise the language can stop evolving in some important directions.

Yes, Guido has a unique skill set. Having said that, one would also hope that anyone chosen to do this would be up for learning a few new things. ;) This is also why Guido delegated to folks on occasion and talked to experts for opinions, something I expect people chosen to do this would

IOW I don't see anyone (or some group of 3) who is as well-versed in everything on Guido's level. That can be solved if Guido agrees to join the permanent N-virate though :)

No one has suggested we haven't been extremely lucky for the past 28 years. :) I also don't think we will reach perfection in any solution anyway and this is somewhat of a "least bad" situation.

I'm sure I will have more (public) comments later, but for now I'd like to limit myself to one thing:

On Thu, Jul 12, 2018 at 11:41:52AM -0600, Eric Snow wrote:

In the short term we could appoint a *temporary* triumvirate to fill in as BDFL (with the intent to re-assess the situation in September if we haven't resolved on a permanent solution by then). That would allow us to maintain business-as-usual (and try out a triumvirate). If we go that route then I'd recommend Brett, Nick, and Barry.

https://www.python.org/dev/peps/pep-0401/

-- Steve

[Antoine Pitrou]

...

That might be a minority view, but I don't think anyone except Guido

...

would be legitimate as a Python BDFL. Not even Tim or Barry ;-)

A majority view is probably an incorrect view anyway.

If Barry had been BDFL all along, only features useful to Mailman would have gotten in ;-)

If I had been,

• generators would have been in the language years earlier

• but async gimmicks still wouldn't be in

• ternary if would not have been added (too little bang for the buck)

• assignment expressions either (yup, I want them! but I wouldn't have had the guts to persevere against such intense community opposition)

• etc etc etc

The details don't matter. The point is that, at heart, Python is what it is because Guido is who he is. No matter what we do when he steps down, Python will change in a fundamental way.

_Now_ is the time to spread FUD via republishing Stroustrup's essay on the Vasa ;-)

Le 12/07/2018 à 20:22, Doug Hellmann a écrit :

Excerpts from Brett Cannon's message of 2018-07-12 11:11:49 -0700:

...

On Thu, 12 Jul 2018 at 11:02 Yury Selivanov yselivanov.ml@gmail.com wrote:

...

IOW I don't see anyone (or some group of 3) who is as well-versed in everything on Guido's level. That can be solved if Guido agrees to join the permanent N-virate though :)

No one has suggested we haven't been extremely lucky for the past 28 years. :) I also don't think we will reach perfection in any solution anyway and this is somewhat of a "least bad" situation.

Are we looking for people who are skilled at language design, or who are skilled at building consensus through open decision-making processes? Because those are very different sorts of skills, and if this new body is intended to only be a final arbiter on decisions the former set of skills may be less important than the latter.

IMHO the N-virate should primarily be responsible for delegation.

Side note: I think we'll be talking less and less about language design, and instead about library and infrastructure design.

Regards

Antoine.

On Thu, 12 Jul 2018 at 11:28 Antoine Pitrou antoine@python.org wrote:

Le 12/07/2018 à 20:22, Doug Hellmann a écrit :

...

Excerpts from Brett Cannon's message of 2018-07-12 11:11:49 -0700:

...

On Thu, 12 Jul 2018 at 11:02 Yury Selivanov yselivanov.ml@gmail.com wrote:

...

IOW I don't see anyone (or some group of 3) who is as well-versed in everything on Guido's level. That can be solved if Guido agrees to join the permanent N-virate though :)

No one has suggested we haven't been extremely lucky for the past 28 years. :) I also don't think we will reach perfection in any solution anyway and this is somewhat of a "least bad" situation.

Are we looking for people who are skilled at language design, or who are skilled at building consensus through open decision-making processes? Because those are very different sorts of skills, and if this new body is intended to only be a final arbiter on decisions the former set of skills may be less important than the latter.

IMHO the N-virate should primarily be responsible for delegation.

Side note: I think we'll be talking less and less about language design, and instead about library and infrastructure design.

Same here. I suspect this will make us much more conservative in accepting language changes compared to e.g. what our deprecation policy should be.

On Jul 12, 2018, at 07:57, Guido van Rossum guido@python.org wrote:

I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own.

Leaving my emotions out of it for now, and with my heartfelt gratitude for everything you’ve done, I am absolutely certain that the community you’ve built is strong enough to carry on.

I’m honored that a some of you think I can fill 1/3 of Guido’s shoes, although in all humility I have my doubts. Aside from that, it’s important to recognize that we have so many intelligent and compassionate contributors, that much of Python’s ongoing development can essentially carry on unchanged. Yury, for example worried about replacing Guido’s extensive knowledge across so much of Python, and there’s the concern that Guido’s unique authority as BDFL will be difficult to replicate. E.g even if you still absolutely hate PEP 572 (which I don’t), it is now unequivocally part of Python. It’s up to all of us to accept that, move on, and learn to use it tastefully.

I think this change in governance will increase the importance of the BDFL-Delegate. We have trusted experts in many of the sub-topics of Python, and I have so much more confidence in letting them make the decisions relevant to those sub-topics. E.g. Nick, and now Paul for packaging, Yury et al for async, etc. I know that experts and BDFL-Delegates will make the right choices in these sub-topics, with the right intentions, and the best of their abilities. Even Guido recognizes that we’re all just trying to do our best.

Where the BDFL role is most important is in those holistic decisions about global features, such as PEP 572. These things impact everyone and every corner of Python, so having a final arbiter(s) that is accepted by the community at large is critical. I’ve long said that if I had to choose a single person to fill that role, it would be Brett. He has the right mix of technical and social chops to make thoughtful, intelligent, compassionate decisions, and he has the advantage of being likely more than a decade away from Guido in hopeful retirement plans, unlike perhaps that FLUFL guy. :)

That said, I think a triumvirate would work (Guido’s Unworthy Inherited Delegation Organization). Mostly, that group would identify and work with Delegates to make the final decisions on such PEPs, and most importantly, confidently back them up, even if those decisions are unpopular.

For PEP 572-level language decisions, the group would be the final arbiters, so it would have to be an odd number. I agree with Brett that voting and rotation could be problematic due to the tyranny of the majority. Imagine that PEP 572 were put in front of this group, and after all the kerfuffle, the same decision were made. Put yourself in that place when you think about the governance of Python-the-language over the next 25 years. I personally value stability and certainty over popularity for such features. PEP 572 won’t destroy Python, and I predict most of us will appreciate it being there once in a while.

There’s no rush to decide, and this would make for a fine discussion at the core sprint in September.

Cheers, -Barry

On Thu, 12 Jul 2018 at 11:53 Barry Warsaw barry@python.org wrote:

On Jul 12, 2018, at 07:57, Guido van Rossum guido@python.org wrote:

...

I would like to remove myself entirely from the decision process. I'll

still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own.

Leaving my emotions out of it for now, and with my heartfelt gratitude for everything you’ve done, I am absolutely certain that the community you’ve built is strong enough to carry on.

I’m honored that a some of you think I can fill 1/3 of Guido’s shoes, although in all humility I have my doubts. Aside from that, it’s important to recognize that we have so many intelligent and compassionate contributors, that much of Python’s ongoing development can essentially carry on unchanged. Yury, for example worried about replacing Guido’s extensive knowledge across so much of Python, and there’s the concern that Guido’s unique authority as BDFL will be difficult to replicate. E.g even if you still absolutely hate PEP 572 (which I don’t), it is now unequivocally part of Python. It’s up to all of us to accept that, move on, and learn to use it tastefully.

I think this change in governance will increase the importance of the BDFL-Delegate. We have trusted experts in many of the sub-topics of Python, and I have so much more confidence in letting them make the decisions relevant to those sub-topics. E.g. Nick, and now Paul for packaging, Yury et al for async, etc. I know that experts and BDFL-Delegates will make the right choices in these sub-topics, with the right intentions, and the best of their abilities. Even Guido recognizes that we’re all just trying to do our best.

Where the BDFL role is most important is in those holistic decisions about global features, such as PEP 572. These things impact everyone and every corner of Python, so having a final arbiter(s) that is accepted by the community at large is critical. I’ve long said that if I had to choose a single person to fill that role, it would be Brett. He has the right mix of technical and social chops to make thoughtful, intelligent, compassionate decisions, and he has the advantage of being likely more than a decade away from Guido in hopeful retirement plans, unlike perhaps that FLUFL guy. :)

Thanks for the vote of confidence! And I haven't hit my mid-life crisis yet, let alone gotten to worry about choosing when to retire. ;)

That said, I think a triumvirate would work (Guido’s Unworthy Inherited Delegation Organization).

Nice! "GUIDO decided ..." Totally going to mess with Guido's personal SEO, though. ;)

Mostly, that group would identify and work with Delegates to make the final decisions on such PEPs, and most importantly, confidently back them up, even if those decisions are unpopular.

For PEP 572-level language decisions, the group would be the final arbiters, so it would have to be an odd number. I agree with Brett that voting and rotation could be problematic due to the tyranny of the majority. Imagine that PEP 572 were put in front of this group, and after all the kerfuffle, the same decision were made. Put yourself in that place when you think about the governance of Python-the-language over the next 25 years. I personally value stability and certainty over popularity for such features. PEP 572 won’t destroy Python, and I predict most of us will appreciate it being there once in a while.

Maybe another way to label this is design stewards? We seem to be suggesting a cabal of folks who steward the overall design while relying on experts as appropriate to handle finer details.

There’s no rush to decide, and this would make for a fine discussion at the core sprint in September.

Oh, if this isn't settled by September then I expect there will be a lively discussion at the dev sprints. :)

On Jul 12, 2018, at 11:53 AM, Barry Warsaw mailto:barry@python.org> wrote:

On Jul 12, 2018, at 07:57, Guido van Rossum mailto:guido@python.org> wrote:

...

I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own.

Leaving my emotions out of it for now, and with my heartfelt gratitude for everything you’ve done, I am absolutely certain that the community you’ve built is strong enough to carry on.

Well said, Barry.

That said, I think a triumvirate would work (Guido’s Unworthy Inherited Delegation Organization).

We'll likely all be asking ourselves often "What would Guido think/do in situation x, y, or z?"

There’s no rush to decide, and this would make for a fine discussion at the core sprint in September.

Tim's reference to Stroustrup's article and the article's cautions are spot on.

I agree with Barry there's no rush to decide. Taking our time to absorb the news and giving Guido the space to recharge and pursue things that rock his world (Python and beyond) would be two actions that we can take right now.

Thank you Guido for everything. Wishing you all that you wish for us: https://neopythonic.blogspot.com/2016/04/kings-day-speech.html https://neopythonic.blogspot.com/2016/04/kings-day-speech.html

Warmly,

Carol

Le 12/07/2018 à 21:17, Doug Hellmann a écrit :

If the primary approach to decision making is to delegate unless an arbiter is absolutely necessary, then long-term consistency and stability comes less from finding individuals to commit to serving for very long terms on the N-virate as it does from everyone having a good understanding of the history of discussions and from a willingness to keep the status quo in situations where consensus isn't reached (note "consensus" rather than "unanimous agreement").

Building the system to support and encourage turnover, like we do with release managers, lowers the level of effort someone is signing up for when they agree to serve. Given the *many* discussions of burnout in the Python community and open source in general, that seems like an important feature.

+1. Ongoing consistency is achieved through a strong culture.

Regards

Antoine.

On Jul 12, 2018, at 12:16, Brett Cannon brett@python.org wrote:

Maybe another way to label this is design stewards? We seem to be suggesting a cabal of folks who steward the overall design while relying on experts as appropriate to handle finer details.

I like that distinction.

-Barry

On Thu, Jul 12, 2018 at 1:29 PM Brett Cannon brett@python.org wrote:

On Thu, 12 Jul 2018 at 10:42 Eric Snow ericsnowcurrently@gmail.com wrote:

...

In the short term we could appoint a *temporary* triumvirate to fill in as BDFL (with the intent to re-assess the situation in September if we haven't resolved on a permanent solution by then). That would allow us to maintain business-as-usual (and try out a triumvirate). If we go that route then I'd recommend Brett, Nick, and Barry.

I don't think we need a temporary solution while we digest this and figure out how we want to manage ourselves. Short of some horrible CoC catastrophe we can just hold off on making any final decisions on PEPs until a decision is made in how we want to handle PEPs going forward since Python 3.8 isn't hitting beta until May 2019 (and even if it was close we don't need to ever rush anything into a release as there's always the next release :) .

Agreed. I was hasty in posting that and don't foresee any issues where a temporary BDFL would matter. :)

-eric

On Jul 12, 2018, at 6:14 PM, Antoine Pitrou antoine@python.org wrote:

I think it would be worth studying the governance structure (*) of a bunch of open source projects picked according to a set of criteria:

• major project in # of users and contributors
• non BDFL-governed
• mostly volunteer-driven
• with an established decision process for major enhancements

(*) (e.g. as an informational PEP)

That makes good sense. We would do well to learn from those who came before us :-)

For the time being, I propose that we shift into low gear and defer major language changes for a while -- that will give us time to digest the changes already in motion and it will give the other implementations more of a chance to catch up (we've been out-running them for a while).

For the smaller decisions, I suggest that for the most part we leave the final calls to the subject matter experts, original authors, and module maintainers when applicable (Yuri for async, Vinay for logging, Nick for functools, Brett for imports, Inada/Victor for the eval-loop and opcodes, Bob for JSON, etc.) The people who've invested the most time in a subject area are probably the best ones to be decision makers for those areas. But mostly, we should aim for consensus and only appeal to a decision maker when there is a major divergence about which way to go.

For the bigger decisions (and there aren't many coming up), I have some suggestions on ways to improve the discussions so that the interested parties can have a more equal say in the outcome and so that the discussions can be more time efficient (it takes too much time to keep-up with long-running, active threads).

Essentially the idea would be have a wiki/faq editable by all the participants. It would include the key examples, arguments for and against, and rebuttals which can be collected into a current-state-of-the-conversation. This would be somewhat different than the current PEP process because currently PEP authors dominate the conversation and others can get drowned out too easily. (This idea is modeled on the California Legislative Analyst Voters Guide which summarizes proposals and has statements and rebuttals from both proponents and opponents).

Also, it would be nice to have the decisions made by someone other that the principal proponents. From my own experience with PEPs, I know that the psychological effects are powerful -- if you are the one spelling out all the details and defending the idea against all the slings and arrows, then it is only natural to come to identify with the PEP and come to believe that the only righteous outcome is for it to be accepted.

Raymond

On 07/12/2018 12:28 PM, Barry Warsaw wrote:

On Jul 12, 2018, at 12:16, Brett Cannon wrote:

...

Maybe another way to label this is design stewards? We seem to be suggesting a cabal of folks who steward the overall design while relying on experts as appropriate to handle finer details.

I like that distinction.

As do I. My thoughts in more detail:

• the number of stewards should be five to increase stability

. the positions should be filled by majority vote of core-devs

• the terms should be for life, with the acknowledgment that stepping down at any time for any reason is perfectly acceptable

The stewards' duties:

• appoint PEP delegates as needed (not every PEP needs a delegate)
• decide PEPs that don't have delegates
• decide on major issues (such as revision control systems, main discussion forums, etc.)

As has been said already, there is no rush.

-- ~Ethan~

On Jul 12, 2018, at 2:27 PM, Raymond Hettinger raymond.hettinger@gmail.com wrote:

For the time being, I propose that we shift into low gear and defer major language changes for a while

+1

Not only do I think our first major decision should be how we make decisions now, but as the release manager of the first versions of Python to ever be developed without a dictator at the helm, I feel responsible for them not to be viewed by future archeologists as the releases where the project went downhill ;-)

The fact I'm midway through a 5 week coast-to-coast road trip doesn't help.

Let's not rush anything at this point. This includes the release schedule which I think is wise to keep intact through this transition. See PEP 569 for 3.8.

I'm +1 to an Informational PEP around the state of the art in project governance.

-- Ł

(separate reply to discuss the "what do we do now" topic)

On 07/12/2018 07:57 AM, Guido van Rossum wrote:

I would like to remove myself entirely from the decision process. [...]

I am not going to appoint a successor.

So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?

Although the timing is a surprise, the idea of Guido retiring isn't.  I remember shooting the breeze with Guido about it as far back as the Santa Clara PyCons--and I'm sure the topic goes even further back.  So we've had quite a while to think about it.  Here's my opinion, which I reached years ago and haven't appreciably changed since.

First, there's no single person in the community who can take over as BDFL.  It's simply impossible.  The Guido we have today is who he is because he's been doing the BDFL job for more than twenty years. The job has shaped and taught him as he did it; as Python grew, so did Guido.  Literally anybody else we might appoint as BDFL would have to start fresh and grow into the job--and I don't think we can afford the growing pains.

On the other hand, I also think that deciding PEPs by popular vote would be folly.  Python is mature enough to be simultaneously robust and fragile, and leaving its design up to popular vote seems like a recipe for chaos.  In my opinion, the final arbiters of Python's evolution should be experts, not the masses.  (Cue "Twitch Plays Pokemon" here.)

I think the happy medium is a Council Of Elders.  Summarizing this approach:

• The number of Elders on the Council should be an odd number greater than two.  It can't be one person, as that'd just be a BDFL.  And we want an odd number to prevent tie votes.  My instinct is that three would be fine.
• For most PEPs the Elders should delegate, just as Guido has generally done in the last few years.  Although I expect the Elders to be seasoned Python core developers, they probably won't have domain-specific knowledge necessary to rule on most PEPs.
• I'm not sure how to appoint the initial round of Elders. Maybe a popular vote?
• However, once appointed, Elders are appointed is "for life". The only way to remove one would be for them to voluntarily step down--there would be no mechanism to remove one from office. (Perhaps this is too strong--perhaps one could be removed by a unanimous vote from all other Elders?)  I want the Council to be immune to popular opinion, to be empowered to do what they think is right without fear of anything beyond negative public opinion.
• I'm not sure how we'd replace Elders.  Maybe they'd hold an internal-only election?  ("Jo has decided to step down, and we have elected Sam as Jo's replacement.")

Your reaction to this might be "but running Python's evolution by committee will slow it down!"  I suspect that's right.  Not being Guido, I think the Council would be more cautious in approving changes to the language.  But I think that'd be appropriate anyway. Python's already a fine language, and I can live with it evolving more slowly in the future.

Personally I'd nominate the following three Elders.  In alphabetical order:

• Barry Warsaw (knows where the bodies are buried)
• Benjamin Peterson (young enough that we'll get many years of service out of him)
• Brett Cannon (the only candidate tall enough to be worth considering as BDFL replacement)

I like this union of experience and personality.  My intuition is that they'd find the mixture of caution and let's-go-for-it spirit that we need to keep Python moving forward without making too many mistakes.  And we could call them "the B's" for short!

Finally, I agree with Raymond's call for slow deliberation. Python's not going anywhere, there are no burning needs for changing the language that need to be addressed immediately.  We can all collectively sit and stew on this for a while.

//arry

/p.s. I know nobody is suggesting this, but I'll preemptively say it anyway: let's not simply appoint all the Release Managers as our initial Council Of Elders.  While that'd net us some very fine Elders indeed, you'd also wind up with me on the Council--an obvious mistake! //

On Fri., 13 Jul. 2018, 02:58 Guido van Rossum, guido@python.org wrote:

available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own.

Thank you for being here, benevolent, for so long . You've been a great example in our communities and it is much appreciated.

Rob

As someone who's not been involved for some time now, but was release manager for a three or four years (2.3.1 through to 2.5.1), trying to have the release manager also be a decider of potentially controversial things doesn't seem scalable.

Getting a release out is a heck of a lot of work, both the actually cutting the alphas, betas, &c, and also triaging issues that comes up and chasing people up for fixes.

I'm not sure what the proper governance structures should be, but they absolutely shouldn't be dumping extra load onto the release manager.

On Fri, Jul 13, 2018, 3:49 AM Doug Hellmann doug@doughellmann.com wrote:

Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400:

...

On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou antoine@python.org wrote:

...

I'd like to point out that the N-virate idea doesn't handle a key

issue:

...

once you have a N-virate, how do you evolve its composition according to the implication and motivation of its members - but also to remarks or frustation by non-virate contributors (especially new contributors who will feel there's a perpetual category they're locked out of)? Do you just wait for people to gently step down when required?

One way would be to re-elect them every 5 or so years. Essentially, an N-virate is a dictator-like entity for a few years.

Yury

We've had good luck in the OpenStack community tying leadership to release cycles. It causes elections more often (our cycles are 6 months long), but people tend to step up for several cycles in a row so that hasn't been a cause of excessive turnover. Having frequent opportunities for folks to step down gracefully when they need or want to also means no one feels like they are signing up for an indefinite time commitment.

For a multi-person group, staggered elections where only a portion of the group is up for election at one time, also provides some consistency when there is turnover.

Doug

---

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 07/12/2018 01:27 PM, Raymond Hettinger wrote:

For the bigger decisions (and there aren't many coming up), I have some suggestions on ways to improve the discussions so that the interested parties can have a more equal say in the outcome and so that the discussions can be more time efficient (it takes too much time to keep-up with long-running, active threads).

Essentially the idea would be have a wiki/faq editable by all the participants. It would include the key examples, arguments for and against, and rebuttals which can be collected into a current-state-of-the-conversation. This would be somewhat different than the current PEP process because currently PEP authors dominate the conversation and others can get drowned out too easily. (This idea is modeled on the California Legislative Analyst Voters Guide which summarizes proposals and has statements and rebuttals from both proponents and opponents).

I really like this idea. I stopped reading the PEP 572 threads once it was painfully obvious that almost all new replies were just saying the same things over and over and over...

-- ~Ethan~

A wild idea:

How about a triumvirate (or trium*ate if “vir” is seen as too male-centric, and actually the “3” isn’t important either) where unanimity is required for language changes (i.e. basically for accepting a PEP)?

A unanimity requirement will inevitably lead to more conservative decisions, but that may be a good thing...

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

On Jul 13, 2018, at 02:30, Anthony Baxter anthonybaxter@gmail.com wrote:

As someone who's not been involved for some time now, but was release manager for a three or four years (2.3.1 through to 2.5.1), trying to have the release manager also be a decider of potentially controversial things doesn't seem scalable.

I'm not sure what the proper governance structures should be, but they absolutely shouldn't be dumping extra load onto the release manager.

My thinking is that the current RM can serve a useful role on the Council, but not in a voting capacity. Some possible scenarios:

• A Council member wants to author a PEP. They probably shouldn’t also get to vote on the PEP’s acceptance, so the RM can serve as a replacement vote for that one PEP. (Maybe only for Standard Track PEPs).

• If a Council member is temporarily unavailable, the RM can serve in their place during that period.

• The RM can give valuable insight that may influence Council members votes. Maybe the PEP’s implementation is too difficult for the current release, and recommends deferral.

• If the Council also decides on the “PEP-worthiness” of an idea, the RM can weigh in based on their unique perspective on the release cycle.

• The RM can provide an independent oversight role on the Council, kind of like an ombudsman (or maybe that should be a separate role, although I suspect it will be rarely invoked in practice).

I would propose that the RM be involved with Council communications, but does not get a vote.

Cheers, -Barry

On 13Jul2018 1600, Larry Hastings wrote:

I disagree.  My proposal for Python's Council Of Elders is partially based on the Supreme Court Of The United States.  For example, SCOTUS judges are appointed for life, and I think PCOE members should be too.

When SCOTUS renders a decision:

• the deliberation is held in private, but then
• the judges cast their votes,
• the "winning" side writes up the official decision, called "the Court's opinion",
• and any member may contribute their own individual opinion, concurring /or/ dissenting, and finally
• all votes and opinions contributed to the decision are made public.

This seems like a sensible approach for the PCOE to me too.  I prefer more transparency in governance generally, and as a member of the community governed by this body I'd prefer more rather than less insight into the process and the thinking that went into the decision.  I don't think it's a requirement for the PCOE to present as a unified front or to work in secret for them to be supportive of each other and of the body's decision.

Sunlight, not darkness

I agree with Larry, at least until the point at which we see "the public" aggressively idolising or demonising those members of the Council with whom they agree/disagree. Then I'll change my mind :)

(For those who are unfamiliar with the phenomenon I'm referencing, wait for SCOTUS to decide _anything_ and then go look at American Twitter.)

Cheers, Steve

[Larry Hastings] ...

• However, once appointed, Elders are appointed is "for life". The only way to remove one would be for them to voluntarily step down--there would be no mechanism to remove one from office. (Perhaps this is too strong--perhaps one could be removed by a unanimous vote from all other Elders?) I want the Council to be immune to popular opinion, to be empowered to do what they think is right without fear of anything beyond negative public opinion.

At the time the US"s founders drafted the Constitution, mean US life

expectancy was about 35 years A Federal judge only had to maintain "good behavior" to keep their job, but I imagine they expected most judges would die within a decade or two regardless.

I really don't think they'd be happy with how the Supreme Court turned out

• political ideologues wielding near-absolute power for decades on end.

So: term limits! Say, 12 years. If there are 3 Elders, replace one every 12/3 = 4 years. At the start we can use the secrets module to pick which Elders get the first 4, 8, and 12-year terms ;-)

Fresh blood is a good thing in all areas.

• I'm not sure how we'd replace Elders. Maybe they'd hold an internal-only election? ("Jo has decided to step down, and we have elected Sam as Jo's replacement.")

Obviously, an Elder would be nominated by the President and confirmed with the advice and consent of the Senate ;-)

Or, short of that, by an approval vote of the Fellows (whatever it is we call for-real PSF members these days).

And I'd propose to let the Fellows remove an Elder by a 2/3rd supermajority vote (akin to the bar for impeachment of a US President).

On Fri, Jul 13, 2018 at 6:54 PM, Tim Peters tim.peters@gmail.com wrote:

[Larry Hastings] ...

...

However, once appointed, Elders are appointed is "for life". The only way to remove one would be for them to voluntarily step down--there would be no mechanism to remove one from office. (Perhaps this is too strong--perhaps one could be removed by a unanimous vote from all other Elders?) I want the Council to be immune to popular opinion, to be empowered to do what they think is right without fear of anything beyond negative public opinion.

At the time the US"s founders drafted the Constitution, mean US life expectancy was about 35 years A Federal judge only had to maintain "good behavior" to keep their job, but I imagine they expected most judges would die within a decade or two regardless.

That's not really true -- life expectancy *at birth* was ~35 years, but mostly because so many people died as infants/children. If you survived long enough to get nominated for a judgeship, then by that point your life expectancy wasn't too different from what we're used to today: https://passionforthepast.blogspot.com/2011/08/average-life-expectancy-myth....

But I think there are a lot of differences between a 21st-century F/OSS project and an 18th-century federal government, so probably not the most relevant model in any case. And of course it's always tempting to start inventing neat rules and procedures, but IME those details are actually the least important part of project governance (compared to things like, having a healthy discussion culture, tools for building consensus, etc. -- by the time you're voting on something you've already failed). So debating the pros and cons of term limits seems a bit premature to me right now :-).

-n

-- Nathaniel J. Smith -- https://vorpus.org

On 07/13/2018 06:54 PM, Tim Peters wrote:

So:  term limits!  Say, 12 years.  If there are 3 Elders, replace one every 12/3 = 4 years.  At the start we can use the secrets module to pick which Elders get the first 4, 8, and 12-year terms ;-)

Fresh blood is a good thing in all areas.

Can I get you to clarify what you mean by "term limits"?  Do you solely mean "Elders would not be appointed for life, but rather would need to be re-elected every N years"?  Or do you additionally mean "No Elder can serve more than N terms in their lifetime?"  As an admittedly-feeble attempt at disambiguation, I'd call the former "limited terms" and the latter "term limits".  (I would welcome better terms ;-)

I'm most familiar with the term "term limits" from American politics, where it definitely means the latter: a person can only serve N times, and are simply ineligible to serve in that same role an N+1th time.  As an example, after FDR was elected President four times (!), the American Congress passed the 22nd Amendment which limits any particular person to no more than two terms as President.

Using my terminology above, at the moment I'm open-minded about whether or not the Council members should have "limited terms".  But I'm less upbeat about "term limits".  Personally I've always found this concept of "term limits" a bit silly--the electorate could simply decline to re-elect the incumbent.  The fact that Americans re-elect the incumbent so frequently, and /also/ vote for term limits, seems to distill down to the attitude "Throw the bums out!... except for /my/ guy, he's good."

//arry/

[Tim]

So: term limits! Say, 12 years. If there are 3 Elders, replace one every 12/3 = 4 years. At the start we can use the secrets module to pick which Elders get the first 4, 8, and 12-year terms ;-)

Fresh blood is a good thing in all areas.

[Larry]

Can I get you to clarify what you mean by "term limits"? Do you solely mean "Elders would not be appointed for life, but rather would need to be re-elected every N years"? Or do you additionally mean "No Elder can serve more than N terms in their lifetime?" As an admittedly-feeble attempt at disambiguation, I'd call the former "limited terms" and the latter "term limits". (I would welcome better terms ;-)

It would mean whatever we said it means ;-) I had in mind that an Elder would be limited to one 12-year term. You do your dozen and you're out. The only ways to get out are to serve your 12 years, quit. die, or get impeached. Then that's it - you can't be a Python Elder again.

I'm most familiar with the term "term limits" from American politics, where it definitely means the latter: a person can only serve N times, and are simply ineligible to serve in that same role an N+1th time. As an example, after FDR was elected President four times (!), the American Congress passed the 22nd Amendment which limits any particular person to no more than two terms as President.

In the context of hypothetical US Supreme Court term limits, legal thinking has been in line with my meaning above, although (a single) 18-year term has been most often discussed in that context:

https://en.wikipedia.org/wiki/Term_limits_in_the_United_States#Supreme_Court

However, the articles I read most recently talked about 12 years instead, and I like that better for Python. The Supremes get a salary, but Elders don't. 12 years is a looooong commitment to do something "in spare time".

Using my terminology above, at the moment I'm open-minded about whether or

not the Council members should have "limited terms". But I'm less upbeat about "term limits". Personally I've always found this concept of "term limits" a bit silly--the electorate could simply decline to re-elect the incumbent. The fact that Americans re-elect the incumbent so frequently, and *also* vote for term limits, seems to distill down to the attitude "Throw the bums out!... except for *my* guy, he's good."

Of course a limit on the number of terms a Congress Critter can serve is intended to force the _other_ side's bums out. The passion for the prospect of being able to do that clouds seeing that it will also throw your side's bums out too ;-)

BTW, we both know that the US founders deliberately did _not_ want Federal judges to be elected. They had little use for democracy at the Federal level. But without a Prez and a Congress to "do the right thing" in the peoples' best interest, I figured it's good enough to let PSF Fellows do the voting (in the best interests of the PSF's much broader membership).

[Nathaniel Smith]

... Well, sure, we can try to come up with something to slot into the space Guido is leaving, while keeping everything else the same, that's one option.

There are already differences between "a Guido" and what Larry suggested.

But I doubt it's the best one.

Then please suggest something specific you think is better.

Guido is, quite literally, irreplaceable.

Yet the roles he played are not self-evidently dispensable either.

...

The US Supreme Court is the closest thing to a dictatorial institution the US has (lifetime appointments, answerable to nobody, and against which there is no appeal), so it's a natural model to consider when replacing a dictator.

Yeah, I get why it comes to mind for USians here, but there are also, like... lots of actual open-source projects that have transitioned from a BDFL model to something else, and they're probably even more natural models ;-).

Then spell out what they did and how that worked for them? I'm not familiar with any such. The closest match to Python's development process I know of was Perl's, but Larry Wall is still (AFAIK) dictator-for-life in Perl world.

On the face of it, sure, I'd rather look at a successful transition in an open source software project than at the centuries-old experiment that brought us American politics ;-)

On Thu, Jul 12, 2018 at 12:17 PM Brett Cannon brett@python.org wrote:

On Thu, 12 Jul 2018 at 11:53 Barry Warsaw barry@python.org wrote:

...

That said, I think a triumvirate would work (Guido’s Unworthy Inherited Delegation Organization).

Nice! "GUIDO decided ..." Totally going to mess with Guido's personal SEO, though. ;)

+1 Whatever we wind up with, the name has already been decided. Lets keep GUIDO as the name unless the ex-BDFL rejects it! =)

I *assumed* someone else would've long suggested we act as an autonomous collective organized as an anarcho-syndicalist commune in honor of https://youtu.be/Yx_pDo9B0NY by now given the in person conversations where the Holy Grail quoting of came up. :P (in case it isn't obvious: *don't take that seriously*)

In all seriousness, we already have a BDFL delegate system for PEPs that makes sense. At a minimum, how to choose the delegate, or early reject a PEP so it doesn't need one, is the thing we'll decide within the next year.

I also liked some of Raymond H's suggestions around adjusting the PEP section authorship and potentially final decision acceptance process. But those types of changes are likely best kept separate from choosing how BDFL delegates are agreed on. (ie: lets decide how we would even declare the decision of such changes first)

-gps

On Jul 13, 2018, at 7:54 PM, Tim Peters tim.peters@gmail.com wrote:

If there are 3 Elders [snip]

It looks like the number 3 is popular in this context. What makes it so attractive?

I see a bunch of problems with such a low number, like the ability for a single corporation to take over the design process of Python by employing just two of the three members (consistently voting over the third one). 3 also has high likelihood of ties if one of the members abstains. And so on.

Taking a step back, before we talk names, term limits and even numbers of council members, Python needs a "constitution" which will codify what the council is and how it functions. Barry calls it PEP 2 but I'd like to understand who is supposed to author it and who is supposed to accept it.

Any committer is in a position to suggest parts of or the entirety of such a document. Otherwise we create a fractal problem of who and how decides on who shouId be writing it. Ultimately we are volunteers, the ones who step up and do the work.

Ideally Guido would accept the PEP but I'm not sure if he is willing to. If that is indeed the case then how should this be done so that the document is universally accepted by all committers?

-- Ł

[Tim]

...

If there are 3 Elders [snip]

[Łukasz Langa]

It looks like the number 3 is popular in this context. What makes it so attractive?

Likely because it was the first specific non-insane number someone mentioned. It helps to be concrete, but I don't know that anyone is wedded to 3.

I see a bunch of problems with such a low number, like the ability for a single corporation to take over the design process of Python by employing just two of the three members (consistently voting over the third one).

Perhaps then you don't want a "supreme court" at all. We've been living for decades with the possibility that a single corporation could buy off Guido. Would it really help to change 3 to 5? Then Evil Corp only needs to buy off 3 - but the larger the number, the more likely Evil Corp will get some votes in its favor without needing to pay.

If semi-dictators are part of the New Order at all, they need to be trusted a whole lot (although I suggested a mechanism for impeachment too).

3 also has high likelihood of ties if one of the members abstains.

I don't care about that. How often did Guido abstain? it's an Elder's _job_ to make potentially unpopular decisions. If one abstained without extraordinarily solid reason, I'd move to impeach them - they're not doing the job in that case.

If they tied, that's fine too. Ties favor the status quo (same as if the proposed change had been rejected). For that reason, I'm not even wedded to an odd number.

And so on.

Likewise in the other direction. For example, how many "extremely trusted" people can we even get to volunteer for a contentious, long-term, non-paying job? I don't know. "3" probably started with the first person here who suggested specific names and could only come up with 3 ;-)

Taking a step back, before we talk names, term limits and even numbers of

council members, Python needs a "constitution" which will codify what the council is and how it functions.

"Feedback loops" - all decisions feed into each other, in all directions. For example, the number of people on the council has real effects on what it's _possible_ for it do, and on how it functions. It doesn't hurt to think about everything at once ;-)

Barry calls it PEP 2 but I'd like to understand who is supposed to author

it and who is supposed to accept it.

Any committer is in a position to suggest parts of or the entirety of such a document. Otherwise we create a fractal problem of who and how decides on who shouId be writing it. Ultimately we are volunteers, the ones who step up and do the work.

Sure!

Ideally Guido would accept the PEP but I'm not sure if he is willing to.

His initial message here seemed very clear that he wants us to "figure something out for yourselves". He's tired of the battles, and perhaps you have to be as old as him (as I was 4 years ago) to grasp what "bone weary" really means ;-)

If that is indeed the case then how should this be done so that the document is universally accepted by all committers?

Perhaps it won't be - after all, much of the point to a dictator-workalike is that universal acceptance is a rare thing in real life. Guido left us with an interesting puzzle to solve :-)

On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon brett@python.org wrote: [..]

...

Ideally Guido would accept the PEP but I'm not sure if he is willing to. If that is indeed the case then how should this be done so that the document is universally accepted by all committers?

In my ideal scenario, people write up PEPs proposing a governance model and Guido chooses one, making it PEP 2.

That would be indeed the ideal scenario, legitimizing the whole thing.

Yury

On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov yselivanov.ml@gmail.com wrote:

On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon brett@python.org wrote: [..]

...

...

Ideally Guido would accept the PEP but I'm not sure if he is willing to. If that is indeed the case then how should this be done so that the document is universally accepted by all committers?

In my ideal scenario, people write up PEPs proposing a governance model and Guido chooses one, making it PEP 2.

That would be indeed the ideal scenario, legitimizing the whole thing.

I don't know how to read these comments... Are you afraid Guido wouldn't accept the proposed arrangement, or are people really doubting that Guido is still involved in this decision? I've seen the latter idea expressed by non-core-developers, but to me, Guido's use of "try" (twice) and "we" in his original email makes it clear that he's still involved; he just doesn't want to (or can't) dictate what he'll be replaced by. If people feel like Guido's participation in this is in doubt, should we just ask him to confirm one way or the other? (You don't have to wait for an answer to that question, Guido :)

-- Thomas Wouters thomas@python.org

Hi! I'm an email virus! Think twice before sending your email to help me spread!

I’m still here, but I would like to be out of the debate and out of the decision loop. I’m also still President of the PSF. But this is not for the PSF to decide. You all are doing fine.

—Guido

On Sun, Jul 15, 2018 at 1:37 PM Brett Cannon brett@python.org wrote:

On Sun, Jul 15, 2018, 13:01 Thomas Wouters, thomas@python.org wrote:

...

On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov yselivanov.ml@gmail.com wrote:

...

On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon brett@python.org wrote: [..]

...

...

Ideally Guido would accept the PEP but I'm not sure if he is willing to. If that is indeed the case then how should this be done so that the document is universally accepted by all committers?

In my ideal scenario, people write up PEPs proposing a governance model and Guido chooses one, making it PEP 2.

That would be indeed the ideal scenario, legitimizing the whole thing.

I don't know how to read these comments... Are you afraid Guido wouldn't accept the proposed arrangement, or are people really doubting that Guido is still involved in this decision? I've seen the latter idea expressed by non-core-developers, but to me, Guido's use of "try" (twice) and "we" in his original email makes it clear that he's still involved; he just doesn't want to (or can't) dictate what he'll be replaced by. If people feel like Guido's participation in this is in doubt, should we just ask him to confirm one way or the other? (You don't have to wait for an answer to that question, Guido :)

For me, Guido's participation just hasn't been agreed to by him yet 😉. I have viewed the retirement email as saying "you all have to decide how you want things to be as I'm not going to force something upon you" and not a mic drop of "I ain't participating". But Guido hasn't spoken up yet as I think he's still processing all of this. So I'm just hedging my phrasing in case he takes a pass.

-Brett

...

-- Thomas Wouters thomas@python.org

Hi! I'm an email virus! Think twice before sending your email to help me spread!

---

python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

---

python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

-- --Guido (mobile)

[Tim]

If they tied, that's fine too. Ties favor the status quo (same as if the

...

proposed change had been rejected). For that reason, I'm not even wedded to an odd number.

[Brett Cannon]

That's a good point. Since this is typically going to be a yes/no question instead of an A/B question, ties that go in favour of the status quo aren't a stalemate issue.

Thanks for reading my mind :-) I certainly didn't spell it out.

Predictably contentious A/B issues, like how to allocate limited resources (how much do we spend on grants vs sponsoring conferences?), are mostly in the PSF's court. Likewise A/B decisions with legal consequences (now that the DPRK has ruled the PSF license counterrevolutionary, which license should we use there instead?).

Guido's most visible (well, to us committers) BDFL role has been in "yes/no", "go/nogo" language/library design questions, which don't even overlap with the PSF's proper concerns.

But I'm not sure it's fully appreciated just how active Guido has been in those at times. The "accepted/rejected" at the end of major PEPs is just a small part of that. Along the way, e.g., it's been pretty common to see a "Save your breath. That's not going to happen." from Guido to end a distracting alternative (sub)proposal persistently promoted by one (or a few) very active and/or loquacious posters.

Those "small" pronouncements typically go by with little notice except by those shut down, but may well be crucial in keeping productive discussion going at all. And they need to be timely to do any good. Whoever makes such decisions needs to be down in the mud, wrestling with the issues while they're hot topics, not judging at leisure weeks (or even days) later.

I'm not sure "a committee" can do that at all. Then again, there seems to be consensus that the current PEP discussion process is sometimes broken anyway, even with a BDFL.

[Chris Jerdonek]

I don’t think we should assume that a stalemate would be okay in all cases. There may be cases in which a decision has to be made (e.g. if nothing changes, bad things will happen). I think one of the most important roles a BDFL serves is to provide a mechanism of last resort to resolve such stalemates should they ever arise. If the replacement we come up with can itself stalemate, I think there will be a problem.

Can you flesh that out with a plausible example? If "bad things can happen" relates to finances or legal issues, the problem is almost certainly the PSF's headache to resolve. If they don't relate to finances or legal issues, I'm unclear on what "bad" could mean. Guido's BDFL pronouncements were mostly about language and library design issues.

The only total stalemate I can recall happened when complex numbers were added to Python. Should the suffix used to denote imaginary literals be "i" or "j"? After long argumentation, nothing anywhere near consensus was reached, in large part because there really isn't a _compelling_ argument for or against either one. Just observations justifying personal tastes, sometimes disguised as "arguments" (whether "i looks too much like the digit 1" or "j is rarely used by mathematicians").

Guido picked "j". The world wouldn't really be significantly different if he had picked "i". If the Elders childishly refused to compromise, then

print(random.choice("ij'))

could settle it ;-)

Here's a hypothetical: suppose Larry removes the GIL but it slows down single-threaded code by a factor of 1.2. Should the default CPython provided by the PSF enable that or not? That could plausibly become a contentious issue with no community consensus. If the Elders tied, the "no change" (maintain the status quo) outcome would still be _a_ resolution.

If you want to make a rule that the Elders cannot tie, the only way to do that is to say they'll all be impeached and replaced if they ever tie (as already noted by Łukasz, having an odd number of Elders doesn't prevent one from abstaining). And we'll keep replacing them until they stop tying. But we'll probably run out of volunteers after the first round of impeachments.

Sneakier: add a rule that if the Elders tie, then the choice has to be made by the President of the PSF. Which, by sheer coincidence, is Guido :-)

Le 16/07/2018 à 04:38, Tim Peters a écrit :

But I'm not sure it's fully appreciated just how active Guido has been in those at times.  The "accepted/rejected" at the end of major PEPs is just a small part of that.  Along the way, e.g., it's been pretty common to see a "Save your breath.  That's not going to happen." from Guido to end a distracting alternative (sub)proposal persistently promoted by one (or a few) very active and/or loquacious posters.

I think that only happens on python-ideas. We've long had a problem with that mailing-list (but at least it allows to avoid such discussions on python-dev).

Regards

Antoine.

Le 16/07/2018 à 20:05, Tim Peters a écrit :

[Tim]

> But I'm not sure it's fully appreciated just how active Guido has been
> in those at times.  The "accepted/rejected" at the end of major
PEPs is
> just a small part of that.  Along the way, e.g., it's been pretty
common
> to see a "Save your breath.  That's not going to happen." from
Guido to
> end a distracting alternative (sub)proposal persistently promoted
by one
> (or a few) very active and/or loquacious posters.

[Antoine]

I think that only happens on python-ideas.  We've long had a problem
with that mailing-list (but at least it allows to avoid such discussions
on python-dev).

I'm unclear on whether you view that as opposing or confirming my point ;-)  I view it as confirming:  yes, the BDFL has played this role mostly on python-ideas, where the dirty work of developing general PEPs is intended to take place, while they're still at best half-baked.  If someone only follows python-dev, they're unaware of most of these BDFL pronouncements.

The latter may think "oh, big deal - a PEP is posted to python-dev, and then Guido has weeks to make up his mind about whether to accept or reject it".  They're only seeing the end of a sometimes very messy process.  Most things on python-ideas never make it to python-dev at all.

PEP 572 was (IMO, and Guido's, and a whole bunch of others) posted to python-dev prematurely, so anyone who doesn't follow python-ideas should know that the firestorm on python-dev was just a hint of what python-ideas can be like routinely ;-) 

I know what python-ideas can be like routinely (I do read it at times).

I think the general idea of my comment is that the signal-to-noise ratio on python-ideas is so low that, whether or not Guido had remained BDFL, we would still have a productivity problem to solve there.

Regards

Antoine.

On Sun, 15 Jul 2018 at 19:38 Tim Peters tim.peters@gmail.com wrote:

[Tim]

...

If they tied, that's fine too. Ties favor the status quo (same as if the

...

proposed change had been rejected). For that reason, I'm not even wedded to an odd number.

[Brett Cannon]

...

That's a good point. Since this is typically going to be a yes/no question instead of an A/B question, ties that go in favour of the status quo aren't a stalemate issue.

Thanks for reading my mind :-) I certainly didn't spell it out.

Just glad I still have the knack for it on occasion. :)

Predictably contentious A/B issues, like how to allocate limited resources (how much do we spend on grants vs sponsoring conferences?), are mostly in the PSF's court. Likewise A/B decisions with legal consequences (now that the DPRK has ruled the PSF license counterrevolutionary, which license should we use there instead?).

Guido's most visible (well, to us committers) BDFL role has been in "yes/no", "go/nogo" language/library design questions, which don't even overlap with the PSF's proper concerns.

But I'm not sure it's fully appreciated just how active Guido has been in those at times. The "accepted/rejected" at the end of major PEPs is just a small part of that. Along the way, e.g., it's been pretty common to see a "Save your breath. That's not going to happen." from Guido to end a distracting alternative (sub)proposal persistently promoted by one (or a few) very active and/or loquacious posters.

IOW the design guidance he provided as the discussion progressed and his thoughts evolved/formed on the topic.

Those "small" pronouncements typically go by with little notice except by those shut down, but may well be crucial in keeping productive discussion going at all. And they need to be timely to do any good. Whoever makes such decisions needs to be down in the mud, wrestling with the issues while they're hot topics, not judging at leisure weeks (or even days) later.

I'm not sure "a committee" can do that at all. Then again, there seems to be consensus that the current PEP discussion process is sometimes broken anyway, even with a BDFL.

There are definitely perks to having a BDFL such as timely shutdown of side threads, consistency/guidance in design, etc.

[Antoine]

I know what python-ideas can be like routinely (I do read it at times).

I think the general idea of my comment is that the signal-to-noise ratio on python-ideas is so low that, whether or not Guido had remained BDFL, we would still have a productivity problem to solve there.

I'm much more focused here on the underappreciated roles Guido played in the process than the medium in which the process occurred. Regardless of whether it occurs on a high or low S/N mailing list, a wiki, a Github issue, ... a PEP proceeds from freewheeling brainstorming to python-dev-worthy perfection ;-) incrementally, and along the way "yes, this idea is definitely in - stop arguing about it' and "no, that idea is dead - stop repeating it" pronouncements need to be made.

When that doesn't happen by universal consensus, it needs to be forced by _some_ mechanism.

If the people involved vote on what they do and don't like, then we have design by committee.

I'd much rather have a BDFL-workalike. But in that case, they need to be involved and responsive, not just sit back waiting for "a crisis" to rise to their rarefied level. The latter is indeed important for a BDFL-workalike too, but the point here has been that Guido did much more than _just_ put out raging fires, via the multitude of largely unheralded little pronouncements he routinely made to help PEPs-in-progress continue making progress. And to kill PEPs before they were written when he knew he'd never accept the core idea.

On Mon, 16 Jul 2018 at 15:21 Jack Jansen jack.jansen@cwi.nl wrote:

On 16-Jul-2018, at 04:38 , Tim Peters tim.peters@gmail.com wrote:

Guido's most visible (well, to us committers) BDFL role has been in "yes/no", "go/nogo" language/library design questions, which don't even overlap with the PSF's proper concerns.

But I'm not sure it's fully appreciated just how active Guido has been in those at times. The "accepted/rejected" at the end of major PEPs is just a small part of that. Along the way, e.g., it's been pretty common to see a "Save your breath. That's not going to happen." from Guido to end a distracting alternative (sub)proposal persistently promoted by one (or a few) very active and/or loquacious posters.

This is a very good point. And it is a role that is not “formally encoded” anywhere, and one that I think cannot be formally encoded.

And actually I wonder whether this role could be fulfilled by any person/committee/procedure other than Guido himself. Which means that in future we should prepare for doing without this role. Which will lead to more contentious issues being put in front of the whatever-body-replaces-the-bdfl, because the early weeding out isn’t going to happen.

I'm not sure if I agree with that in this case. In terms of this specific case of quickly shutting down dead-end discussions, that comes down to time and dedication and maybe a decently broad knowledge base to grasp a concept quickly enough or ability to learn on their feet. But those are not magical traits of Guido's. To me the question is whether we can replace Guido's design sensibilities.

On Mon, Jul 16, 2018, 17:02 Tim Peters, tim.peters@gmail.com wrote:

[Tim]

...

Guido's most visible (well, to us committers) BDFL role has been in "yes/no", "go/nogo" language/library design questions, which don't even overlap with the PSF's proper concerns.

But I'm not sure it's fully appreciated just how active Guido has been in those at times. The "accepted/rejected" at the end of major PEPs is just a small part of that. Along the way, e.g., it's been pretty common to see a "Save your breath. That's not going to happen." from Guido to end a distracting alternative (sub)proposal persistently promoted by one (or a few) very active and/or loquacious posters.

[Jack Jansen]

...

This is a very good point. And it is a role that is not “formally encoded” anywhere, and one that I think cannot be formally encoded.

And actually I wonder whether this role could be fulfilled by any person/committee/procedure other than Guido himself. Which means that in future we should prepare for doing without this role. Which will lead to more contentious issues being put in front of the whatever-body-replaces-the-bdfl, because the early weeding out isn’t going to happen.

I'm not quite as hopeless ;-) Most notions on python-ideas are dropped voluntarily, after it's clear that they generate little interest - or massive hostility ;-)

For one that proceeds to a preliminary PEP, I think it would be wise for the Elders (whatever it's called) to appoint a BDFL-workalike for that specific PEP. Which may or may not be an Elder. That person would need to commit to staying current with the PEP's progress, and would have final "yes/no", "this/that", ... authority on all the design decisions on the way to polishing the PEP. But not the final accept/reject decision (if the PEP survives that long).

That would do more than "just" provide a BDFL-workalike for the PEP, it would also provide a kind of mentor for PEP writers sometimes pretty clueless about what the community expects from a PEP.

It wouldn't provide a consistent design vision _across_ PEPs, but would at least leave each PEP coherent on its own in _some_ experienced developer's mind. Leaving the final accept/reject to someone else is, in part, a nod to that even a self-coherent PEP may be best rejected for clashing with a broader vision.

This ties into the core dev sponsor idea that got floated where all inexperienced PEP authors need someone to sign up to shepherd them through the process. That way everything is more structured and, with this idea, also more uniform.

-Brett

With a bit of luck, PEP authors and their BDFL-workalikes will come to despise each other so swiftly that no PEP will ever finish again ;-)

On 17 Jul 2018, at 02:02, Tim Peters tim.peters@gmail.com wrote:

[Tim]

...

Guido's most visible (well, to us committers) BDFL role has been in "yes/no", "go/nogo" language/library design questions, which don't even overlap with the PSF's proper concerns.

But I'm not sure it's fully appreciated just how active Guido has been in those at times. The "accepted/rejected" at the end of major PEPs is just a small part of that. Along the way, e.g., it's been pretty common to see a "Save your breath. That's not going to happen." from Guido to end a distracting alternative (sub)proposal persistently promoted by one (or a few) very active and/or loquacious posters. [Jack Jansen]

...

This is a very good point. And it is a role that is not “formally encoded” anywhere, and one that I think cannot be formally encoded.

And actually I wonder whether this role could be fulfilled by any person/committee/procedure other than Guido himself. Which means that in future we should prepare for doing without this role. Which will lead to more contentious issues being put in front of the whatever-body-replaces-the-bdfl, because the early weeding out isn’t going to happen.

I'm not quite as hopeless ;-) Most notions on python-ideas are dropped voluntarily, after it's clear that they generate little interest - or massive hostility ;-)

For one that proceeds to a preliminary PEP, I think it would be wise for the Elders (whatever it's called) to appoint a BDFL-workalike for that specific PEP. Which may or may not be an Elder. That person would need to commit to staying current with the PEP's progress, and would have final "yes/no", "this/that", ... authority on all the design decisions on the way to polishing the PEP. But not the final accept/reject decision (if the PEP survives that long).

I’m not hopeless either:-)

But the point I was trying to make is that Guido has a standing _within the wider community_ that will cause people to sit and ponder his replies, in stead of quickly replying and going into the defensive. The Elders will probably miss that standing in the community at large, at least for the time being. So I think we should prepare for more and longer heated discussions, and make sure that the procedures for the eventual decision are such that people can generally live with the outcome and don’t turn their back on the community.

Jack Jansen, 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