Re: [python-committers] Transfer of power

[Doug Hellmann]

Excerpts from Jack Jansen's message of 2018-07-17 11:33:22 +0200:
> 
> > On 17 Jul 2018, at 02:02, Tim Peters  wrote:
> > 
> > [Tim]
> >> Guido's most visible (well, to us committers) BDFL role has been in 
> >> "yes/no", "go/nogo" language/library design questions, which don't even 
> >> overlap with the PSF's proper concerns.
> >> 
> >> But I'm not sure it's fully appreciated just how active Guido has been in 
> >> those at times.  The "accepted/rejected" at the end of major PEPs is just 
> >> a small part of that.  Along the way, e.g., it's been pretty common to see 
> >> a "Save your breath.  That's not going to happen." from Guido to end a 
> >> distracting alternative (sub)proposal persistently promoted by one (or a 
> >> few) very active and/or loquacious posters.
> > [Jack Jansen]
> >  
> >> This is a very good point. And it is a role that is not “formally encoded” 
> >> anywhere, and one that I think cannot be formally encoded.
> >> 
> >> And actually I wonder whether this role could be fulfilled by any 
> >> person/committee/procedure other than Guido himself. Which means that in 
> >> future we should prepare for doing without this role. Which will lead to 
> >> more contentious issues being put in front of the 
> >> whatever-body-replaces-the-bdfl, because the early weeding out isn’t going 
> >> to happen.
> >> 
> > I'm not quite as hopeless ;-)  Most notions on python-ideas are dropped 
> > voluntarily, after it's clear that they generate little interest - or 
> > massive hostility ;-) 
> > 
> > For one that proceeds to a preliminary PEP, I think it would be wise for 
> > the Elders (whatever it's called) to appoint a BDFL-workalike for that 
> > specific PEP.  Which may or may not be an Elder.  That person would need to 
> > commit to staying current with the PEP's progress, and would have final 
> > "yes/no", "this/that", ...  authority on all the design decisions on the 
> > way to polishing the PEP.  But not the final accept/reject decision (if the 
> > PEP survives that long).
> 
> I’m not hopeless either:-)
> 
> But the point I was trying to make is that Guido has a standing _within the 
> wider community_ that will cause people to sit and ponder his replies, in 
> stead of quickly replying and going into the defensive. The Elders will 
> probably miss that standing in the community at large, at least for the time 
> being. So I think we should prepare for more and longer heated discussions, 
> and make sure that the procedures for the eventual decision are such that 
> people can generally live with the outcome and don’t turn their back on the 
> community.

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

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

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

Re: [python-committers] Transfer of power

[Jack Jansen]

> On 17 Jul 2018, at 02:02, Tim Peters  wrote:
> 
> [Tim]
>> Guido's most visible (well, to us committers) BDFL role has been in 
>> "yes/no", "go/nogo" language/library design questions, which don't even 
>> overlap with the PSF's proper concerns.
>> 
>> But I'm not sure it's fully appreciated just how active Guido has been in 
>> those at times.  The "accepted/rejected" at the end of major PEPs is just a 
>> small part of that.  Along the way, e.g., it's been pretty common to see a 
>> "Save your breath.  That's not going to happen." from Guido to end a 
>> distracting alternative (sub)proposal persistently promoted by one (or a 
>> few) very active and/or loquacious posters.
> [Jack Jansen]
>  
>> This is a very good point. And it is a role that is not “formally encoded” 
>> anywhere, and one that I think cannot be formally encoded.
>> 
>> And actually I wonder whether this role could be fulfilled by any 
>> person/committee/procedure other than Guido himself. Which means that in 
>> future we should prepare for doing without this role. Which will lead to 
>> more contentious issues being put in front of the 
>> whatever-body-replaces-the-bdfl, because the early weeding out isn’t going 
>> to happen.
>> 
> I'm not quite as hopeless ;-)  Most notions on python-ideas are dropped 
> voluntarily, after it's clear that they generate little interest - or massive 
> hostility ;-) 
> 
> For one that proceeds to a preliminary PEP, I think it would be wise for the 
> Elders (whatever it's called) to appoint a BDFL-workalike for that specific 
> PEP.  Which may or may not be an Elder.  That person would need to commit to 
> staying current with the PEP's progress, and would have final "yes/no", 
> "this/that", ...  authority on all the design decisions on the way to 
> polishing the PEP.  But not the final accept/reject decision (if the PEP 
> survives that long).

I’m not hopeless either:-)

