[python-committers] Transfer of power

Steve Dower steve.dower at python.org
Thu Jul 12 13:12:52 EDT 2018


On 12Jul2018 0958, Antoine Pitrou 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 of the important things we will have to do is define the scope of 
any long-term appointees. For example, saying "we have an N-virate that 
decides on PEPs" is very different from saying "we have an N-virate that 
decides on the PEP approver (formerly BDFL-delegates)". The latter does 
not necessarily lock anyone out from being a critical part of Python's 
future, but it does avoid endless arguments about selecting who is 
responsible with deciding.

I'm honestly not very sympathetic towards "locking out" new contributors 
from literally leading a project. As you say below, few of us can claim 
as long and as uninterrupted a presence in this project as Guido, but 
many of us can certainly claim more "right" to a say than some random 
person who probably ought to build a few of their own languages before 
deeming themselves worthy to significantly influence a well established one.

> One key point about Guido is that not only he's the founder of the
> project, but he's been consistently be there all the time, with almost
> no interruptions.  I don't think any of us can claim such an
> uninterrupted presence, neither in the past, nor in the long future.

This is the main reason for having more than one person be on the 
critical path for significant changes. It is easier to replace 33% of a 
group without losing continuity than to replace 100%.

For me, I would like the release manager to also take on some of the 
responsibility for new features in their releases. Perhaps holding one 
position in an N-virate for the current RM (who continue rotating every 
two releases) is a good way to keep things fresh?

Cheers,
Steve


More information about the python-committers mailing list