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