[python-committers] Transfer of power
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?
More information about the python-committers