[python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

Doug Hellmann doug at doughellmann.com
Thu Jul 19 16:29:34 EDT 2018

Excerpts from Brett Cannon's message of 2018-07-19 12:44:23 -0700:
> On Thu, 19 Jul 2018 at 11:52 Doug Hellmann <doug at doughellmann.com> wrote:
> > Excerpts from Antoine Pitrou's message of 2018-07-19 20:07:41 +0200:
> > >
> > > Le 19/07/2018 à 20:00, Carol Willing a écrit :
> > > > I appreciate and respect the importance of these decisions. The dates
> > > > that I suggested, and I am not anchored to any of them, were not
> > > > selected to rush or be hasty. Instead, it was respect for our time
> > > > together (at least some of us) at the September sprint and to have all
> > > > proposals on the table by that time.
> > >
> > > I hadn't thought about the September sprint.  I'd say it's up to people
> > > to discuss those things there if they want or not (I would prefer if we
> > > could avoid discussions in select groups like that, but I don't think
> > > there's any reasonable way to prevent it).
> >
> > The best way to mitigate it is to agree that select groups who happen to
> > be able to meet in person won't make any final decisions, and that any
> > discussions they have that start to trend toward agreement will be
> > summarized to the mailing list so that the folks not able to be present
> > can benefit from and participate in the discussion.
> >
> We already do that for the language summit and I don't think any consensus
> reached at the dev sprints would be any different. My gut says that if we
> haven't reached a consensus on how to handle voting by the dev sprints then
> we will try to reach one there to bring back to the list to see if
> team-wide consensus also exists for the voting proposal.

That plan makes sense to me.

> > > > My biggest concern is that dragging this on into the new year will
> > > > result in more bikeshedding, more uncertainty, and less confidence in
> > > > the developer community decision making ability.
> > >
> > > That's a fair point.  But there's also an opposite concern that
> > > discussions may be deterred or cut short by a too tight deadline.  Even
> > > simple and uncontentious PEPs take time to write, discuss and finalize.
> >
> > Maybe it would be better to focus on a first date for submitting
> > proposals and then wait to set the rest of the deadlines until after
> > we have a bit more of the discussion behind us. That will give us
> > a sense for how much consensus there is and how much more discussion
> > might be needed.
> >
> But the amount of discussion can be unbounded (considering people write PhD
> theses on governance models and voting systems we could talk about this
> stuff forever ;), so putting a schedule in place to help focus the
> discussions can be beneficial.

Sure. I'm just suggesting not rushing to decide what that schedule
should be. Maybe by the time all of the proposals are formally written
up there will be a high enough level of consensus that it will be
possible to move to a decision sooner than we expect right now.

Either way, I do think having a schedule will give folks enough space
and time to consider the options carefully.

> I'm +1 on Mariatta's schedule. That gives people more than 2 months to come
> up with governance proposals and all of us to settle on how we will vote.
> And if we say the month of November will be when voting is open then that
> would give people more then 3 months notice of when the first vote will
> occur.

More information about the python-committers mailing list