[python-committers] PEP stewardship delegation: the minimal change approach
Hi folks, While I think the threads suggesting that we treat Guido's retirement as an opportunity to conduct a critical self-review of our community governance structures and practices are an excellent idea, I also want to note that there's only a relatively minimal change required to PEP 1 to permit changes to proceed in areas that would likely previously have been handled by a BDFL-Delegate anyway. The gist is that both PEP 1 and the derived process I set up for PyPA allow for folks to *volunteer* as BDFL-Delegates for a PEP, rather than waiting for Guido (or the default BDFL-Delegate in the PyPA case) to pick someone. (The unwritten addendum to both these clauses is that PEP authors may also ask core devs with suitable experience to consider volunteering as BDFL-Delegate) Quoting the relevant paragraph from PEP 1 [1]: = The final authority for PEP approval is the BDFL. However, whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other core developers and the BDFL, then they will have the authority to approve (or reject) that PEP. This process happens most frequently with PEPs where the BDFL has granted in principle approval for something to be done, but there are details that need to be worked out before the PEP can be accepted. = And the relevant section from the PyPA process documentation [2]: = Whenever a new PEP is put forward on distutils-sig, any PyPA core reviewer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL’s delegate (or “PEP czar”) for that PEP. If their self-nomination is accepted by the other PyPA core reviewers, the lead PyPI maintainer and the default BDFL delegate for package distribution metadata PEPs, then they will have the authority to approve (or reject) that PEP. Otherwise, the default BDFL-Delegate depends on the area the PEP affects. - Package Distribution Metadata PEPs: Paul Moore - Package Index Interface PEPs: Donald Stufft For Package Distribution Metadata, the default BDFL-Delegate was originally appointed directly by Guido van Rossum as Python’s BDFL (hence the use of the term BDFL-Delegate), but is now nominated by the previous default BDFL-Delegate (and the transfer of delegation approved by Guido). For Package Index Interfaces, the default responsible decision maker is the lead maintainer for the Python Package Index. = So stealing Brett's excellent suggestion of "Design Steward" as a BDFL-independent term for the current BDFL-Delegate role, a potential PEP 1 amendment for the appointment process would be: = Whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the "Design Steward" for that PEP. If their self-nomination is accepted by the other core developers, then they will have the authority to approve (or reject) that PEP. = This is similar to the "any core developer can approve a commit, any other core developer can subsequently ask for that commit to be reverted" principle that applies for smaller changes, just applied in advance to more complex design reviews and decisions. The PyPA amendment would be similar - replacing "BDFL-Delegate" with "Design Steward", and removing any references to Guido's previously priviliged role in the process. There are some proposals where I wouldn't expect this simple modification to be sufficient (e.g. PEP 505's proposal for new None-aware operators, or PEP 572's assignment expressions), due to a lack of core developers that would consider themselves suitably experienced to be solely responsible for language level design decisions of that magnitude. However, I'd expect it to be sufficient in cases where the main motivation for requiring a PEP is due to a generally supported change's design complexity, rather than due to it being a particularly controversial decision on whether or not to do anything at all. Cheers, Nick. [1] https://www.python.org/dev/peps/pep-0001/#pep-review-resolution [2] https://www.pypa.io/en/latest/specifications/#proposing-new-specifications -- Nick Coghlan | [email protected] | Brisbane, Australia ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Transfer of power
> On Jul 13, 2018, at 7:54 PM, Tim Peters wrote: > > If there are 3 Elders [snip] It looks like the number 3 is popular in this context. What makes it so attractive? I see a bunch of problems with such a low number, like the ability for a single corporation to take over the design process of Python by employing just two of the three members (consistently voting over the third one). 3 also has high likelihood of ties if one of the members abstains. And so on. Taking a step back, before we talk names, term limits and even numbers of council members, Python needs a "constitution" which will codify what the council is and how it functions. Barry calls it PEP 2 but I'd like to understand who is supposed to author it and who is supposed to accept it. Any committer is in a position to suggest parts of or the entirety of such a document. Otherwise we create a fractal problem of who and how decides on who shouId be writing it. Ultimately we are volunteers, the ones who step up and do the work. Ideally Guido would accept the PEP but I'm not sure if he is willing to. If that is indeed the case then how should this be done so that the document is universally accepted by all committers? -- Ł ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] PEP stewardship delegation: the minimal change approach
On 14 July 2018 at 08:05, Nick Coghlan wrote: > So stealing Brett's excellent suggestion of "Design Steward" as a > BDFL-independent term for the current BDFL-Delegate role, a potential > PEP 1 amendment for the appointment process would be: I've only got one peripheral point to make here, but can we keep the term "BDFL" and its derived terms? Even if we no longer have a BDFL (although the "FL" means that Guido is still our BDFL, even if he has stood down from the actual day to day responsibilities), Carol made the important point that Python is about community as much as it is about a programming language, and that community is built around the BDFL. I think it's important for the community that we continue to acknowledge the place of the BDFL in that role, even if it's now a notional position. As a British person, I suppose I think in terms of the royal family. No actual function in terms of government, but important in what many people (both within and outside Britain) consider being "British" to mean (apologies to any republicans out there). Paul ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Transfer of power
On Thu, Jul 12, 2018 at 4:58 PM Guido van Rossum 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 > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ I owe my entire career to you. Your creation has influenced my life and decision making in a very profound way. I cannot tell you how grateful I am for what you did throughout all these years. I am sincerely sad to see you resigning from your role. -- Giampaolo - http://grodola.blogspot.com ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Transfer of power
[Tim] > > If there are 3 Elders [snip] > [Łukasz Langa] > It looks like the number 3 is popular in this context. What makes it so > attractive? > Likely because it was the first specific non-insane number someone mentioned. It helps to be concrete, but I don't know that anyone is wedded to 3. > I see a bunch of problems with such a low number, like the ability for a > single corporation to take over the design process of Python by employing > just two of the three members (consistently voting over the third one). Perhaps then you don't want a "supreme court" at all. We've been living for decades with the possibility that a single corporation could buy off Guido. Would it really help to change 3 to 5? Then Evil Corp only needs to buy off 3 - but the larger the number, the more likely Evil Corp will get some votes in its favor without needing to pay. If semi-dictators are part of the New Order at all, they need to be trusted a whole lot (although I suggested a mechanism for impeachment too). > 3 also has high likelihood of ties if one of the members abstains. I don't care about that. How often did Guido abstain? it's an Elder's _job_ to make potentially unpopular decisions. If one abstained without extraordinarily solid reason, I'd move to impeach them - they're not doing the job in that case. If they tied, that's fine too. Ties favor the status quo (same as if the proposed change had been rejected). For that reason, I'm not even wedded to an odd number. > And so on. > Likewise in the other direction. For example, how many "extremely trusted" people can we even get to volunteer for a contentious, long-term, non-paying job? I don't know. "3" probably started with the first person here who suggested specific names and could only come up with 3 ;-) Taking a step back, before we talk names, term limits and even numbers of > council members, Python needs a "constitution" which will codify what the > council is and how it functions. "Feedback loops" - all decisions feed into each other, in all directions. For example, the number of people on the council has real effects on what it's _possible_ for it do, and on how it functions. It doesn't hurt to think about everything at once ;-) Barry calls it PEP 2 but I'd like to understand who is supposed to author > it and who is supposed to accept it. > Any committer is in a position to suggest parts of or the entirety of such > a document. Otherwise we create a fractal problem of who and how decides on > who shouId be writing it. Ultimately we are volunteers, the ones who step > up and do the work. > Sure! Ideally Guido would accept the PEP but I'm not sure if he is willing to. His initial message here seemed very clear that he wants us to "figure something out for yourselves". He's tired of the battles, and perhaps you have to be as old as him (as I was 4 years ago) to grasp what "bone weary" really means ;-) > If that is indeed the case then how should this be done so that the > document is universally accepted by all committers? > Perhaps it won't be - after all, much of the point to a dictator-workalike is that universal acceptance is a rare thing in real life. Guido left us with an interesting puzzle to solve :-) ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Transfer of power
On Sat, 14 Jul 2018 at 00:16 Łukasz Langa wrote: > > > On Jul 13, 2018, at 7:54 PM, Tim Peters wrote: > > > > If there are 3 Elders [snip] > > > It looks like the number 3 is popular in this context. What makes it so > attractive? > I think because it's small enough to be manageable and have consistency in outcomes (which is what I would want if these folks are the design stewards). IOW it prevents design-by-committee scenarios. > > I see a bunch of problems with such a low number, like the ability for a > single corporation to take over the design process of Python by employing > just two of the three members (consistently voting over the third one). 3 > also has high likelihood of ties if one of the members abstains. And so on. > > I'm personally not worried about the single corporation issue as we've basically had that under Guido since the beginning. :) I would also hope that anyone who ends up in this position is trusted enough to put Python above any potential pressure from their employer. While I prefer 3, I can see 5 working. Basically I think the number should be small enough that you can have a casual conversation with everyone involved and not feel like it's a committee meeting. > > Taking a step back, before we talk names, term limits and even numbers of > council members, Python needs a "constitution" which will codify what the > council is and how it functions. Barry calls it PEP 2 but I'd like to > understand who is supposed to author it and who is supposed to accept it. > Any committer is in a position to suggest parts of or the entirety of such > a document. Otherwise we create a fractal problem of who and how decides on > who shouId be writing it. Ultimately we are volunteers, the ones who step > up and do the work. > Ideally Guido would accept the PEP but I'm not sure if he is willing to. > If that is indeed the case then how should this be done so that the > document is universally accepted by all committers? > In my ideal scenario, people write up PEPs proposing a governance model and Guido chooses one, making it PEP 2. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Identify roles of the BDFL
On Fri, Jul 13, 2018, 17:11 Carol Willing, wrote: > On Jul 13, 2018, at 11:39 AM, Brett Cannon wrote: > > On Fri, 13 Jul 2018 at 03:44 Victor Stinner wrote: > >> Hi, >> >> 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya : >> >> >> * Diversity. Last years, the BDFL was a strong player to enhance the >> diversity of core developers and contributors by mentoring directly >> Mariatta Wijaya, and suggesting regularly to mentor more people from >> minorities whenever possible. He also likes to wear PyLadies t-shirt >> and support DjangoGirls ;-) >> > > I lump this into the community and PR bucket as I don't know if we need to > be worrying about appointing a head of diversity right now as that doesn't > tie into governance. If, once this is all over, we want to take our > diversity efforts to another level then a diversity SIG could be formed, > but I don't see this as a BDFL thing and more of a team thing that someone > choose to spearhead. > > > Brett, > > I'm wondering if prematurely placing this in the community and PR bucket > gives mentoring and inclusion among the core developer enviroment enough > strategic importance. Knowing how gracious you are, I suspect that you > personally are viewing it as such. Yet, I'm not sure that by removing this > as a role that Guido has played is best for the language or the developer > community. > > If I look at the many important roles that Guido has played, I personally > believe that he has been someone who encouraged many women (and I'm sure > others as well) and most importantly provided a safe place to share ideas. > If we reflect on Mariatta's PyCon talk and Summit talk, it's clear that we > should not overlook this role as growth and improvements still need to > happen here. > > I believe that improving the overall communication and professionalism on > mailing lists and PEPs is important to continuously improve the culture and > discourse. While this may help improve inclusion (and is a step in the > right direction), I would encourage everyone to reflect on Mariatta's talks > and consider whether improvement will happen if members of > GUIDO/elders/triumvirate/kittens of entropy and anarchy/pick your > governance/etc. don't believe, embrace, and make this a priority in > stewarding the future of the Python language. > > tldr; We don't need a head of diversity. What we need is leadership that > embraces inclusion and will steward the vision for improvements. > Yes, and I'm assuming no one would end up on any council who doesn't hold these views. My poorly made point is I don't know if we want to lump all of this together such that this council is expected to lead all of these points explicitly. IOW if I were to make a PSF comparison this is like the council being the board and they would be expected to support a diversity SIG/WG. -Brett > Thanks, > Carol > > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] possible future PEP discussion format [was: Transfer of power]
On Fri, Jul 13, 2018, 13:14 Neil Schemenauer, wrote: > On 2018-07-13, Ethan Furman wrote: > > I stopped reading the PEP 572 threads once it was painfully > > obvious that almost all new replies were just saying the same > > things over and over and over... > > Perhaps this can be seen as a kind of economic problem. What is the > cost of posting to a PEP discussion thread vs the cost of everyone > reading that post? Or, what is the value of the comment vs what is > cost for everyone to read it? > > With the current discussion method, the costs are often > disproportionate. You have hundreds of people reading the thread. > So that cost is pretty high. Posting a half-baked comment is too > easy. Starting a new thread with a new subject line is too easy. > While I'm not ready to start talking about a tweaked PEP process, I will say that this disproportionate cost is definitely an issue from my perspective. -Brett > One idea is to have a list dedicated to PEP discussions. We could > establish a set of rules (cultural norms) for discussion on that > list. E.g. > > - do your background research before posting: read PEP in its > entirety, read complete PEP discussion thread > > - make high quality posts: ensure your points are truly bringing new > ideas forth, present them clearly and succinctly > > - lay down rules for subject lines of posts, when you can start a > new thread. Off topic discussion should go back to python-ideas. > > python-ideas can remain a free-wheeling wild west. Make the PEP > discussion list a formal discussion forum. If people don't follow > the rules, warn them and ultimately ban them from the list. > > Thinking about subject line rules, it would be helpful to organize > threads by PEP, by topic and sub-topic. E.g. > > PEP 572: R: informal educator feedback > PEP 572: S: comprehension scope > PEP 572: S: operator precedence of := > > Possible topic abbreviations: > > R: Rationale > S: Syntax and semantics > E: Examples > > Regards, > > Neil > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Identify roles of the BDFL
On Sat, Jul 14, 2018, 15:56 Brett Cannon, wrote: > > > On Fri, Jul 13, 2018, 17:11 Carol Willing, wrote: > >> On Jul 13, 2018, at 11:39 AM, Brett Cannon wrote: >> >> On Fri, 13 Jul 2018 at 03:44 Victor Stinner wrote: >> >>> Hi, >>> >>> 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya : >>> >>> >>> * Diversity. Last years, the BDFL was a strong player to enhance the >>> diversity of core developers and contributors by mentoring directly >>> Mariatta Wijaya, and suggesting regularly to mentor more people from >>> minorities whenever possible. He also likes to wear PyLadies t-shirt >>> and support DjangoGirls ;-) >>> >> >> I lump this into the community and PR bucket as I don't know if we need >> to be worrying about appointing a head of diversity right now as that >> doesn't tie into governance. If, once this is all over, we want to take our >> diversity efforts to another level then a diversity SIG could be formed, >> but I don't see this as a BDFL thing and more of a team thing that someone >> choose to spearhead. >> >> >> Brett, >> >> I'm wondering if prematurely placing this in the community and PR bucket >> gives mentoring and inclusion among the core developer enviroment enough >> strategic importance. Knowing how gracious you are, I suspect that you >> personally are viewing it as such. Yet, I'm not sure that by removing this >> as a role that Guido has played is best for the language or the developer >> community. >> >> If I look at the many important roles that Guido has played, I personally >> believe that he has been someone who encouraged many women (and I'm sure >> others as well) and most importantly provided a safe place to share ideas. >> If we reflect on Mariatta's PyCon talk and Summit talk, it's clear that we >> should not overlook this role as growth and improvements still need to >> happen here. >> >> I believe that improving the overall communication and professionalism on >> mailing lists and PEPs is important to continuously improve the culture and >> discourse. While this may help improve inclusion (and is a step in the >> right direction), I would encourage everyone to reflect on Mariatta's talks >> and consider whether improvement will happen if members of >> GUIDO/elders/triumvirate/kittens of entropy and anarchy/pick your >> governance/etc. don't believe, embrace, and make this a priority in >> stewarding the future of the Python language. >> >> tldr; We don't need a head of diversity. What we need is leadership that >> embraces inclusion and will steward the vision for improvements. >> > > Yes, and I'm assuming no one would end up on any council who doesn't hold > these views. My poorly made point is I don't know if we want to lump all of > this together such that this council is expected to lead all of these > points explicitly. IOW if I were to make a PSF comparison this is like the > council being the board and they would be expected to support a diversity > SIG/WG. > And after sending this I realized the council -> board analogy might suggest more power than the council will probably have. Anyway, my key point is I'm trying to avoid burnout for anyone ending up on this council by making them directly responsible for too much while still expecting them to be good representatives of the team (like I would hope we all strive to be). > -Brett > > >> Thanks, >> Carol >> >> ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] PEP stewardship delegation: the minimal change approach
On 14 July 2018 at 19:36, Paul Moore wrote: > On 14 July 2018 at 08:05, Nick Coghlan wrote: >> So stealing Brett's excellent suggestion of "Design Steward" as a >> BDFL-independent term for the current BDFL-Delegate role, a potential >> PEP 1 amendment for the appointment process would be: > > I've only got one peripheral point to make here, but can we keep the > term "BDFL" and its derived terms? Even if we no longer have a BDFL > (although the "FL" means that Guido is still our BDFL, even if he has > stood down from the actual day to day responsibilities), Carol made > the important point that Python is about community as much as it is > about a programming language, and that community is built around the > BDFL. I think it's important for the community that we continue to > acknowledge the place of the BDFL in that role, even if it's now a > notional position. Yes, the even-more-minimal change would be to leave the terminology alone (which has the additional benefit of avoiding any bikeshedding over a new name for the role), and just note that Guido now has the same role in the process as any other core developer, rather than needing to explicitly assent to any BDFL-Delegate nomination. = Whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the "BDFL-Delegate" for that PEP. If their self-nomination is accepted by the other active core developers, then they will have the authority to approve (or reject) that PEP. (We retain the "BDFL-Delegate" term for this role, even though delegates are no longer directly appointed or accepted by the BDFL - while Guido still participates in the BDFL-Delegate appointment process, he participates in the same capacity as any other core developer) = Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Transfer of power
On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon wrote: [..] >> Ideally Guido would accept the PEP but I'm not sure if he is willing to. If >> that is indeed the case then how should this be done so that the document is >> universally accepted by all committers? > > > In my ideal scenario, people write up PEPs proposing a governance model and > Guido chooses one, making it PEP 2. That would be indeed the ideal scenario, legitimizing the whole thing. Yury ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
