Question for council candidates: Direction Group


(David Mertz) #21

I agree especially with Emily Morehouse’ comment that “[T]he council should adequately fill the integral duties described in the quoted charter from the C++ Direction Group.”

More specifically, I believe that the SC will absolutely require expert advice on many topics. But I also think that expert advice should be focused on specific topics, i.e. on particular PEPs or families of closely related PEPs. I expect that all member of the SC will have a broad technical knowledge, at least enough to know what the right questions to ask are, so the need for additional generalists feels less likely. However, on in-depth matters, we/they would often need to rely on one or more delegates for advice (I suppose now SC-delegate rather than BDFL-delegate).

We already have the delegate role in relation to PEPs, so there is probably overlap between that and this likely new role. But I think that using the equivalent of legal “special masters” is likely to be common (who may well be the person as a PEP delegate). However, as I’ve said, I don’t think that should be a standing role, but one specific to a particular decision process.

(Nick Coghlan) #22

I think the Steering Council’s mandate definitely covers the second part of the C++ Direction Group’s role: if the SC consider there to be zero chance of a proposal ever being accepted, then it’s simple courtesy to make that clear relatively early in the process, before folks have invested too much time in a research & development effort that’s doomed to go nowhere.

The degree to which the SC tackles the road map & priority setting aspect is still an open question, since we’ve historically taken a “many agendas, few plans” approach to that, with folks choosing for themselves what they want to work on based on their own personal interests.

It’s not yet clear to me whether it’s viable to change that within the context of the existing community driven project, since I don’t see a lot of point to declaring a road map without some means of directing resources towards the road map items, and I’m not clear on what the gain would be for the AmaGoogFaceSofts of the world to delegate that task to an elected community Steering Council over just assigning their own developers as they see fit.

Tangent:,, and are all interesting to browse through. One particularly notable distinction between open source projects like CPython and traditional standards committees is that the latter are pay-to-play exercises, where you have to be a member of a recognised standards body to participate (and those membership fees can be on the order of $100 a month or more)

(Peter Wang) #23

Here are the functions needed to replace Guido:

  1. Final arbitration to resolve disputes
  2. Innovation & Visioneering - Defending the “soul” of the language, forward-looking vision about what the language is about
  3. Community management
  4. Decisions on PEPs and other technical matters
  5. Product management decisions about prioritizing aspects of the release, reconciling user needs around language features, stdlib improvements, etc. with release schedule

It is no wonder that he burned out!

My understanding of the Steering Council was that it was really meant to serve as function #1, and it fulfills its obligations on 2-4 by the creation of separate groups or committees. Thus, I interpret this question about a Direction Group as primarily being concerned with function 2, and possibly projecting into function 4.

My disagreement with foisting PEP resolution onto the Steering Council is that that shortchanges the bandwidth for providing high-level input and guidance to each of the other important topic areas. With the creation of this council, we have the chance to set up an organization structure that actually scales up our group’s collective capability, as opposed to merely re-allocating it.

Of course, if the result of the election is that the SC consists entirely of experienced core devs, my expectation is that people will fall into familiar patterns, and treat their job as primarily being Function #4.

(Travis E Oliphant) #24

One of the principles of the Python community that has been incredibly enabling has been the ability for anyone to participate in the evolution of the language. I believe the Python community should continue to encourage the PEP process for language evolution. If there is a high-level “direction PEP” that a group of core developers or other community members want to write, then they should do that and get support or challenges to the ideas being expressed.

The Steering Council would get involved in their joint capacity only when (and after) this process results in divergent views that have to be resolved and a decision made. In this way, anyone could participate in the “Direction of Python” discussions and only if in the course of time that real forks in the road appear after some discussion and exploration, would the Steering Council need to act. I don’t believe they could delegate that final decision.

Thus, rather than a Direction Group, a Direction Document could be written by any collection of language champions and proceed to get feedback and potential buy-in.

(Terry Jan Reedy) #25

With the election near over, let me contribute my experience with IDLE. A year and some months ago, I posted an IDLE Roadmap to idledev to let new contributors know (and remind myself) where I want to go with IDLE and what sort of PRs I would most welcome and review quickly. Testing was one item. There is now a test file for all 60 IDLE modules and we are about half way to 95% coverage. Conversion from tk to ttk widgets is either done or so close that I should just finish it. About time to post a revision.

I have also posted mini-roadmaps as index issues. ‘Improve code context’ listed about 15 possible fixes and improvements. With our attention focused, Cheryl Sabella and I fixed several and I opened a revised index issue. Last fall, when she had time again, Cheryl Sabella submitted more Code Context PRs, which I quickly reviewed and merged. Just a few left.

I think Travis is correct that high-level roadmaps (plural) can and should be produced by self-selected volunteers. I would like to read some. What are people’s visions?

Nick is correct that roadmaps cannot command resources. But they can, especially when specific, invite resources. Some IDLE contributors submit specific itch PRs. Cheryl wanted to ‘contribute to IDLE’, so lists of specific items helped us work together. Reading the core-mentorship list, it seems that there are many other people with a general ‘contribute to Python’ itch. Looking through the 1000s of issues, without knowing which have a core developer willing to review a PR, is overwhelming.

(Barry Warsaw) #26

And if we’re able to begin accepting donations large enough to fund actual PSF-sponsored (or employed?) development work, then having a roadmap will be critical to convincing the purses that their money will be well spent. I think it’s much less that corporations have different priorities than volunteers (though that can also be the case), but they they have a lot less visibility into priorities that align between the two. And I think there’s a lot of potential alignment.