Question for council candidates: Direction Group

Python Help
1

I’m not going to go through and tag everyone - hopefully candidates are watching the board (if not, well, that answers a slightly different question that I’m only asking implicitly :slight_smile: ).

Also posting this in Users so that the external nominees can participate - please avoid answering if you are not a nominee (FWIW, I’ll restate my suggestion that nominees should have been temporarily added to the Committers group so this wouldn’t be an issue and we wouldn’t be asking everyone to watch every post, but I guess since that was in the least popular governance PEP everyone else wants the council to have to watch everything… )

Here is the question.

What are your thoughts on a Direction Group?

To add some context, this document (PDF) is the current report from the C++ Direction Group. It includes a small section on the group’s history and make up, and their charter, which I reproduce below (emphasis mine):

The direction group is a small by-invitation group of experienced participants who are asked to recommend priorities for WG21. Currently, that group consists of: Howard Hinnant, Roger Orr, Bjarne Stroustrup, Daveed Vandevoorde, and Michael Wong. Their charter includes setting forth a group opinion on:

  • Evolution direction (language and library): This includes both language and library topics, and includes both proposals in hand and proposals we do not have but should solicit. The direction group maintains a list of the proposals it considers the most important for the next version of C++ or to otherwise make progress such as in a TS, and the design group chairs use that list to prioritize work at meetings. Typically, work on other topics will occur after there’s nothing further left to do at this meeting to advance the listed items.
  • Providing an opinion on any specific proposal: This includes whether the proposal should be pursued or not, and if pursued any changes that should be considered. Design group participants are strongly encouraged to give weight to an opinion that the direction group feel strongly enough about to suggest.

I am interested in candidates’ positions on having such a group, whether they believe the council can/will sufficiently fill this role, whether Python has a need for a more formalised approach to defining its evolution, how you would advocate/propose such a group be set up and operate, or anything related to this subject.

1 Like
2

Well, PEP 8016 doesn’t explicitly prohibit the Steering Council from taking advice from anyone, be it a single core developer, or some “Direction Group”.

But, the whole point of the governance voting we had was to establish a transparent decision making structure that most core developers understand and accept. Changing that structure by adding another decision making entity looks like an attempt to significantly alter the accepted governance model. So if the council decides to establish a “Direction Group”, they will have to alter PEP 8016. The PEP has a guideline on that:

Changing this document

Changes to this document require at least a two-thirds majority of votes cast in a core team vote.

4 Likes
3

To clarify the context a little, the C++ one does not make decisions and has no additional voting power beyond anyone else involved. So they deem it valuable to have such a group separate from the decision-making entity. I presume your reply means you think that would not be possible given your interpretation of PEP 13?

4

Yes. In my opinion, if a Direction Group exists in any capacity it will directly or indirectly affect how the decisions are made by the council. This means PEP 13 should be updated to make sure that Python core developers and the community fully understand (and respect) the decision making process. This is from the standpoint of how the council can establish a Direction Group.

Another question is why the council might want to have a DG. I think we’re lucky to have a very diverse pool of candidates. Pretty much any composition of the council should be able to govern without the need to further complicate the process or significantly change PEP 13. My 2c.

2 Likes
5

Initially, I think it will be prudent for the Council to be conservative when starting new groups while the Council gets up and running. It often takes council 3-6 months to get up and running effectively (learn successful governance practices, set a meeting/communication schedule, outline Council governance priorities for the year, and to gel as a team).

For the PSF, we typically have had people propose a new workgroup, create a charter for the group, and then have the board vote on whether the group makes sense at the time. Some workgroups will have limited lifespans to achieve a specific goal; while, others will be standing workgroups.

Overall, we should keep in mind that starting slowly, being responsive, and growing transparently as needed are healthy governance practices.

5 Likes
6

@steve.dower I wonder if you’d get a better reception if you framed it as “would it be worthwhile to come up with a document describing Python’s high-level state and direction?”, and deferred the question of how exactly we’d organize writing such a thing.

7

From my perspective, the council should adequately fill the integral duties described in the quoted charter from the C++ Direction Group, namely that the council will ensure guidance for the language’s evolution and direction at a high-level, though in the most hands-off way possible. Otherwise, I would be skeptical of any “by-invitation-only” formalized group especially early on in the formation of Python’s Steering Council as it seems unnecessarily exclusionary, though I do see the council utilizing members of the community to confer on technical specifics as needed.

Until a need arises to formalize a DG (if it ever does), that role can and should be filled by all Core Developers as well as the greater Python community as needed. Historically speaking, there hasn’t been a single person or group of people who would “solicit” proposals – we’ve all worked to find and support new ideas in one way or another and I don’t see that changing in the future. Restricting that to a few choice people would only hinder growth, creativity, and collaboration.

