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

[Jack Jansen]

Nathaniel, you strike the nail on the head here.

The reason Guido as BDFL and therefore ultimate authority on what “python” is worked because it is organic: it is not set down in strict rules and regulations and timelines and percentages of votes and what not. It works because a very large fraction of the community accepts it. (And I know I’m mixing past and present tense and I’m doing it on purpose:-)

We need to come up with a new governance model, and I think that a rules-and-regulations model is not a model that Python will thrive by. On the contrary, I think it has the danger of moving people into a rules-and-regulations mindset, and therefore lead to all sorts of decisions being viewed in a “political” light, where before they wouldn’t be.

And my worry is that be introducing deadlines and all that in the process there is the danger that we will inexorably move to a strict governance model. I would much prefer a process where we go here/there/everywhere and slowly a consensus builds up.

Jack

Sent from my iPad

> On Aug 1, 2018, at 23:22, Nathaniel Smith <njs at pobox.com> wrote:
> 
> 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
> 
> -- 
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/