Re: [python-committers] And Now for Something Completely Different
On 21 July 2018 at 04:30, Donald Stufft wrote: > > On Jul 19, 2018, at 7:47 PM, Victor Stinner wrote: > > It seems that the main question for a new governance is how to take a > decision on PEPs (accept or reject them with some variants like > Deferred). I read that core developers are unable to make a decision > themselves (fail to reach a consensus) and that letting core > developers decide would make Python "inconsistent" (as if only a > single BDFL is able to keep Python consistent). I also read that the > BDFL is required to make unpopular decisions to enhance Python. > > > I think the core difference behind all of the proposals, when you get down > to > brass tacks, will be the vision for where the langauge goes. There are > independently good ideas that maybe should not be accepted, because they > compromise the vision for the worse, or ideas that seem poor on the tin but > that > once they get added they mesh well with the overall language. > > The further you scale up the number of people directly deciding the > direction > of the language, the more likely you will find inconsistency. No two people > have > the same design sense, and so if you ask two people you're likely to get at > least two answers. One of the things that puzzles me about the "Who will set the direction of the language if Guido doesn't do it?" concern is that from my perspective, this is something that Guido mostly *didn't* do (and I'm OK with that). Python has never had a clear road map in the 15+ years I've been part of the core development community - it's just had assorted projects that different individuals have driven to varying levels of completion based on the strength of their convictions about the topic, and the time they've had available to devote to driving it (along with a few "definitely not" issues written down in the form of rejected PEPs). The projects that Guido has been directly involved in driving have been more ambitious in scope than most other folks would be prepared to pursue (e.g. Py3k, asyncio, type hinting), but there have been significant changes he accepted that were originated by others (such as f-strings and assignment expressions), as well as significant topics where he largely delegated decision making to others (such as Unicode handling, project dependency management, the import system, and scientific computing). If I were to write an article like https://www.curiousefficiency.org/posts/2011/08/of-python-and-road-maps-or-lack-thereof.html today, the specific topics I'd mention would be different, but the overall tone would be similar. And I think that's inevitable in an environment driven primarily by volunteer and sponsored development: the time to pursue particular activities has to come from somewhere, and that's either going to be the intrinsic motivations of individuals donating their own time, or else the extrinsic motivation of folks pursuing paid problem solving on behalf of an organisation. 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] And Now for Something Completely Different
On 21 July 2018 at 07:14, Brett Cannon wrote: > On Thu, 19 Jul 2018 at 16:47 Victor Stinner wrote: >> What is the image sent to contributors if we create a subgroup inside >> core developpers called "council"? What if we elect a new BDFL *for >> life*? Does it mean that even core developers judgment are no longer >> trusted, only the council decision matters? What about people outside >> in the insider group of cores... regular contributors? Will anyone >> still listen to them? >> >> I'm not saying that a new governance will lead to such issues. I'm >> only opening the question of the image sent to the community. > > > This will also make it harder to become a core developer. In the past we > have been willing to give people commit privileges for showing they know how > to code to our standards, make decisions when it came to PRs, and knew when > they were outside of their depth (e.g. giving someone commit privileges to > work on Python code but not C). We've also given commit privileges away like > candy to people who have attended sprints in the past, so we have not even > held up that level of requirement for all of Python's history. > > Now we're being asked to also trust someone's design acumen as they will be > voting on PEPs. Up until this point I didn't have to worry about whether > every core dev would take the language in a direction I disagreed with > because they simply didn't have the authority to; it rested with Guido. This > proposed change, though, means I now have to judge all core developers not > just on whether I can trust them to code appropriately but whether I think > they would vote on PEPs that I agree with. That would mean I wouldn't have > voted to give Pablo commit privileges because I simply do not know his > contributions well enough to know if he would make decisions in a way I'm > personally in favour of. I'd share Brett's concern about our being careful in changing the responsibilities of what it means to be a core developer - we're already pretty slow and cautious when it comes to promoting people and encouraging them to find their own comfort level with their new privileges and responsibilities, and so we should be wary of making that learning curve even steeper than it already is. By contrast, I think that adding more explicit responsibility levels beyond the initial step of becoming a core developer has the potential to help us avoid some of the pitfalls described decades ago in Jo Freeman's excellent discussion on the "Tyranny of Structurelessness": https://www.jofreeman.com/joreen/tyranny.htm It's already the case that we have differing levels of influence amongst the core development team - they're just currently acquired through years of personal interactions, both positive and negative, and thus I'd expect them to mainly correlate with "available time" (to increase the number of opportunities for positive interactions), "self-restraint" (to reduce the frequency of negative interactions), and "freedom to travel" (to provide more opportunities to meet people in person and increase trust levels that way). While those aspects of community influence and leadership are never going to go away, we have an opportunity now to set up a model that allows folks to ask themselves if they're interested in pursuing a more visible role not only amongst the core development team, but also in representing the core development team to the outside world (whether that's through day-to-day participation in python-dev and python-ideas, through presentations and personal articles, or through being a point of contact for media enquiries). Similar to the way PSF Board elections work, folks offering to serve in this role could be elected via Approval voting amongst the core developers, using the same Helios platform as the Board elections. That way even if we do decide that it still makes sense to have a Chief Shrubbery Tender (with or without obscure English comedy references in their role title), we can also build succession planning into the system by which we appoint them, by ensuring that more folks than just the primary designated spokesperson are gaining community visibility. Cheers, Nick. P.S. The Chief Shrubbery Tender suggestion isn't entirely in jest. In addition to being a Monty Python reference, it also ties in to a community management discussion that was rumbling along in the background (e.g. [1]) when I was still working for Red Hat: the upstream/downstream analogy that Linux distributions have long used to describe the way that open source software flows into their systems and then on to downstream rebuilds has a lot of problems, one of the most notable of which is that open source communities tend to require a lot more tending than oceans, rain clouds and natural springs do. While it doesn't look like the potential replacement analogies were ever fully elaborated in a public venue (at least, not that I can find), [2] touches on the one that seemed most compelling: b
Re: [python-committers] And Now for Something Completely Different
On Tue, 24 Jul 2018 at 07:46 Nick Coghlan wrote: > On 21 July 2018 at 04:30, Donald Stufft wrote: > > > > On Jul 19, 2018, at 7:47 PM, Victor Stinner wrote: > > > > It seems that the main question for a new governance is how to take a > > decision on PEPs (accept or reject them with some variants like > > Deferred). I read that core developers are unable to make a decision > > themselves (fail to reach a consensus) and that letting core > > developers decide would make Python "inconsistent" (as if only a > > single BDFL is able to keep Python consistent). I also read that the > > BDFL is required to make unpopular decisions to enhance Python. > > > > > > I think the core difference behind all of the proposals, when you get > down > > to > > brass tacks, will be the vision for where the langauge goes. There are > > independently good ideas that maybe should not be accepted, because they > > compromise the vision for the worse, or ideas that seem poor on the tin > but > > that > > once they get added they mesh well with the overall language. > > > > The further you scale up the number of people directly deciding the > > direction > > of the language, the more likely you will find inconsistency. No two > people > > have > > the same design sense, and so if you ask two people you're likely to get > at > > least two answers. > > One of the things that puzzles me about the "Who will set the > direction of the language if Guido doesn't do it?" concern is that > from my perspective, this is something that Guido mostly *didn't* do > (and I'm OK with that). Python has never had a clear road map in the > 15+ years I've been part of the core development community - it's just > had assorted projects that different individuals have driven to > varying levels of completion based on the strength of their > convictions about the topic, and the time they've had available to > devote to driving it (along with a few "definitely not" issues written > down in the form of rejected PEPs). > > The projects that Guido has been directly involved in driving have > been more ambitious in scope than most other folks would be prepared > to pursue (e.g. Py3k, asyncio, type hinting), but there have been > significant changes he accepted that were originated by others (such > as f-strings and assignment expressions), as well as significant > topics where he largely delegated decision making to others (such as > Unicode handling, project dependency management, the import system, > and scientific computing). > > If I were to write an article like > > https://www.curiousefficiency.org/posts/2011/08/of-python-and-road-maps-or-lack-thereof.html > today, the specific topics I'd mention would be different, but the > overall tone would be similar. > So I think if you replaced "direction" with "tone" in your opening phrase then that would encompass what a lot of people are worried about. It isn't necessarily about a roadmap (which we obviously have never had written down ;) , but Guido did set a tone for the language overall which he kept in his head and worked towards through thought and instinct. But Guido has done directional things like saying the removal of the GIL would be acceptable if single-threaded performance was kept, even potentially at the cost of a bit of the C API. So while we have never laid out explicit plans for the next 1, 5, or 10 years, I think there has been guidance and an implicit direction of where the language should be headed. -Brett > > And I think that's inevitable in an environment driven primarily by > volunteer and sponsored development: the time to pursue particular > activities has to come from somewhere, and that's either going to be > the intrinsic motivations of individuals donating their own time, or > else the extrinsic motivation of folks pursuing paid problem solving > on behalf of an organisation. > > 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/ > ___ 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] And Now for Something Completely Different
Brett: > This will also make it harder to become a core developer. In the past we > have been willing to give people commit privileges for showing they know how > to code to our standards, make decisions when it came to PRs, and knew when > they were outside of their depth (e.g. giving someone commit privileges to > work on Python code but not C). We've also given commit privileges away like > candy to people who have attended sprints in the past, so we have not even > held up that level of requirement for all of Python's history. I don't think that giving core dev priviledge just if you attend a sprint is a good practice :-) Maybe we did that in the past, but it seems like nowadays the process is more formalized and stricter. Some people wrote that they are "100+" core developers. If everyone vote on each PEP, one additional core dev just has 1 vote on 101 voters. I don't see any pressure here. > Now we're being asked to also trust someone's design acumen as they will be > voting on PEPs. Up until this point I didn't have to worry about whether > every core dev would take the language in a direction I disagreed with > because they simply didn't have the authority to; it rested with Guido. This > proposed change, though, means I now have to judge all core developers not > just on whether I can trust them to code appropriately but whether I think > they would vote on PEPs that I agree with. That would mean I wouldn't have > voted to give Pablo commit privileges because I simply do not know his > contributions well enough to know if he would make decisions in a way I'm > personally in favour of. IMHO it's ok if people make mistakes on voting if we are enough voters. Making mistakes is part of the learning process. If the vote results are public during the vote, if a voter "does a mistake", you are free to lobby to vote against this mistake to guide people to the right choice :-) Again, I expect that the discussion before a vote will already highlight the popular opinions. The vote result shouldn't be a surprise for anyone if the discussion goes well. Honestly, in many cases, I just follow the expert that I trust, when I'm unable to have my own opinion on a PEP. Victor ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