To more directly answer @njs’s reframing of the question, my assumption is that the council will certainly need to formalize documentation on a decision-making process for PEPs, as well as any additional information that needs to be documented on the core team’s relationship with the PSF per the mandate, but the formalization of any additional groups should be done transparently and as conservatively as possible. A statement on the council’s views on Python’s high-level state and direction may be beneficial at some point as an assurance that the future is indeed in good hands (and judging by our excellent selection of nominees, it inevitably will be).

2 Likes
8

I was certainly thinking about how the future direction of Python would be established when I wrote my governance PEP, so I do think this is an important vision to articulate, and I think the Steering Committee is a good place to start with drafting such a document. No matter who is on the SC, I don’t think they need to carry the entire burden themselves. Whether that means establishing a working group independent of the SC or not, is something worth discussing. It seems obvious to me that the output of such deliberations would be a PEP, and that PEP would go through the normal Informational process.

I might also call this a “roadmap PEP”, and I actually think such a thing is overdue. A roadmap PEP would help focus the development effort of the language, implementation, and stdlib, but it needn’t overly constrain it. It would provide some clarity to folks who aren’t as deeply connected to the daily activity of the project, and it could be used to garner outside support (e.g. commercial development funds). As an example, if this vision PEP expressed the aspirational goal of making CPython start up 2x faster over 2 releases, this would help clarify whether changes to the startup process (or e.g. .pth file processing) helps or hinders that vision.

3 Likes
9

It depends on what kind of answer you think I’m expecting :slight_smile: I’ve actually been very happy with the answers so far - they’ve all given far more insight into how people are thinking about the council than I had before, which is what I wanted to achieve.

If it was really just about getting some kind of vision document created, I’d wait for “whoever” to be elected and then try and pitch it in a way that would appeal to them. But given the opportunity to make a more informed decision before electing anyone, I figured I’d take it (especially since we ended up with the governance model that hands the most freedom to the council).

1 Like
10

I think it would look odd to have a “Steering Committee” require
a “Direction Group” to tell it where to steer to.

While delegation is a good thing for any management group, the vision
and implementation of how to get there has to be defined by the group
which delegates, not an external body.

Otherwise, the group we’re voting on becomes a mere proxy for another
group we did not vote on and this defeats the purpose of the vote,
and the whole democratic approach to begin with.

7 Likes
11

I think the need for a Direction Group depends on the outcome of this election. If the the winners are all veteran core devs, then the community has basically implicitly indicated that the Steering Council will serve the same role as a Direction Group, and @malemburg’s redundancy argument applies. If, however, there are several non-core devs on the Steering Council, then a DG would be a very good idea.

Based on my experience of trying to scale ad-hoc collaboration within an open source context, I think that formal working groups absolutely can aid in transparency and accountability for everyone. But I also deeply agree with @willingc’s perspective about being conservative, lean governance, and being responsive to see what needs organically arise.

I disagree with @yselivanov’s assessment that “adding another decision-making body [significantly alters] the governance model”. The SC charter explicitly states that it should mostly exercise its powers through delegation, and “use its powers lightly”. If it is actively, directly setting direction for the language, that does not seem like a “light” use of powers. I admit that this could be a mis-read on my part, but I view the Steering Council as a meta-governance, dispute-resolving body. The Steering Council is a “Minimum Viable Governance” replacement for the BDFL model, not a replacement for the BDFL.

As @barry says, one of the most important things for the SC to establish is a roadmap and vision document for Python, to reassure all of the user communities (“the tribes of Py”, as I call them) that Python has a bright and viable future. It shouldn’t have to carry that weight alone.

I will repeat what I said in my nomination post: I feel, very deeply, that the single greatest threat to Python’s long-term survival is our community’s ability to evolve our product management capability. I wholeheartedly support efforts to upgrade this, and if that is the spirit of the Direction Group, than I am in support of it. It’s important to note that the C++ model (which we don’t have to follow exactly) still uses a proposal/working group format. It is a Direction group, not a Course-setting group. There are still votes or whatever “normal” PEP procedure we want to follow. It seems to me that one of its most important functions is soliciting for proposals we haven’t seen yet.

Carol mentioned the the PSF SIG model, which I think is conceptually a good one. However, looking at the list of SIGs on the PSF web page, we have a lot of SIGs whose charters are very important (education; documentation; databases) but which are basically dormant. Passively looking for participation on these matters is clearly not connecting us with our massive (and commercial) user base. If the Direction Group can help cohere more velocity in this area, I’m all for it.

2 Likes
12

Would you mind clarifying the nuance for us non-native speakers?

Online search finds ship navigation or aviation answers that add more terms (bearing!), I figured asking directly could help other readers. Thanks!

1 Like
13

I don’t see it working this way. No matter who is on the SC, I expect all core devs (at a minimum) will help craft the roadmap, but the SC will curate it and provide clarity when there’s disagreement.

3 Likes
14

Note: this and my previous replies are based on the assumption that a Direction Group would mostly consist of non-core developers. @steve.dower is the author of PEP 8013 (The External Council Governance Model) after all :slight_smile:

