On Jul 13, 2018, at 02:30, 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. > > I'm not sure what the proper governance structures should be, but they > absolutely shouldn't be dumping extra load onto the release manager.
My thinking is that the current RM can serve a useful role on the Council, but not in a voting capacity. Some possible scenarios: * A Council member wants to author a PEP. They probably shouldn’t also get to vote on the PEP’s acceptance, so the RM can serve as a replacement vote for that one PEP. (Maybe only for Standard Track PEPs). * If a Council member is temporarily unavailable, the RM can serve in their place during that period. * The RM can give valuable insight that may influence Council members votes. Maybe the PEP’s implementation is too difficult for the current release, and recommends deferral. * If the Council also decides on the “PEP-worthiness” of an idea, the RM can weigh in based on their unique perspective on the release cycle. * The RM can provide an independent oversight role on the Council, kind of like an ombudsman (or maybe that should be a separate role, although I suspect it will be rarely invoked in practice). I would propose that the RM be involved with Council communications, but does not get a vote. Cheers, -Barry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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/
