On 18 July 2018 at 16:42, Chris Jerdonek <chris.jerdo...@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 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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