But the point I was trying to make is that Guido has a standing _within the 
wider community_ that will cause people to sit and ponder his replies, in stead 
of quickly replying and going into the defensive. The Elders will probably miss 
that standing in the community at large, at least for the time being. So I 
think we should prepare for more and longer heated discussions, and make sure 
that the procedures for the eventual decision are such that people can 
generally live with the outcome and don’t turn their back on the community.
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



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

Re: [python-committers] Transfer of power

[Antoine Pitrou]

Le 17/07/2018 à 04:07, Brett Cannon a écrit :
> 
> This ties into the core dev sponsor idea that got floated where all
> inexperienced PEP authors need someone to sign up to shepherd them
> through the process. That way everything is more structured and, with
> this idea, also more uniform.

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

Regards

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

Re: [python-committers] Transfer of power

[Brett Cannon]

On Mon, Jul 16, 2018, 17:02 Tim Peters,  wrote:

> [Tim]
>
>> Guido's most visible (well, to us committers) BDFL role has been in
>> "yes/no", "go/nogo" language/library design questions, which don't even
>> overlap with the PSF's proper concerns.
>>
>> But I'm not sure it's fully appreciated just how active Guido has been in
>> those at times.  The "accepted/rejected" at the end of major PEPs is just a
>> small part of that.  Along the way, e.g., it's been pretty common to see a
>> "Save your breath.  That's not going to happen." from Guido to end a
>> distracting alternative (sub)proposal persistently promoted by one (or a
>> few) very active and/or loquacious posters.
>>
>> [Jack Jansen]
>
>
>> This is a very good point. And it is a role that is not “formally
>> encoded” anywhere, and one that I think cannot be formally encoded.
>>
>> And actually I wonder whether this role could be fulfilled by any
>> person/committee/procedure other than Guido himself. Which means that in
>> future we should prepare for doing without this role. Which will lead to
>> more contentious issues being put in front of the
>> whatever-body-replaces-the-bdfl, because the early weeding out isn’t going
>> to happen.
>>
>>
>> I'm not quite as hopeless ;-)  Most notions on python-ideas are dropped
> voluntarily, after it's clear that they generate little interest - or
> massive hostility ;-)
>
> For one that proceeds to a preliminary PEP, I think it would be wise for
> the Elders (whatever it's called) to appoint a BDFL-workalike for that
> specific PEP.  Which may or may not be an Elder.  That person would need to
> commit to staying current with the PEP's progress, and would have final
> "yes/no", "this/that", ...  authority on all the design decisions on the
> way to polishing the PEP.  But not the final accept/reject decision (if the
> PEP survives that long).
>
> 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 ;-)
>
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Tim Peters]

[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 ;-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Mon, 16 Jul 2018 at 15:21 Jack Jansen  wrote:

>
>
> On  16-Jul-2018, at 04:38 , Tim Peters  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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Jack Jansen]

> On  16-Jul-2018, at 04:38 , Tim Peters  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, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



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

Re: [python-committers] Transfer of power

[Tim Peters]

[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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Tim Peters]

[Chris Jerdonek]

> ... 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.
>
>
[Brett Cannon]

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


In the original message of that thread, the release manager had already
made a decision, but was getting so much opposition to his position that he
appealed to Guido.  But the RM already had authority to make the decision.
Highly contentious decisions will always be appealed to the full height of
whatever bureaucracy exists ;-)  It turned out Guido agreed with the RM in
this case.

