On Thu, 12 Jul 2018 at 10:13 Mariatta Wijaya <mariatta.wij...@gmail.com> wrote:
> Guido, > > Thank you for all you've done for Python. It is well deserved break. > > I'm sad, but I like to see this as an opportunity to further improve > Python and this community. > > My first instinct is to suggest: instead of one successor, we will have > several people as the new "leaders", perhaps a co-BDFL, or even 3-5 people > as co-BDFLs/leaders. > This is based on my experience with organizing meetup and conference > (although these are not comparable to leading the community like Python). > The benefit is to lessen the burden and responsibilities of one person, > and they will have backups when they need to go on a break, vacation, take > care of personal life. > > Another thing that came to my mind is, who is actually able (have the time > and energy) to take on this role? Most of us in open source are > volunteering on limited free time available. I'm aware some of you have > employer support, but most don't. Will this limit the candidacy to certain > people just because they have the employer support? > I think it will limit it to people who feel they are up for it. I'm not sure what Guido's time commitment was in the end pre-PEP 572, but outside of major PEP discussions I don't think the time commitment should be huge (and if you delegate a PEP then even less :) . So I don't think it necessitates work time, but you might want to check with your family if they are happy with your current engagement level. ;) > > What is the role of the successor(s)? Do we assume "whatever Guido did", > or is this an opportunity to come up with a new process? > That's why Guido is leaving it up to us. :) For me the key function Guido provided was tone and consistency in design. So whatever we replace Guido with should be something that will represent us in a way we are all proud to stand behind. And then from there the design consistency suggests a first line of yea/nay on PEPs and then delegation. I don't think we can just have a "delegation committee" which doesn't make initial rejections since that would then leave the over-arching design of the language unguided unless the "delegation chooser" consistently chose the same person, informally choosing a design dictator anyway. ;) > One useful resource is Vicky Brasseur's talk: Passing the Baton, > Succession planning for your project > https://www.youtube.com/watch?v=Jhkm2PA_Gf8 > The slides: > https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf > > Some ideas from that talk: > 1. identify critical roles (e.g. PEP decision making) > 2. refactor large roles > 3. mentor the new successor, shadow the previous leader > 4. document all the things > > This might be selfish request, but I hope you can still assume power until > we have new successor(s). > > Thanks. > > Mariatta > > > On Thu, Jul 12, 2018 at 7:58 AM Guido van Rossum <gu...@python.org> wrote: > >> Now that PEP 572 is done, I don't ever want to have to fight so hard for >> a PEP and find that so many people despise my decisions. >> >> I would like to remove myself entirely from the decision process. I'll >> still be there for a while as an ordinary core dev, and I'll still be >> available to mentor people -- possibly more available. But I'm basically >> giving myself a permanent vacation from being BDFL, and you all will be on >> your own. >> >> After all that's eventually going to happen regardless -- there's still >> that bus lurking around the corner, and I'm not getting younger... (I'll >> spare you the list of medical issues.) >> >> I am not going to appoint a successor. >> >> So what are you all going to do? Create a democracy? Anarchy? A >> dictatorship? A federation? >> >> I'm not worried about the day to day decisions in the issue tracker or on >> GitHub. Very rarely I get asked for an opinion, and usually it's not >> actually important. So this can just be dealt with as it has always been. >> >> The decisions that most matter are probably >> - How are PEPs decided >> - How are new core devs inducted >> >> We may be able to write up processes for these things as PEPs (maybe >> those PEPs will form a kind of constitution). But here's the catch. I'm >> going to try and let you all (the current committers) figure it out for >> yourselves. >> >> Note that there's still the CoC -- if you don't like that document your >> only option might be to leave this group voluntarily. Perhaps there are >> issues to decide like when should someone be kicked out (this could be >> banning people from python-dev or python-ideas too, since those are also >> covered by the CoC). >> >> Finally. A reminder that the archives of this list are public ( >> https://mail.python.org/pipermail/python-committers/) although >> membership is closed (limited to core devs). >> >> I'll still be here, but I'm trying to let you all figure something out >> for yourselves. I'm tired, and need a very long break. >> >> -- >> --Guido van Rossum (python.org/~guido) >> _______________________________________________ >> 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/ >
_______________________________________________ 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/
