[python-committers] Transfer of power

[Brett Cannon]

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

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

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

-Brett


> With a bit of luck, PEP authors and their BDFL-workalikes will come to
> despise each other so swiftly that no PEP will ever finish again ;-)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180716/b78aca90/attachment.html>