[python-committers] Identify roles of the BDFL

[Barry Warsaw]

On Jul 13, 2018, at 03:40, Victor Stinner <vstinner at redhat.com> wrote:

> Should we split the role "take the final decision on PEPs" into
> sub-roles for example? Do we need in advance to define BDFL-delegate
> for some kinds of PEPs? Or the BDFL should define per-PEP, which ones
> he doesn't want to handle and need a BDFL-delegate? In my experience,
> the BDFL delegation was done naturally, was not the source of
> conflict, and usually discussed directly with the BDFL.

I don’t think we need to be so formal about delegation.  As you say, it should generally happen naturally.

I actually think delegation will be more common, leaving mostly the language-level Standards Track PEPs for the BDFL (Benevolent Design Faction Lifers - okay, still playing with names :).

One tricky thing with delegation will be when a natural delegate is also the author of the PEP. For example, if Yury proposed some changes to async, he wouldn’t also be able to pronounce on it.  OTOH, Guido is of course still a developer and could be a delegate for such PEPs if he wants.  Just something to be aware of.

It’s possible that more decisions that have previously been informal will be best served by the PEP process.  For example, the pronouncement that dictionaries officially preserve insertion order would likely be handled as a succinct PEP.  One of the roles of the council would be to decide whether a change is PEP-worthy or not.  It’s possible that ideas that only show up on the tracker for example, need to be promoted into a PEP, and it would be up to the developer community to help identify those potential changes.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180713/2de08466/attachment.sig>