On Wed, Aug 1, 2018 at 12:41 PM, Mariatta Wijaya <mariatta.wij...@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@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
