On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou <antoine@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?
That's what we had with Guido so I don't see why this needs to suddenly change. The BDFL role needs to not fear the "tyranny of the majority" (Alexis de Tocqueville). Otherwise we are sacrificing consistent/uniform design for design-by-committee/community.
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.
But that doesn't help deal with inconsistency since that just means we have consistency for 2 releases and then we start all over again. If you're suggesting someone forcibly rotates out every 5 years then that's different since that adds in some consistency thanks to the remaining two members.
Remember the time scale we are talking about here. Python is 28 years old, so a 5 year scale means we would have swapped leaders 6 times at this point. Python 3.0 came out in 2008, so we're approaching 10 years, so a 5 year time scale we would not have had any consistency in just Python 3's lifetime.