[python-committers] Transfer of power

[Anthony Baxter]

As someone who's not been involved for some time now, but was release
manager for a three or four years (2.3.1 through to 2.5.1), trying to have
the release manager also be a decider of potentially controversial things
doesn't seem scalable.

Getting a release out is a heck of a lot of work, both the actually cutting
the alphas, betas, &c, and also triaging issues that comes up and chasing
people up for fixes.

I'm not sure what the proper governance structures should be, but they
absolutely shouldn't be dumping extra load onto the release manager.

On Fri, Jul 13, 2018, 3:49 AM Doug Hellmann <doug at doughellmann.com> wrote:

> Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400:
> > On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou <antoine at python.org>
> wrote:
> > >
> > >
> > > I'd like to point out that the N-virate idea doesn't handle a key
> issue:
> > > once you have a N-virate, how do you evolve its composition according
> to
> > > the implication and motivation of its members - but also to remarks or
> > > frustation by non-virate contributors (especially new contributors who
> > > will feel there's a perpetual category they're locked out of)?  Do you
> > > just wait for people to gently step down when required?
> >
> > One way would be to re-elect them every 5 or so years.  Essentially,
> > an N-virate is a dictator-like entity for a few years.
> >
> > Yury
>
> We've had good luck in the OpenStack community tying leadership to
> release cycles. It causes elections more often (our cycles are 6
> months long), but people tend to step up for several cycles in a
> row so that hasn't been a cause of excessive turnover. Having
> frequent opportunities for folks to step down gracefully when they
> need or want to also means no one feels like they are signing up
> for an indefinite time commitment.
>
> For a multi-person group, staggered elections where only a portion
> of the group is up for election at one time, also provides some
> consistency when there is turnover.
>
> Doug
> _______________________________________________
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180713/94c2314d/attachment.html>