The PEPs came later, and were much less contentious than the original
under-time-pressure decision.

Regardless, I agree with Chris that it would be good to spell out what to
do if the Ultimate Authority can't, or won't, reach a decision on their
own.  Indeed, that's the exact position Guido just left us in ;-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Sun, 15 Jul 2018 at 19:38 Tim Peters  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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Mon, 16 Jul 2018 at 00:17 Chris Jerdonek 
wrote:

> On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters  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
> 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 :-)
> >
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Antoine Pitrou]

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Tim Peters]

[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 ;-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Antoine Pitrou]

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Chris Jerdonek]

On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters  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 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.

> 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 :-)
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Tim Peters]

[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 :-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Chris Jerdonek]

On Sun, Jul 15, 2018 at 6:07 PM Brett Cannon  wrote:

> On Sat, 14 Jul 2018 at 11:37 Tim Peters  wrote:
>
>> [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.
>>
>
> 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.
>

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.

—Chris



> -Brett
>
>
>>
>>
>>
>>> 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 :-)
>>
>> ___
>> 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/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Tim Peters]

[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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Sat, 14 Jul 2018 at 11:37 Tim Peters  wrote:

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

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.

-Brett


>
>
>
>> 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 :-)
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Guido van Rossum]

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

>
>
> On Sun, Jul 15, 2018, 13:01 Thomas Wouters,  wrote:
>
>> On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov 
>> wrote:
>>
>>> On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon  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 
>>
>> 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)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Sun, Jul 15, 2018, 13:01 Thomas Wouters,  wrote:

> On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov 
> wrote:
>
>> On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon  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 
>
> 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/

Re: [python-committers] Transfer of power

[Thomas Wouters]

On Sun, Jul 15, 2018 at 8:53 AM Yury Selivanov 
wrote:

> On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon  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 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 14, 2018, at 00:16, Łukasz Langa  wrote:

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

Yes, I’ve been thinking the same thing.  PEP 2 would serve as the Python 
development constitution.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Yury Selivanov]

On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Sat, 14 Jul 2018 at 00:16 Łukasz Langa  wrote:

>
> > On Jul 13, 2018, at 7:54 PM, Tim Peters  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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Tim Peters]

[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 :-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Giampaolo Rodola']

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

I owe my entire career to you.
Your creation has influenced my life and decision making in a very
profound way.
I cannot tell you how grateful I am for what you did throughout all
these years.
I am sincerely sad to see you resigning from your role.

-- 
Giampaolo - http://grodola.blogspot.com
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Łukasz Langa]

> On Jul 13, 2018, at 7:54 PM, Tim Peters  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?

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

Re: [python-committers] Transfer of power

[Nick Coghlan]

On 13 July 2018 at 00: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.

Guido, thank you for the immense amount of time and energy you've
devoted to both designing and developing Python-the-language, and also
to building and supporting python-dev-the-collaborative-community.

I know I'd be a different person without the years of freely shared
experience, knowledge, and advice that I've benefited from by being
part of this group.

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

Take all the time you need - you've built a strong design community
here, and hopefully we can arrange things in away that allows you to
rediscover the fun parts of contributing without the burden of always
needing to be the ultimately responsible decision maker :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Gregory P. Smith]

On Thu, Jul 12, 2018 at 12:17 PM Brett Cannon  wrote:

> On Thu, 12 Jul 2018 at 11:53 Barry Warsaw  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Tim Peters]

[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 ;-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Nathaniel Smith]

On Fri, Jul 13, 2018 at 8:22 PM, Tim Peters  wrote:
> [Nathaniel Smith ]
>>
>> 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.html
>
> But that's just anecdotal, [...]

