Re: [python-committers] Transfer of power
On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters wrote: > [Chris Jerdonek] >> >> I don’t think we should assume that a stalemate would be okay in all >> cases. There may be cases in which a decision has to be made (e.g. if >> nothing changes, bad things will happen). I think one of the most important >> roles a BDFL serves is to provide a mechanism of last resort to resolve such >> stalemates should they ever arise. If the replacement we come up with can >> itself stalemate, I think there will be a problem. > > Can you flesh that out with a plausible example? If "bad things can happen" > relates to finances or legal issues, the problem is almost certainly the > PSF's headache to resolve. If they don't relate to finances or legal > issues, I'm unclear on what "bad" could mean. Guido's BDFL pronouncements > were mostly about language and library design issues. I only had in mind technical things. Non-technical things didn't cross my mind. The types of cases I had in mind were (in the abstract) (1) a feature is rolled out which later turns out to have a severe defect, and so it needs to be fixed somehow, and people are divided on how it should be fixed; (2) something changes outside of Python (e.g. something OS related), which is or will cause a severe defect for Python users, and people can't agree on how it should be fixed; and (3) (a case you mentioned) there is a feature that everyone wants to add, but people are split on some bike shed issue. It's true that a stalemate for (3) wouldn't be so bad, but it would prevent something that everybody wants. For (1) and (2), I'm probably not the best person to provide an example. But one case in the back of my mind that may have prompted my reply and that might qualify was when there was a randomness-related security issue in the summer of 2016. I believe this is the thread that kicked it off (subject line: "BDFL ruling request: should we block forever waiting for high-quality random bits?"): https://mail.python.org/pipermail/python-dev/2016-June/144939.html Things got so contentious on python-dev that, IIRC, at least one core developer quit or was threatening to quit, and it prompted the creation of a new mailing list (Security-SIG) due to the volume of emails. See the number of emails the thread above spurred alone: https://mail.python.org/pipermail/python-dev/2016-June/thread.html To resolve the split, Guido ultimately chose PEP 524 over PEP 522. > If you want to make a rule that the Elders cannot tie, the only way to do > that is to say they'll all be impeached and replaced if they ever tie (as > already noted by Łukasz, having an odd number of Elders doesn't prevent one > from abstaining). There's another alternative. You can make a rule that they're not allowed to abstain (or some variant, like you have to choose someone else if you need to recuse yourself). I'm a member of such a body in fact (the San Francisco Elections Commission). If a member wants to abstain, a member has to request it, and then the Commission has to pass a majority vote to let the person to abstain. But we wouldn't even have to have that extra provision. --Chris > And we'll keep replacing them until they stop tying. But > we'll probably run out of volunteers after the first round of impeachments. > > Sneakier: add a rule that if the Elders tie, then the choice has to be made > by the President of the PSF. Which, by sheer coincidence, is Guido :-) > ___ 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
Le 16/07/2018 à 04:38, Tim Peters a écrit : > > But I'm not sure it's fully appreciated just how active Guido has been > in those at times. The "accepted/rejected" at the end of major PEPs is > just a small part of that. Along the way, e.g., it's been pretty common > to see a "Save your breath. That's not going to happen." from Guido to > end a distracting alternative (sub)proposal persistently promoted by one > (or a few) very active and/or loquacious posters. I think that only happens on python-ideas. We've long had a problem with that mailing-list (but at least it allows to avoid such discussions on python-dev). Regards Antoine. ___ 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] > > But I'm not sure it's fully appreciated just how active Guido has been > > in those at times. The "accepted/rejected" at the end of major PEPs is > > just a small part of that. Along the way, e.g., it's been pretty common > > to see a "Save your breath. That's not going to happen." from Guido to > > end a distracting alternative (sub)proposal persistently promoted by one > > (or a few) very active and/or loquacious posters. > [Antoine] > I think that only happens on python-ideas. We've long had a problem > with that mailing-list (but at least it allows to avoid such discussions > on python-dev). > I'm unclear on whether you view that as opposing or confirming my point ;-) I view it as confirming: yes, the BDFL has played this role mostly on python-ideas, where the dirty work of developing general PEPs is intended to take place, while they're still at best half-baked. If someone only follows python-dev, they're unaware of most of these BDFL pronouncements. The latter may think "oh, big deal - a PEP is posted to python-dev, and then Guido has weeks to make up his mind about whether to accept or reject it". They're only seeing the end of a sometimes very messy process. Most things on python-ideas never make it to python-dev at all. PEP 572 was (IMO, and Guido's, and a whole bunch of others) posted to python-dev prematurely, so anyone who doesn't follow python-ideas should know that the firestorm on python-dev was just a hint of what python-ideas can be like routinely ;-) ___ 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
Le 16/07/2018 à 20:05, Tim Peters a écrit : > [Tim] > > > But I'm not sure it's fully appreciated just how active Guido has been > > in those at times. The "accepted/rejected" at the end of major > PEPs is > > just a small part of that. Along the way, e.g., it's been pretty > common > > to see a "Save your breath. That's not going to happen." from > Guido to > > end a distracting alternative (sub)proposal persistently promoted > by one > > (or a few) very active and/or loquacious posters. > > [Antoine] > > I think that only happens on python-ideas. We've long had a problem > with that mailing-list (but at least it allows to avoid such discussions > on python-dev). > > I'm unclear on whether you view that as opposing or confirming my point > ;-) I view it as confirming: yes, the BDFL has played this role mostly > on python-ideas, where the dirty work of developing general PEPs is > intended to take place, while they're still at best half-baked. If > someone only follows python-dev, they're unaware of most of these BDFL > pronouncements. > > The latter may think "oh, big deal - a PEP is posted to python-dev, and > then Guido has weeks to make up his mind about whether to accept or > reject it". They're only seeing the end of a sometimes very messy > process. Most things on python-ideas never make it to python-dev at all. > > PEP 572 was (IMO, and Guido's, and a whole bunch of others) posted to > python-dev prematurely, so anyone who doesn't follow python-ideas should > know that the firestorm on python-dev was just a hint of what > python-ideas can be like routinely ;-) I know what python-ideas can be like routinely (I do read it at times). I think the general idea of my comment is that the signal-to-noise ratio on python-ideas is so low that, whether or not Guido had remained BDFL, we would still have a productivity problem to solve there. Regards Antoine. ___ 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 Mon, 16 Jul 2018 at 00:17 Chris Jerdonek wrote: > On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters wrote: > > [Chris Jerdonek] > >> > >> I don’t think we should assume that a stalemate would be okay in all > >> cases. There may be cases in which a decision has to be made (e.g. if > >> nothing changes, bad things will happen). I think one of the most > important > >> roles a BDFL serves is to provide a mechanism of last resort to resolve > such > >> stalemates should they ever arise. If the replacement we come up with > can > >> itself stalemate, I think there will be a problem. > > > > Can you flesh that out with a plausible example? If "bad things can > happen" > > relates to finances or legal issues, the problem is almost certainly the > > PSF's headache to resolve. If they don't relate to finances or legal > > issues, I'm unclear on what "bad" could mean. Guido's BDFL > pronouncements > > were mostly about language and library design issues. > > I only had in mind technical things. Non-technical things didn't cross > my mind. The types of cases I had in mind were (in the abstract) (1) a > feature is rolled out which later turns out to have a severe defect, > and so it needs to be fixed somehow, and people are divided on how it > should be fixed; (2) something changes outside of Python (e.g. > something OS related), which is or will cause a severe defect for > Python users, and people can't agree on how it should be fixed; and > (3) (a case you mentioned) there is a feature that everyone wants to > add, but people are split on some bike shed issue. It's true that a > stalemate for (3) wouldn't be so bad, but it would prevent something > that everybody wants. > > For (1) and (2), I'm probably not the best person to provide an > example. But one case in the back of my mind that may have prompted my > reply and that might qualify was when there was a randomness-related > security issue in the summer of 2016. I believe this is the thread > that kicked it off (subject line: "BDFL ruling request: should we > block forever waiting for high-quality random bits?"): > https://mail.python.org/pipermail/python-dev/2016-June/144939.html > > Things got so contentious on python-dev that, IIRC, at least one core > developer quit or was threatening to quit, and it prompted the > creation of a new mailing list (Security-SIG) due to the volume of > emails. See the number of emails the thread above spurred alone: > https://mail.python.org/pipermail/python-dev/2016-June/thread.html > > To resolve the split, Guido ultimately chose PEP 524 over PEP 522. > But that's an extremely rare case. And even then, I would assume the council would have picked a BDFL delegate who would have made the utlimate decision. So even in a stalemate there's a way out by the council saying "not it" and pointing at someone else. -Brett > > > If you want to make a rule that the Elders cannot tie, the only way to do > > that is to say they'll all be impeached and replaced if they ever tie (as > > already noted by Łukasz, having an odd number of Elders doesn't prevent > one > > from abstaining). > > There's another alternative. You can make a rule that they're not > allowed to abstain (or some variant, like you have to choose someone > else if you need to recuse yourself). I'm a member of such a body in > fact (the San Francisco Elections Commission). If a member wants to > abstain, a member has to request it, and then the Commission has to > pass a majority vote to let the person to abstain. But we wouldn't > even have to have that extra provision. > > --Chris > > > > And we'll keep replacing them until they stop tying. But > > we'll probably run out of volunteers after the first round of > impeachments. > > > > Sneakier: add a rule that if the Elders tie, then the choice has to be > made > > by the President of the PSF. Which, by sheer coincidence, is Guido :-) > > > ___ 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 Sun, 15 Jul 2018 at 19:38 Tim Peters wrote: > [Tim] > >> 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. >>> >> > [Brett Cannon] > >> That's a good point. Since this is typically going to be a yes/no >> question instead of an A/B question, ties that go in favour of the status >> quo aren't a stalemate issue. >> > > Thanks for reading my mind :-) I certainly didn't spell it out. > Just glad I still have the knack for it on occasion. :) > > Predictably contentious A/B issues, like how to allocate limited resources > (how much do we spend on grants vs sponsoring conferences?), are mostly in > the PSF's court. Likewise A/B decisions with legal consequences (now that > the DPRK has ruled the PSF license counterrevolutionary, which license > should we use there instead?). > > Guido's most visible (well, to us committers) BDFL role has been in > "yes/no", "go/nogo" language/library design questions, which don't even > overlap with the PSF's proper concerns. > > But I'm not sure it's fully appreciated just how active Guido has been in > those at times. The "accepted/rejected" at the end of major PEPs is just a > small part of that. Along the way, e.g., it's been pretty common to see a > "Save your breath. That's not going to happen." from Guido to end a > distracting alternative (sub)proposal persistently promoted by one (or a > few) very active and/or loquacious posters. > IOW the design guidance he provided as the discussion progressed and his thoughts evolved/formed on the topic. > > Those "small" pronouncements typically go by with little notice except by > those shut down, but may well be crucial in keeping productive discussion > going at all. And they need to be timely to do any good. Whoever makes > such decisions needs to be down in the mud, wrestling with the issues while > they're hot topics, not judging at leisure weeks (or even days) later. > > I'm not sure "a committee" can do that at all. Then again, there seems to > be consensus that the current PEP discussion process is sometimes broken > anyway, even with a BDFL. > There are definitely perks to having a BDFL such as timely shutdown of side threads, consistency/guidance in design, etc. ___ 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
[Chris Jerdonek] > ... But one case in the back of my mind that may have prompted my reply and that might qualify was when there was a randomness-related >> security issue in the summer of 2016. I believe this is the thread >> that kicked it off (subject line: "BDFL ruling request: should we >> block forever waiting for high-quality random bits?"): >> https://mail.python.org/pipermail/python-dev/2016-June/144939.html >> >> Things got so contentious on python-dev that, IIRC, at least one core >> developer quit or was threatening to quit, and it prompted the >> creation of a new mailing list (Security-SIG) due to the volume of >> emails. See the number of emails the thread above spurred alone: >> https://mail.python.org/pipermail/python-dev/2016-June/thread.html >> >> To resolve the split, Guido ultimately chose PEP 524 over PEP 522. > > [Brett Cannon] > But that's an extremely rare case. And even then, I would assume the > council would have picked a BDFL delegate who would have made the utlimate > decision. So even in a stalemate there's a way out by the council saying > "not it" and pointing at someone else. In the original message of that thread, the release manager had already made a decision, but was getting so much opposition to his position that he appealed to Guido. But the RM already had authority to make the decision. Highly contentious decisions will always be appealed to the full height of whatever bureaucracy exists ;-) It turned out Guido agreed with the RM in this case. The PEPs came later, and were much less contentious than the original under-time-pressure decision. Regardless, I agree with Chris that it would be good to spell out what to do if the Ultimate Authority can't, or won't, reach a decision on their own. Indeed, that's the exact position Guido just left us in ;-) ___ 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
[Antoine] > I know what python-ideas can be like routinely (I do read it at times). > > I think the general idea of my comment is that the signal-to-noise ratio > on python-ideas is so low that, whether or not Guido had remained BDFL, > we would still have a productivity problem to solve there. > I'm much more focused here on the underappreciated roles Guido played in the process than the medium in which the process occurred. Regardless of whether it occurs on a high or low S/N mailing list, a wiki, a Github issue, ... a PEP proceeds from freewheeling brainstorming to python-dev-worthy perfection ;-) incrementally, and along the way "yes, this idea is definitely in - stop arguing about it' and "no, that idea is dead - stop repeating it" pronouncements need to be made. When that doesn't happen by universal consensus, it needs to be forced by _some_ mechanism. If the people involved vote on what they do and don't like, then we have design by committee. I'd much rather have a BDFL-workalike. But in that case, they need to be involved and responsive, not just sit back waiting for "a crisis" to rise to their rarefied level. The latter is indeed important for a BDFL-workalike too, but the point here has been that Guido did much more than _just_ put out raging fires, via the multitude of largely unheralded little pronouncements he routinely made to help PEPs-in-progress continue making progress. And to kill PEPs before they were written when he knew he'd never accept the core idea. ___ 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 16-Jul-2018, at 04:38 , Tim Peters wrote: > > Guido's most visible (well, to us committers) BDFL role has been in "yes/no", > "go/nogo" language/library design questions, which don't even overlap with > the PSF's proper concerns. > > But I'm not sure it's fully appreciated just how active Guido has been in > those at times. The "accepted/rejected" at the end of major PEPs is just a > small part of that. Along the way, e.g., it's been pretty common to see a > "Save your breath. That's not going to happen." from Guido to end a > distracting alternative (sub)proposal persistently promoted by one (or a few) > very active and/or loquacious posters. This is a very good point. And it is a role that is not “formally encoded” anywhere, and one that I think cannot be formally encoded. And actually I wonder whether this role could be fulfilled by any person/committee/procedure other than Guido himself. Which means that in future we should prepare for doing without this role. Which will lead to more contentious issues being put in front of the whatever-body-replaces-the-bdfl, because the early weeding out isn’t going to happen. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ 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 Mon, 16 Jul 2018 at 15:21 Jack Jansen wrote: > > > On 16-Jul-2018, at 04:38 , Tim Peters wrote: > > Guido's most visible (well, to us committers) BDFL role has been in > "yes/no", "go/nogo" language/library design questions, which don't even > overlap with the PSF's proper concerns. > > But I'm not sure it's fully appreciated just how active Guido has been in > those at times. The "accepted/rejected" at the end of major PEPs is just a > small part of that. Along the way, e.g., it's been pretty common to see a > "Save your breath. That's not going to happen." from Guido to end a > distracting alternative (sub)proposal persistently promoted by one (or a > few) very active and/or loquacious posters. > > > This is a very good point. And it is a role that is not “formally encoded” > anywhere, and one that I think cannot be formally encoded. > > And actually I wonder whether this role could be fulfilled by any > person/committee/procedure other than Guido himself. Which means that in > future we should prepare for doing without this role. Which will lead to > more contentious issues being put in front of the > whatever-body-replaces-the-bdfl, because the early weeding out isn’t going > to happen. > I'm not sure if I agree with that in this case. In terms of this specific case of quickly shutting down dead-end discussions, that comes down to time and dedication and maybe a decently broad knowledge base to grasp a concept quickly enough or ability to learn on their feet. But those are not magical traits of Guido's. To me the question is whether we can replace Guido's design sensibilities. ___ 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] > Guido's most visible (well, to us committers) BDFL role has been in > "yes/no", "go/nogo" language/library design questions, which don't even > overlap with the PSF's proper concerns. > > But I'm not sure it's fully appreciated just how active Guido has been in > those at times. The "accepted/rejected" at the end of major PEPs is just a > small part of that. Along the way, e.g., it's been pretty common to see a > "Save your breath. That's not going to happen." from Guido to end a > distracting alternative (sub)proposal persistently promoted by one (or a > few) very active and/or loquacious posters. > > [Jack Jansen] > This is a very good point. And it is a role that is not “formally encoded” > anywhere, and one that I think cannot be formally encoded. > > And actually I wonder whether this role could be fulfilled by any > person/committee/procedure other than Guido himself. Which means that in > future we should prepare for doing without this role. Which will lead to > more contentious issues being put in front of the > whatever-body-replaces-the-bdfl, because the early weeding out isn’t going > to happen. > > > I'm not quite as hopeless ;-) Most notions on python-ideas are dropped voluntarily, after it's clear that they generate little interest - or massive hostility ;-) For one that proceeds to a preliminary PEP, I think it would be wise for the Elders (whatever it's called) to appoint a BDFL-workalike for that specific PEP. Which may or may not be an Elder. That person would need to commit to staying current with the PEP's progress, and would have final "yes/no", "this/that", ... authority on all the design decisions on the way to polishing the PEP. But not the final accept/reject decision (if the PEP survives that long). That would do more than "just" provide a BDFL-workalike for the PEP, it would also provide a kind of mentor for PEP writers sometimes pretty clueless about what the community expects from a PEP. It wouldn't provide a consistent design vision _across_ PEPs, but would at least leave each PEP coherent on its own in _some_ experienced developer's mind. Leaving the final accept/reject to someone else is, in part, a nod to that even a self-coherent PEP may be best rejected for clashing with a broader vision. With a bit of luck, PEP authors and their BDFL-workalikes will come to despise each other so swiftly that no PEP will ever finish again ;-) ___ 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 Mon, Jul 16, 2018, 17:02 Tim Peters, wrote: > [Tim] > >> Guido's most visible (well, to us committers) BDFL role has been in >> "yes/no", "go/nogo" language/library design questions, which don't even >> overlap with the PSF's proper concerns. >> >> But I'm not sure it's fully appreciated just how active Guido has been in >> those at times. The "accepted/rejected" at the end of major PEPs is just a >> small part of that. Along the way, e.g., it's been pretty common to see a >> "Save your breath. That's not going to happen." from Guido to end a >> distracting alternative (sub)proposal persistently promoted by one (or a >> few) very active and/or loquacious posters. >> >> [Jack Jansen] > > >> This is a very good point. And it is a role that is not “formally >> encoded” anywhere, and one that I think cannot be formally encoded. >> >> And actually I wonder whether this role could be fulfilled by any >> person/committee/procedure other than Guido himself. Which means that in >> future we should prepare for doing without this role. Which will lead to >> more contentious issues being put in front of the >> whatever-body-replaces-the-bdfl, because the early weeding out isn’t going >> to happen. >> >> >> I'm not quite as hopeless ;-) Most notions on python-ideas are dropped > voluntarily, after it's clear that they generate little interest - or > massive hostility ;-) > > For one that proceeds to a preliminary PEP, I think it would be wise for > the Elders (whatever it's called) to appoint a BDFL-workalike for that > specific PEP. Which may or may not be an Elder. That person would need to > commit to staying current with the PEP's progress, and would have final > "yes/no", "this/that", ... authority on all the design decisions on the > way to polishing the PEP. But not the final accept/reject decision (if the > PEP survives that long). > > That would do more than "just" provide a BDFL-workalike for the PEP, it > would also provide a kind of mentor for PEP writers sometimes pretty > clueless about what the community expects from a PEP. > > It wouldn't provide a consistent design vision _across_ PEPs, but would at > least leave each PEP coherent on its own in _some_ experienced developer's > mind. Leaving the final accept/reject to someone else is, in part, a nod > to that even a self-coherent PEP may be best rejected for clashing with a > broader vision. > This ties into the core dev sponsor idea that got floated where all inexperienced PEP authors need someone to sign up to shepherd them through the process. That way everything is more structured and, with this idea, also more uniform. -Brett > With a bit of luck, PEP authors and their BDFL-workalikes will come to > despise each other so swiftly that no PEP will ever finish again ;-) > > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
