[python-committers] And Now for Something Completely Different

[Nick Coghlan]

On 21 July 2018 at 07:14, Brett Cannon <brett at python.org> wrote:
> On Thu, 19 Jul 2018 at 16:47 Victor Stinner <vstinner at 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 at gmail.com   |   Brisbane, Australia