Yeah, it's an off-topic digression anyway so I was simplifying and
didn't spend much time looking for the perfect link. Looking a bit it
seems like in ~1790 a 20-year old white male in the US could expect to
live another ~45 years, and today that's up to ~55 years, and then the
numbers get closer together as the ages increase. Which is about what
I had in mind for "not too different".

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

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. But I doubt it's the best one. Guido is, quite literally,
irreplaceable.

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

-n

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

Re: [python-committers] Transfer of power

[Tim Peters]

[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 long 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).
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Tim Peters]

[Nathaniel Smith ]

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


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_and_longevity

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Tim Peters]

[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".
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Nathaniel Smith]

On Fri, Jul 13, 2018 at 6:54 PM, Tim Peters  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.html

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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Larry Hastings]

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/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Steve Dower]

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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Larry Hastings]

On 07/13/2018 03:30 PM, Barry Warsaw wrote:

On Jul 13, 2018, at 15:11, Jack Jansen  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/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 13, 2018, at 02:30, Anthony Baxter  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



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 13, 2018, at 15:11, Jack Jansen  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.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Jack Jansen]

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, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



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

Re: [python-committers] Transfer of power

[Doug Hellmann]

Oh, yeah, I guess I wasn’t clear there. I am not suggesting that release 
managers add this new responsibility. I’m suggesting that a release cycle 
length is an amount of time the community is used to dealing with, and 
therefore might make a good cadence for elections or whatever other rotation 
mechanism is selected for the new group.

Sorry for the confusion.

Doug

> On Jul 13, 2018, at 5:30 AM, Anthony Baxter  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. 
> 
> Getting a release out is a heck of a lot of work, both the actually cutting 
> the alphas, betas, , 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  > 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  > > 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/ 
> 

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

Re: [python-committers] Transfer of power

[Anthony Baxter]

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, , 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  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 
> 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/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Paul Moore]

On 12 July 2018 at 15:57, Guido van Rossum  wrote:
> But I'm basically giving myself a permanent vacation from being BDFL, and you 
> all will be on your own.

I just want to echo everyone else's sentiments and say thank you for
all the work you've done, and for the example you've set to all of us.
Like many others here, my life would have been quite different without
Python. Even though I've never met you in person, you've been a huge
influence for me.

Best wishes for the future.
Paul
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Senthil Kumaran]

On Thu, Jul 12, 2018 at 7:57 AM, Guido van Rossum  wrote:

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

Thank you, Guido, for being the BDFL of Python. As the title goes, it is
for Life.  :-)

I wouldn't worry about the governance process now.  We will figure out
something that will work.  You have steered in the right direction with the
right people.
I hope, you will find rest and peace with the break you are taking. I heard
it somewhere that there isn't a concept of retirement for artists. I am
inclined to believe that it might be the same for certain programmers.

Good luck with your happy break :-)

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

Re: [python-committers] Transfer of power

[Robert Collins]

On Fri., 13 Jul. 2018, 02:58 Guido van Rossum,  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

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

Re: [python-committers] Transfer of power

[Larry Hastings]

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

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

Re: [python-committers] Transfer of power

[Łukasz Langa]

> On Jul 12, 2018, at 2:27 PM, Raymond Hettinger  
> 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.

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

Re: [python-committers] Transfer of power

[Pablo Galindo Salgado]

Thank you so much for creating a language that is much bigger than itself
and for your passion
and commitment along all these years. I hope you enjoy this well-deserved
vacation :)

Paraphrasing [this](
http://neopythonic.blogspot.com/2013/10/letter-to-young-programmer.html)
letter of yours:

 Thank you so much for have dreamed so big!

Regards from cloudy London,
Pablo Galindo Salgado
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Ethan Furman]

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~
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Davin Potts]

Per Antoine's comment:
> 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 ;-)

I think all agree that there simply is no replacing Guido, there is only
succeeding Guido and demonstrating that what he has built and cultivated in
this community and those on this mailing list is self-sustaining.


