[python-committers] An alternative governance model

[Brett Cannon]

On Fri, Jul 20, 2018, 07:51 Nick Coghlan, <ncoghlan at gmail.com> wrote:

> 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).
>

While I'm purposefully staying out of this thread as my name is currently
so strongly associated with it and I don't want people thinking I'm a
megalomaniac, I will say that I see no reason why I wouldn't get 50% time
at Microsoft if I asked for it (I already get a day/week plus email reading
every day).

I also agreed to Barry's proposal under the expectation that I would still
take a month off every year and one day a week like I do already. That plus
a council of folks to help with the load makes me think I can handle the
workload without having to sacrifice more personal time than I'm already
comfortable doing now. I also think that we as a team and a community are a
bit more aware of the issue of burnout thanks to Guido's retirement.

Plus Andrea said it was okay 😉 (The cat was indifferent.)

-Brett


> 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
> proposed change)
>
> Cheers,
> Nick.
>
> 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
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180720/81be33f4/attachment.html>