It looks like we at least agree on something: I too think that resolving disputes will be something that the Steering Council will have to do. Especially technical/language design disputes. Based on my own experience of engaging on python-dev expect that that will be a rather frequent (and sometimes stressful) activity.

I’ll use myself as an example to illustrate my point of view. I spent at least a couple of months working full time on every one of my PEPs. For the last one – PEP 567 – I spent a month researching and prototyping, and about three months debating on python-dev, iterating on design, polishing the implementation, etc. Till the day the PEP was approved by Guido I wasn’t completely sure what will be its fate. Given that I had to sacrifice so much of my business and personal time, the whole process was extremely stressful for me. One of the reasons I didn’t just give up, was that Guido himself, someone whose language design expertise I deeply trust, was helping to guide the design and discussions. Even if the PEP would be rejected I would ultimately be able to cope with that.

Now suppose that there was no Guido, and instead we had a Steering Council. Suppose that hypothetical council didn’t have enough members in it who understood/loved/knew Python’s technical side and had a Direction Group to guide it. If my PEP was to be rejected by that external and foreign Direction Group I would completely lose trust in the Council and the whole core-development idea. The most likely outcome – I would begin to contribute less and less and eventually leave the project.

Like it or not, one of the key responsibilities of the Council would be to ensure that the existing Python core developers trust and respect its decisions. That they are encouraged to work on Python, work on challenging new ideas and PEPs, triage bugs etc. Conflicts and challenging technical disputes happen almost every day, it’s an essential part of Python core development. It is simple to reject (or accept) a PEP when 90% of core devs are in favour, but what if it’s a 50/50 split?

I do believe that the Council must be technically equipped to do what Guido had been doing for Python for so long. And if it doesn’t, then no Direction Group can help it to successfully communicate with core developers and lead Python.

FWIW I don’t think that all 5 members must be core developers or be ready to dive in technical details of all proposals on python-dev. But at least 2 technical members, in my opinion, should ensure that our Council doesn’t need another Council or Direction Group.

5 Likes
15

Thanks for the additional discussion! I appreciate the thought you’ve clearly put into this.

FWIW, my idea was to move the conflict resolution aspect (“do we think this controversial change is justified”) outside of the core team, primarily to avoid conflicts of interest. If I were to design a direction group, I’d closely follow the invite-only model that C++ used, probably by nominating Guido and letting him choose whoever and however many people he wanted to work with. Like the C++ group, they’d have no power to approve or reject proposals, but would predefine (in our case) “Pythonic” in such a way that the council could use it to assist with their decision making (e.g. “I reject this proposal because it doesn’t align with this aspect of the vision document”).

But I’m not designing the group, so my ideas don’t matter so much :slight_smile:

1 Like
16

I can’t refrain from asking: is there any actual difference between “Steering” and “Direction”? Or is one groupe meant to appeal to germanophile core developers and the other to the more latin-leaning? :wink:

4 Likes
17

:joy:

For me, the person [ in the car ] reading the map is providing direction. The person holding the wheel is doing the steering.

18

Already :heart: 'd a few replies without reading everyone’s so I’ll keep mine short: The Steering Council will be able to fill this role. Even in the case they decide otherwise, all of our possible candidates are self aware enough to realize when they cannot and seek input from others in the community who are.

I do not think creating new groups of people should be a priority… it adds beaurocracy and complicates decisions. Especially while still finding our own “new council smell” feet.

3 Likes
19

Previously, I already proposed on python-committers to have a formalized concept of “sub-teams”, and maybe delegate permissions, but nobody supported this idea. I understand that it’s not a popular idea.

I wrote PEP 8015 which is designed around delegation and workgroups (called “teams” in my PEP). My PEP has been rejected (and wasn’t in the top 3 in the vote results), so I understand that core developers don’t trust or don’t like such organization, and prefer to put more power in the hands of a steering committee. (Well, I also heard that my PEP is pushing bureaucracy too far, which can be another reason was it hasn’t been selected.)

Even if my PEP 8015 has been rejected, I’m still a strong believer that the steering committee must listen to identified experts. I don’t expect the committee to make decisions in private and not listen to anyone, it wouldn’t make sense.

Maybe we can create workgroups anyway (not only for the language, see my PEP 8015 for other topics which may justify to create a workgroup), but I wouldn’t suggest to have a strict relationship between workgroups and how Steering Committee take decisions.

3 Likes
20

@steve.dower As Carol said, the new Steering Council will take time to settle down, and throughout the process, it will also stay open to the ideas from the core-developers (does not matter who all are in the council). I am sure that the council members will not try to hide the reasons behind any decision they have to make, and also they would be open to the input from others.

Effective communication and making decisions based on those inputs would be major work for this new council. In the coming months, it may find that it would be easier to have to a certain group of folks (as you said, the direction group, or call it by any other name) to ask for suggestions first, and then (also) listen to the bigger crowd of the core developers.

1 Like