On Fri, Jul 20, 2018, 07:51 Nick Coghlan, <ncogh...@gmail.com> wrote:
> 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). > 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 | 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/ >
_______________________________________________ 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/
