On 21 July 2018 at 07:14, Brett Cannon brett@python.org wrote:
On Thu, 19 Jul 2018 at 16:47 Victor Stinner vstinner@redhat.com 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: building and maintaining a successful open source community is a lot like tending a garden, where the key activities are things like keeping weeds away and helping to provide water and appropriate amounts of sunlight, rather than trying to tell the individual plants how to grow leaves and flowers :)
[1] http://community.redhat.com/blog/2017/05/let-the-river-flow/ [2] https://community.redhat.com/blog/2017/05/seeds-of-community/
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia