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 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~

On 12/07/18 16:55, Christian Heimes wrote:

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.

Language *implementation* not design. It is much less controversial :)

Thanks for your vote of confidence, but I think there are plenty of others better qualified.

Cheers, Mark.

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 <guido@python.org <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 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

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 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 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

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.

Doug

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.

Excerpts from Christian Heimes's message of 2018-07-12 20:54:05 +0200:

On 2018-07-12 20:50, Brett Cannon wrote:

...

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.

+1

• Primary to delegate responsibilities to domain experts
• Secondary to provide consistency and trust
• Lastly to have final word in case of controversial bike shedding

Christian

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.

Doug

On 12Jul2018 1102, Yury Selivanov wrote:

IOW I don't see anyone (or some group of 3) who is as well-versed in everything on Guido's level.

The actual solution is to ensure the members of the group are humble enough to admit this, and aware enough of the community to be able to identify and nominate the people who are well-versed enough for a particular subject.

We should *always* be able to nominate a core committer to be the designated expert for a particular area (at least for long enough to approve a PEP). If we cannot, the problem is that we don't have anyone for that area, not that the triumvirate isn't well-versed enough themselves.

Cheers, Steve

On 2018-07-12, Yury Selivanov 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.

Modeling the body after a supreme court seems like a good idea. They don't have to make day-to-day decisions, only settle disputes that cannot be resolved by normal processes.

Having an N-virate entity would diffuse some of the criticism they will almost certainly receive for their decisions. Having them serve for multiple years will provide more consistency of direction. Having multiple members will allow members to be replaced without too much disruption.

The most important decision is what will we call this entity? ;-P I'm sure Barry will have a good idea. Is a "cabal" the correct term?

Cheers,

Neil

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 07/13/2018 03:30 PM, Barry Warsaw wrote:

On Jul 13, 2018, at 15:11, Jack Jansen <jack.jansen@cwi.nl> wrote:

...

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)? Possibly, but even if unanimity can’t be achieved, I feel strongly that any decision coming from the GUIDO/Cabal/Council should be give as a single party. E.g. if Alice and Bob +1 PEP 801 and Carol -1’s it, I don’t think any purpose is served by breaking that out into individual votes. I would hope that the council members support each other and the body’s decision even if it doesn’t go an individual’s way.

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,

//arry/

On 07/13/2018 04:20 PM, Steve Dower wrote:

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.

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 :)

Despite the smiley etc, this is a reasonable point.  But!  I think it's inevitable.  As the BDFL Guido received more than his fair share of idolatry and demonization (cf. the PEP 572 discussion). It's a natural consequence of having identifiable people in charge of a project as popular as Python.  Having the PCOE keep its votes / dissent private wouldn't eliminate the consequences of fame for its members--all I'd expect is that it'd be more evenly distributed.

//arry/

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.

-eric

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 2:04 PM Antoine Pitrou <antoine@python.org> wrote:

That might be a minority view, but I don't think anyone except Guido would be legitimate as a Python BDFL.

+1

[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 ;-)

On Thu, Jul 12, 2018 at 8:41 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:

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

+1

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 was going to recommend the same names :)

--Berker

On Jul 12, 2018, at 11:16, Steven D'Aprano <steve@pearwood.info> wrote:

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

And of course, Uncle Timmy was the original FLUFL, before Guido and Brett did their nefarious edits. :)

-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 Thu, 12 Jul 2018 at 10:13 Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:

Guido,

Thank you for all you've done for Python. It is well deserved break.

I'm sad, but I like to see this as an opportunity to further improve Python and this community.

My first instinct is to suggest: instead of one successor, we will have several people as the new "leaders", perhaps a co-BDFL, or even 3-5 people as co-BDFLs/leaders. This is based on my experience with organizing meetup and conference (although these are not comparable to leading the community like Python). The benefit is to lessen the burden and responsibilities of one person, and they will have backups when they need to go on a break, vacation, take care of personal life.

Another thing that came to my mind is, who is actually able (have the time and energy) to take on this role? Most of us in open source are volunteering on limited free time available. I'm aware some of you have employer support, but most don't. Will this limit the candidacy to certain people just because they have the employer support?

I think it will limit it to people who feel they are up for it. I'm not sure what Guido's time commitment was in the end pre-PEP 572, but outside of major PEP discussions I don't think the time commitment should be huge (and if you delegate a PEP then even less :) . So I don't think it necessitates work time, but you might want to check with your family if they are happy with your current engagement level. ;)

What is the role of the successor(s)? Do we assume "whatever Guido did", or is this an opportunity to come up with a new process?

That's why Guido is leaving it up to us. :)

For me the key function Guido provided was tone and consistency in design. So whatever we replace Guido with should be something that will represent us in a way we are all proud to stand behind. And then from there the design consistency suggests a first line of yea/nay on PEPs and then delegation. I don't think we can just have a "delegation committee" which doesn't make initial rejections since that would then leave the over-arching design of the language unguided unless the "delegation chooser" consistently chose the same person, informally choosing a design dictator anyway. ;)

One useful resource is Vicky Brasseur's talk: Passing the Baton, Succession planning for your project https://www.youtube.com/watch?v=Jhkm2PA_Gf8 The slides: https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-py...

Some ideas from that talk:

1. identify critical roles (e.g. PEP decision making)
2. refactor large roles
3. mentor the new successor, shadow the previous leader
4. document all the things

This might be selfish request, but I hope you can still assume power until we have new successor(s).

Thanks.

Mariatta

On Thu, Jul 12, 2018 at 7: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/

---

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

On Jul 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 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

[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).

[Tim]

...

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

[Ethan Furman]

Forgive my ignorance, but how does one become a PSF member?

That depends on which year you ask ;-) The current rules are here:

https://www.python.org/psf/membership/

That also defines what I meant by "Fellows".

[Nathaniel Smith <njs@pobox.com>]

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 that's just anecdotal, apparently cherry-picking the oldest people of the time the author could find, and misleadingly saying "George Washington was a young 67 [at death]", implying that was exceptionally young. A better account is here, which shows a bell-like curve for _all_ the Founders' death ages, peaking in the 60s (Washington did not die exceptionally young - except by _contemporary_ standards):

https://en.wikipedia.org/wiki/Founding_Fathers_of_the_United_States#Youth_an...

I happily grant that the vast bulk of mean expectancy increase is due to surviving early childhood, but it's not true either that life expectancy at (say) age 30 hasn't also increased.

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 :-).

The subject "Transfer of power" is a pretty good clue that building tools (etc) isn't the primary topic of this thread ;-) We're looking to fill the void left by an Absolute Dictator for Life stepping down. It's important to get that part right too, because "by the time you're voting on something you're already failed" is a thing that will happen, and repeatedly. Guido has been the last, best resort in such cases.

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.

Maybe people don't want a dictatorial court of last resort at all. That would be germane too.

[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 ;-)

[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).

[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 :-)

[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.

[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 ;-)

[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 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.

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

[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.

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 ;-)

Le 17/07/2018 à 04:07, Brett Cannon a écrit :

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

This sounds like a reasonable policy. We could stipulate that a non-core developer can't get a PEP examined if they didn't go through the shepherding process (which implies there exists a core developer motivated enough to shepherd them, which may help weed out the silliest ideas).

Regards

Antoine.

Excerpts from Jack Jansen's message of 2018-07-17 11:33:22 +0200:

...

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.

I agree that having a consensus-based process that everyone agrees to use and abide by is important.

Perhaps we can also take change the process to start eliminating the culture that leads to so much heat in the first place. Healthy debate is all well and good, but it seems like we've had a couple of examples of things getting out of hand recently.

Doug

[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 :-)

On Mon, 16 Jul 2018 at 00:17 Chris Jerdonek <chris.jerdonek@gmail.com> wrote:

...

[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

On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters <tim.peters@gmail.com> wrote: pronouncements

...

were mostly about language and library design issues.

I only had in mind technical things. Non-technical things didn't cross my mind. The types of cases I had in mind were (in the abstract) (1) a feature is rolled out which later turns out to have a severe defect, and so it needs to be fixed somehow, and people are divided on how it should be fixed; (2) something changes outside of Python (e.g. something OS related), which is or will cause a severe defect for Python users, and people can't agree on how it should be fixed; and (3) (a case you mentioned) there is a feature that everyone wants to add, but people are split on some bike shed issue. It's true that a stalemate for (3) wouldn't be so bad, but it would prevent something that everybody wants.

For (1) and (2), I'm probably not the best person to provide an example. But one case in the back of my mind that may have prompted my reply and that might qualify was when there was a randomness-related security issue in the summer of 2016. I believe this is the thread that kicked it off (subject line: "BDFL ruling request: should we block forever waiting for high-quality random bits?"): https://mail.python.org/pipermail/python-dev/2016-June/144939.html

Things got so contentious on python-dev that, IIRC, at least one core developer quit or was threatening to quit, and it prompted the creation of a new mailing list (Security-SIG) due to the volume of emails. See the number of emails the thread above spurred alone: https://mail.python.org/pipermail/python-dev/2016-June/thread.html

To resolve the split, Guido ultimately chose PEP 524 over PEP 522.

But that's an extremely rare case. And even then, I would assume the council would have picked a BDFL delegate who would have made the utlimate decision. So even in a stalemate there's a way out by the council saying "not it" and pointing at someone else.

-Brett

...

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).

There's another alternative. You can make a rule that they're not allowed to abstain (or some variant, like you have to choose someone else if you need to recuse yourself). I'm a member of such a body in fact (the San Francisco Elections Commission). If a member wants to abstain, a member has to request it, and then the Commission has to pass a majority vote to let the person to abstain. But we wouldn't even have to have that extra provision.

--Chris

...

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 :-)

On Sat, 14 Jul 2018 at 00:16 Łukasz Langa <lukasz@langa.pl> wrote:

...

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 think because it's small enough to be manageable and have consistency in outcomes (which is what I would want if these folks are the design stewards). IOW it prevents design-by-committee scenarios.

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.

I'm personally not worried about the single corporation issue as we've basically had that under Guido since the beginning. :) I would also hope that anyone who ends up in this position is trusted enough to put Python above any potential pressure from their employer.

While I prefer 3, I can see 5 working. Basically I think the number should be small enough that you can have a casual conversation with everyone involved and not feel like it's a committee meeting.

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?

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

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)