[python-committers] Reminder of BDFL succession timeline + CFP

Antoine Pitrou antoine at python.org
Wed Aug 1 17:28:56 EDT 2018

I think Nathaniel and Marc-André are speaking wisely here.
Sorry, I've not much to add ;-)



Le 01/08/2018 à 23:22, Nathaniel Smith a écrit :
> On Wed, Aug 1, 2018 at 12:41 PM, Mariatta Wijaya
> <mariatta.wijaya at gmail.com> wrote:
>> Since this is like a CFP I figured we should clarify what's expected the
>> proposal, and I also wanted to be more detailed in the timeline.
>> Oct 1 00:00:00 UTC: Deadline of coming up with proposals of governance
>> model.
>> To be included in the proposal:
>> - explanation and reasoning of the governance model
>> - expected roles and responsibilities
>> - candidate for the role need not be included at this time, since we're only
>> choosing the governance model. Depending on the governance model chosen, we
>> might have different people to be nominated. There will be a separate
>> process for nominating the candidate.
>> - the term of governance: is it for life? 5 years? 10 years?
>> Who can submit the proposal?
>> Python core developers. Individual core devs can submit a proposal, or
>> co-author the proposal with another core dev.
>> How to submit the proposal?
>> Proposal should be in a form of a PEP, and merged into peps repo before Oct
>> 1 00:00:00 UTC. Proposals not merged after Oct 1 00:00:00 UTC will not be
>> considered.
>> Oct 1 - Nov 15: Review period.
>> All core developers will review the PEPs, and ask any questions to the PEP
>> author. This timeline allows for enough time for all core devs to carefully
>> review each PEPs, and for authors to respond.
>> There will be two parts of this:
>> Review phase 1: Oct 1- Nov 1: Allow changes and tweaks to the proposed PEPs.
>> I figured people will have questions and will need to clarify the PEPs
>> during this period. But if we want the PEP to be final by Oct 1, that's fine
>> by me. maybe allow typo fixes still.
>> Review phase 2: Nov 1 00:00:00 UTC: No more changes to the above PEPs.
>> No more tweaks to these PEPs. PRs to these PEPs should be rejected.
>> This is the final chance to carefully review all governance PEPs, and
>> formulate your decisions.
> I'm worried that this whole plan is a bad idea.
> This kind of process with deadlines, proposals, votes, etc., is an
> excellent way to take legitimacy and make it visible. That's a
> valuable thing, and addresses an important problem. But it's not the
> problem I'm most worried about here.
> As engineers, we know that every design has trade-offs, and that goes
> for governance as well. Having a universally acclaimed BDFL like Guido
> has many tremendous advantages. But it also has one tremendous
> disadvantage: because we always knew Guido would make the final
> decision, and that we could always appeal to him when things didn't go
> the way we like, python-dev has never had to learn to work out
> disagreements and get along.
> Now we have to figure that out: the legitimacy of any new governance
> system is ultimately going to have to rest on the consensus of the
> core devs. The only way I know to get that is by taking the time to
> work through the difficult conversations. If these deadlines just
> encourage people to keep moving and engaging, then that's great. But I
> worry that if we impose a cut-off like this up front, then we'll take
> that as an excuse to skip doing that work, because there's no time,
> and if someone disagrees it's easier to vote than to actually engage
> and work it out.
> -n

More information about the python-committers mailing list