<div dir="auto">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. <div dir="auto"><br></div><div dir="auto">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.<div dir="auto"><br></div><div dir="auto">I'm not sure what the proper governance structures should be, but they absolutely shouldn't be dumping extra load onto the release manager.</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 13, 2018, 3:49 AM Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400:<br>
> On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou <<a href="mailto:antoine@python.org" target="_blank" rel="noreferrer">antoine@python.org</a>> wrote:<br>
> ><br>
> ><br>
> > I'd like to point out that the N-virate idea doesn't handle a key issue:<br>
> > once you have a N-virate, how do you evolve its composition according to<br>
> > the implication and motivation of its members - but also to remarks or<br>
> > frustation by non-virate contributors (especially new contributors who<br>
> > will feel there's a perpetual category they're locked out of)?  Do you<br>
> > just wait for people to gently step down when required?<br>
> <br>
> One way would be to re-elect them every 5 or so years.  Essentially,<br>
> an N-virate is a dictator-like entity for a few years.<br>
> <br>
> Yury<br>
<br>
We've had good luck in the OpenStack community tying leadership to<br>
release cycles. It causes elections more often (our cycles are 6<br>
months long), but people tend to step up for several cycles in a<br>
row so that hasn't been a cause of excessive turnover. Having<br>
frequent opportunities for folks to step down gracefully when they<br>
need or want to also means no one feels like they are signing up<br>
for an indefinite time commitment.<br>
<br>
For a multi-person group, staggered elections where only a portion<br>
of the group is up for election at one time, also provides some<br>
consistency when there is turnover.<br>
<br>
Doug<br>
_______________________________________________<br>
python-committers mailing list<br>
<a href="mailto:python-committers@python.org" target="_blank" rel="noreferrer">python-committers@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-committers" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-committers</a><br>
Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer noreferrer" target="_blank">https://www.python.org/psf/codeofconduct/</a><br>
</blockquote></div>