The discussion about PEP 13 and CoC raised a different question in my mind. I thought I’d raise it as a separate thread, since it’s not really about CoC issues. What role-related expertise do we expect SC members to have? What kind of job do they see themselves doing?
I’ve been in large engineering teams in industry for a long time. We tend to have leaders who focus on a particular role, where the most obvious distinction is between a tech lead and a manager. The tech lead focuses on design and coding. The manager focuses on running the organization. (The product and program managers are two other common roles.)
Do the SC members think of themselves as primarily wearing one hat or another? What role do people want the SC members to take? Does it need people representing several different kinds of expertise?
My sense is that I had been thinking of SC members primarly as TLs. I think it’s useful to have some TLs on the SC, but I think management expertise is the most critical skill to have.
It’s an interesting question. I won’t chime in with any opinions other than to say that I pushed for open nominations (that is, anyone at all can be nominated) specifically so that we could diversify the steering council beyond “people who are core devs” and try to bring in expertise that isn’t the same as sending pull requests or managing technical aspects.
Perhaps I misunderstand what you mean by “open nominations”, but just to be clear, you do not have to be a core dev to serve on or be nominated for the SC. The only current requirement in PEP 13 is that someone must be nominated by a core dev, and also that self-nominations by core devs are allowed. Are you advocating that anybody can nominate anybody for the SC and that self-nominations would also be allowed?
Whether we loosen the nomination process or not, I do think we could be more proactive in finding willing and qualified candidates outside the core dev community.
I meant exactly what you just said. The nominee (and hence, the nomination (n)) is open, the nominator (and hence, the nomination (v)) is constrained. Thanks, English.
I do think of the SC in more of a “technical lead” role, although “stewardship” is also a description that comes to mind. Thinking about the long term sustainability of the code base and feature set, thinking about how to evolve the language and implementation responsibly for the long-term, and taking into consideration the “Pythonic-ness” of proposed solutions, etc. are all critically important. Having at least some awareness of the vastness of the surface for Python’s reach and use is important too.
Management expertise can be useful, but I don’t think it’s a central role, at least in my mind as the SC currently operates. The SC as a body doesn’t actively manage contributions from volunteers or paid staff, doesn’t allocate resources to specific tasks, make priority trade-offs between this feature or that feature, determine timelines, or support direct reports. The SC kind of sort of manages the DiRs, but it’s very loose, technically focused, and doesn’t really have HR functions since the DiRs are employed by the PSF. It does have a hand in the hiring process though.
@barry hit the nail on the head IMO. Here’s a little more context as well:
The SC’s role is purposefully open-ended in PEP 13 – each council prioritizes different parts of the process and the impact they may have. In a way, your vote signals these priorities to the elected members!
I can say that the majority of our work over the last 2 years that I served has been pronouncing on PEPs, or providing feedback and decisions on post-PEP decisions that were overlooked. A good way to see the public view of this is to skim through the issues that have been brought to us or our Community Updates.
For this “core work,” PEP decisions have been a mixed bag – some decisions have been obvious, both at the technical merit and direction of a PEP but also the community consensus, and others have been quite contentious and deep-reaching into the underlying technical implementations as well as the impacts of the future of Python. I’d say that in this case, SC members benefit from the technical chops to understand these issues and their implications deeply, but they don’t need to be the people who are actually doing the work. In fact, if an SC member is a collaborator on a PEP, they recuse themselves from voting on it and try to keep discussions at a minimum to avoid swaying the vote outside of the PEP content itself and its public discussions. If you feel that certain PEPs should or should not have been accepted in the past, voting for someone who prioritizes those aspects could inform the process as well.
There is a bit of direct management of both people (the DiRs, though the SC has largely been hands-off in this), as well as finances (which we also haven’t done a ton with outside of approving funds for PyCon US Core Dev grants, the Core Sprint, and small things like funding the mentorship). These really are minor roles in comparison.
I do think that some community members expect more from the SC, and some want them to focus strictly on technical stewardship. I see the SC as a mechanism to take feedback from the community and spur action where needed, but not necessarily as the expected implementors (though they could take on those roles if desired).
@jhylton I’m going to speak to my time on the inaugural steering council and the two terms after that. So qualities that were critical to have:
technical knowledge
understanding governance of a volunteer organization
desire to put the best interests of Python above personal interests
willingness to take on the issues that are important to core development now and in the near term future
excellent listening and communication skills
While 75% of the time was spent on technical topics, another 25% was spent on creating a strategy and efforts to fund a developer in residence (partially to provide continuity in the project and partly to minimize volunteer burnout), improving the community standards (that led to the hostile responses to the walrus operator), and reviewing incidents where standards were clearly not upheld.
The Steering Council should be made up of leaders. Leaders have to make difficult decisions and navigate uncharted waters. Ultimately, productive core development requires people and technical skills.
Participating in the inaugural steering council felt quite similar to “development lead” roles in my various day jobs: you’re not specifically responsible for people management tasks, but you are potentially involved in them.
One of the key relationships that the SC handles is the one with the PSF, which is very much a “supportive management” situation (that is, working together to identify areas where PSF funding and fundraising can be effectively applied to make the contributor experience more enjoyable and the overall project more sustainable, such as the developer in residence program).
The other corporate analogy I would draw is with an Architecture Review Board - taking a broader view of technical decisions that may impact the entire organisation, beyond the individual development team implementing the feature in question.
The fact most of the people involved (at every level) are volunteers makes things more complicated, but the core premise of “responsible for technical direction, consulted on people management” seems to have held in the years since the Steering Council mechanism was adopted.
Edit: something I meant to mention, but missed, is that there is also a complicating factor in managing volunteers that have only ever experienced adversarial management relationships, and are hence inclined to see the PSF as “the big mean authority figures trying to stop the developers from having fun”. That perception isn’t remotely accurate (many SC members have also been PSF Board members), but healthy management relationships are so wildly different from unhealthy ones that they sound like a fantasy to people that have only experienced the latter.
Are you saying that you think “leader” is some kind of natural quality that pre-exists to the fact of having a role as a (technical or management) leader?
There is a lot of trivialisation here. Luckily, I have not experienced “only adversarial management relationships”, but I do think core development should remain autonomous from the PSF.
I also think the hundred or so core Python developers are more likely to understand and represent the interests of Python communities at large, than the 15 PSF board members that have been elected on vague self-promotional discourses.
My goal was to emphasise the diplomatic/liaison aspects of being part of the steering council.
That’s both internally facing and externally facing, and part of it is addressing folks concerns when offers of assistance are perceived as attempts to assert control or exercise undue influence.
It also has aspects of representing whoever isn’t present in a particular discussion (hence my comparison to institutional architecture review boards: when working with specific teams, system architects are filling in for all of the groups which aren’t otherwise represented).
PSF Board members often have substantially more exposure than we do to the use of Python in environments that haven’t given rise to any core developers yet. Yes, being able to identify and describe their activities that are likely to provide useful insights into the potential activities of the wider PSF is a necessary part of being elected as Board members, but we expect the same of potential steering council members (I doubt any of us would vote for a steering council candidate that just posted “because I want to be on the steering council” as their nomination statement, without any description of the perspectives they would be bringing to bear or the outcomes they were hoping to achieve).
That said, when the steering council was starting up, we were primarily working with the PSF staff rather than directly with the board, and my impression is that is still the case.
That is indeed still the case. I would say we work less closely with Deb (the Executive Director now) than we did with Ewa (the Executive Director for the first couple of SC years) for a number of reasons none of which are bad. We don’t really have direct contact with the Board. Pretty much all PSF matters go via the Executive Director, and sometimes directly to PSF staff.
To be very explicit about it, we have clear areas of responsibilities, shared work is clearly defined and nobody from the PSF Board has tried to tell the SC what to do. There are no concerns there.