Per Christian's comment, repeated by many:
> How about a form of presbyterian polity in the form of a triumvirate

+1
+1
+1


Per Brett's comment:
> 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

Consistency, I suggest, outweighs many of our other valid concerns raised
so far.  I support the approach of sorting out over time how the
composition of the triumvirate changes and when -- legislating how things
work before we have a good sense of things will quickly become
problematic.  I have faith in the people we are choosing from for the first
triumvirate.



Per Raymond's comment:
> Sorry the PEP process was so painful.  I hope your decision to have a
> permanent vacation will lift a great weight from your shoulders and that
> you will derive more joy from just being a far from ordinary core dev.

+1



Davin

On Thu, Jul 12, 2018 at 2:38 PM, Eric Snow 
wrote:

> On Thu, Jul 12, 2018 at 1:29 PM Brett Cannon  wrote:
> > On Thu, 12 Jul 2018 at 10:42 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.
> >
> > 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
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Raymond Hettinger]

> On Jul 12, 2018, at 6:14 PM, Antoine Pitrou  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Ethan Furman]

Guido,

Thank you for creating Python.

Thank you for giving me a second chance when I mouthed off to you.

Thank you for trusting us enough to leave this great project in our hands.

Thank you.

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

Re: [python-committers] Transfer of power

[Eric Snow]

On Thu, Jul 12, 2018 at 1:29 PM Brett Cannon  wrote:
> On Thu, 12 Jul 2018 at 10:42 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.
>
> 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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Thu, 12 Jul 2018 at 10:42 Eric Snow  wrote:

> On Thu, Jul 12, 2018 at 10:55 AM Yury Selivanov 
> 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.
>

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 :) .
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

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.

-Barry




signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 12, 2018, at 11:21, Tim Peters  wrote:
> 
> If Barry had been BDFL all along, only features useful to Mailman would have 
> gotten in ;-)

I would have stuck around just long enough to kill off !=

diamonds-are-a-flufl’s-best-friend-ly y’rs,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Antoine Pitrou]

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 12, 2018, at 11:16, Steven D'Aprano  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



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Carol Willing]

> On Jul 12, 2018, at 11:53 AM, Barry Warsaw  > wrote:
> 
> On Jul 12, 2018, at 07:57, Guido van Rossum  > 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 


Warmly,

Carol




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

Re: [python-committers] Transfer of power

[Doug Hellmann]

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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Thu, 12 Jul 2018 at 11:53 Barry Warsaw  wrote:

> On Jul 12, 2018, at 07:57, Guido van Rossum  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. :)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Christian Heimes]

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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 12, 2018, at 07:57, Guido van Rossum  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





signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Christian Heimes]

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

I understand that you are worried. But you don't have to be member of an
hypothetical N-virate in order to stir asyncio into the future. I
assumme that the trusted and wise members of the N-virate will recognize
you as domain expert for asyncio and listen to your advise. We already
have the concept of BDFL delegate for PEPs and should adapt the idea.

As Brett pointed out in one of his replies, N-virate should guarantee
long-term stability and consistency of the language. It's not the job of
the N-virate to control every little details. I envision the gremium a
bit like SCOTUS. SCOP, Supreme Court of Python, has a nice ring.

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/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Thu, 12 Jul 2018 at 11:28 Antoine Pitrou  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 
> 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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Éric Araujo]

  Hello,

Le 2018-07-12 à 13:55, Neil Schemenauer a écrit :
> 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?

  I fear the general public may not get the self-mocking humour here.

  A note about triumvirate: it means three men, not three people.

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

Re: [python-committers] Transfer of power

[Antoine Pitrou]

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  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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Doug Hellmann]

Excerpts from Brett Cannon's message of 2018-07-12 11:11:49 -0700:
> On Thu, 12 Jul 2018 at 11:02 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.  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Tim Peters]

[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 ;-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Steven D'Aprano]

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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Steve Dower]

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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Steve Dower]

