Home Original page

[python-committers] Transfer of power

Doug Hellmann doug at doughellmann.com
Fri Jul 13 09:59:54 EDT 2018 
Oh, yeah, I guess I wasn’t clear there. I am not suggesting that release managers add this new responsibility. I’m suggesting that a release cycle length is an amount of time the community is used to dealing with, and therefore might make a good cadence for elections or whatever other rotation mechanism is selected for the new group.

Sorry for the confusion.

Doug

> On Jul 13, 2018, at 5:30 AM, Anthony Baxter <anthonybaxter at gmail.com> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto:python-committers at python.org>
> https://mail.python.org/mailman/listinfo/python-committers <https://mail.python.org/mailman/listinfo/python-committers>
> Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180713/19b6ca37/attachment-0001.html>
More information about the python-committers mailing list