[python-committers] Reminder of BDFL succession timeline + CFP
njs at pobox.com
Wed Aug 1 17:22:48 EDT 2018
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
> 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
> 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.
Nathaniel J. Smith -- https://vorpus.org
More information about the python-committers