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 <anthonybax...@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 <d...@doughellmann.com > <mailto:d...@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 <anto...@python.org > > <mailto:anto...@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@python.org <mailto:python-committers@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/>
_______________________________________________ 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/
