Home Original page

[python-committers] Transfer of power

Barry Warsaw barry at python.org
Fri Jul 13 18:37:27 EDT 2018 
On Jul 13, 2018, at 02:30, 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.
> 
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180713/8e70b517/attachment.sig>
More information about the python-committers mailing list