On 12Jul2018 1104, Antoine Pitrou wrote:


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


+1. If Guido had designated a successor, I'd be all for it, but I don't 
see any stable future if we try to select one person to fill that role.



Regards

Antoine.

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

Re: [python-committers] Transfer of power

[Brett Cannon]

On Thu, 12 Jul 2018 at 11:02 Yury Selivanov  wrote:

> On Thu, Jul 12, 2018 at 1:50 PM Brett Cannon  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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Alexander Belopolsky]

On Thu, Jul 12, 2018 at 2:04 PM Antoine Pitrou  wrote:

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

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

Re: [python-committers] Transfer of power

[Antoine Pitrou]

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Thu, 12 Jul 2018 at 10:13 Mariatta Wijaya 
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-pyconau2017-successionplanning-with_notes.pdf
>
> 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  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.
>>
>> --
>> 

Re: [python-committers] Transfer of power

[Yury Selivanov]

On Thu, Jul 12, 2018 at 1:50 PM Brett Cannon  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Berker Peksağ]

On Thu, Jul 12, 2018 at 8:41 PM, Eric Snow  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Neil Schemenauer]

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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Eric Snow]

On Thu, Jul 12, 2018 at 11:55 AM Brett Cannon  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brett Cannon]

On Thu, 12 Jul 2018 at 10:42 Eric Snow  wrote:

> On Thu, Jul 12, 2018 at 10:55 AM Yury Selivanov 
> 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. :)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Doug Hellmann]

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

Re: [python-committers] Transfer of power

[Eric Snow]

On Thu, Jul 12, 2018 at 10:55 AM Yury Selivanov  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Yury Selivanov]

On Thu, Jul 12, 2018 at 12:58 PM 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 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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Raymond Hettinger]

> On Jul 12, 2018, at 4:57 PM, Guido van Rossum  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.

Sorry the PEP process was so painful.  I hope your decision to have a permanent 
vacation will lift a great weight from your shoulders and that you will derive 
more joy from just being a far from ordinary core dev.


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

Re: [python-committers] Transfer of power

[Steve Dower]

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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Mariatta Wijaya]

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?

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?

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-pyconau2017-successionplanning-with_notes.pdf

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

Re: [python-committers] Transfer of power

[Antoine Pitrou]

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

Re: [python-committers] Transfer of power

[Jeff Hardy]

On Thu, Jul 12, 2018 at 7:57 AM, 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?
>
> 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.

Thank you, Guido, for everything that you're done, and enjoy your
well-deserved rest.

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

Re: [python-committers] Transfer of power

[Yury Selivanov]

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  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Brian Quinlan]

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

Hey Guido,

Thank you so much for creating Python and nurturing it for the last 25+
years. I, and many others on the list, have built our careers around Python
and we own you a huge amount of gratitude.

So thank you very much and I hope that your retirement goes better than it
does for most dictators ;-)

Cheers,
Brian


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

Re: [python-committers] Transfer of power

[Brett Cannon]

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

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/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Mark Shannon]

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Mark Shannon]

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Hynek Schlawack]

Guido,

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

Since you only announced it here so far, this also seems the only proper place 
to thank you for 27 years of service…and Python of course. :)

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

I believe none of us is an expert in *this* kind of problems so I’m positive it 
would be beneficial to a) look what others did and process it into a PEP(?), b) 
possibly even involve someone external who *is* an expert like PyCon US did 
with their CoC, and most importantly c) never, ever quote works of ESR.

Enjoy your break!
—h

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

Re: [python-committers] Transfer of power

[Antoine Pitrou]

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/
> 
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Victor Stinner]

Hi,

2018-07-12 16:57 GMT+02:00 Guido van Rossum :
> 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-...@python.org/thread/QT7SKORCF6OKWO3OVP5KO6XNGU2AR6TU/
"

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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Christian Heimes]

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/