[python-committers] An alternative governance model
ncoghlan at gmail.com
Fri Jul 20 10:51:22 EDT 2018
On 18 July 2018 at 16:42, Chris Jerdonek <chris.jerdonek at gmail.com> wrote:
> I agree a name other than BDFL should be chosen, especially since (as
> I understand it) Guido is still BDFL but just taking a permanent
> vacation, and the name implies there should only be one.
> Also, if we're considering particular people, I think Nick should also
> be considered.
As much as I appreciate the vote of confidence, I'm actively working
to reduce my open source commitments and responsibilities at the
moment, not increase them. Burnout's a thing, y'all, especially when
you have the attention span of a caffeinated squirrel and get involved
in far more things than you could ever hope to see through to
completion in a reasonable period of time :)
And that's my primary concern with any proposals to put a comparable
level of stress to that which Guido has been handling for years on to
another volunteer's shoulders: I don't think it's an even remotely
reasonable thing to request of a community volunteer.
Guido was willing to do it for so long because Python was his
creation, and he grew into the increasing demands of the BDFL role as
time went by, but even he eventually reached the point of saying "I
don't want to do this any more - the personal costs are outweighing
the personal benefits". There's no way that a new individual in a
comparable role to Guido's is going to have an easier time of it than
Guido did, and a lot of good reasons to believe that they will find it
significantly harder (not least of which is that Guido has been able
to request 50% funded "BDFL-time" from his employers since he joined
Google in 2005, and it's unlikely that a newcomer to the role would
enjoy that benefit any time soon).
In the 2 terms I spent on the PSF board, one of the things I aimed to
help Ewa work towards was making being on the Board less of a recipe
for burnout, and I've done what I could to help make working on the
Python packaging ecosystem less of a burnout factory as well. Before
my time on the Board, other folks had already started the process of
having paid PSF staff take on more PyCon US management
responsibilities to help reduce the burden on folks volunteering for
PyCon US leadership roles.
In that context, setting up a high profile volunteer leadership role
that I'd expect to mainly let us burn out multiple people in
succession really doesn't seem like a good response to a leading
contributor deciding that it's time for them to step down :)
So while I'm in favour of the minimal PEP 1 tweaks needed to keep the
volunteer-per-PEP BDFL-Delegate model going for the less controversial
proposals that don't touch core parts of the language, I *don't* think
filing Guido's name off and writing Brett's (or anyone else's) name in
is the right answer for the deeper community governance questions
we're asking ourselves, and I think we'd be squandering a rare
opportunity to explore the alternatives if we instead sought to
preserve the status quo too directly.
Yes, change is scary, and there's always a risk we'll find that we
don't like the initial iteration of whatever we come up with, but
that's just motivation to ensure that whatever system we come up with
has mechanisms for change built into it (just as even the PSF's
by-laws can be amended by a vote of the members).
Personally, I think the contributor council approach is likely to
prove to be a good way to go (since it distributes the burden of
responsibility amongst mutiple volunteers and doesn't leave anyone
feeling obliged to be "on" all the time), and it would then be up to
the initial members of that council to come up with a way to
appropriately rotate any spokesperson responsibilities that came up.
I also think folks are placing too much weight on the notion of Guido
as the primary spokesperson representing what the core contributors
are thinking - if anyone were to be seen as occupying that role, I'd
actually point to whoever takes the lead editor role for the What's
New document in any given release, since most Pythonistas don't even
think about the core development process until they're looking at a
new release and asking themselves "Why on Earth did they add *that*?".
(It could actually be an interesting trial addition to the PEP process
to require that PEP authors include a draft What's New entry, as it
forces you to step back from the intricacies of language and
interpreter runtime design, and focus on the end user impact of a
P.S. Since "What *do* you think is the upper limit on what's a
reasonable request to make of a community volunteer?" is a natural
follow-up question, I'm currently fairly comfortable with the scope of
things like PSF Board membership, PSF Working Group membership,
CPython release management, CPython module maintainership, and the
packaging BDFL-Delegate responsibilities I recently handed over to
Paul Moore (and I think that last one is borderline, and could stand
to follow in CPython's footsteps if we can settle on a reasonable
non-BDFL-dependent design management model).
P.P.S. Full disclosure for folks that weren't there: I proposed at the
2018 Python Language Summit that we institute a PEP 3003 style
language moratarium for Python 3.8, to give the ripple effects arising
from some of the recent language changes like type hinting, native
coroutines, and f-strings a chance to settle down before we embarked
on more language level changes like assignment expressions and
None-aware operators - I think imposing such a moratorium would cost
us very little in the long run, and give the wider community a chance
to catch up on all of the benefits that 3.6 and 3.7 can offer them.
While Guido really wasn't a fan of the idea, the fact that I believe
we should be thinking about how to reduce the demand for language
level churn rather than worrying too much about how to enable more of
it does mean that I'm entirely comfortable with the idea of postponing
any further syntax changes beyond PEP 572 to Python 3.9 or later.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the python-committers