My thoughts on a good composition for the steering council

Hi all,

This first council is going to set the stage for further councils in a way, as well as likely settle the biggest governance questions. However, it’s also special because it’s the one where we’re transitioning our governance model, meaning it will probably need to be more BDFL-like at first than future councils will. With all that in mind, it’s important that we are extra cognizant this time around of who would fit best (and how well they would work together).

Initial Thoughts

Initially I focused particularly on individuals and thought the following would make up a good council, especially considering continuity:

  • Guido
  • Barry
  • Brett
  • Carol
  • Łukasz, Victor, or Yury

The first three, in addition to providing continuity, have good instincts and are really good about being objective in decision-making (and are thoughtful community-wise). I couldn’t imagine a council without Carol, whose thoughtfulness is superhuman and would have a critical impact on the council’s decisions and effect. I also thought the council would benefit from someone willing to break a few eggs to push Python forward. Those five people would be a mix that would give us a good result.

Post-Discussion Thoughts

After discussing this with @steve.dower and @barry last week, I started thinking more about classifications of council members. Here are the groupings I was already thinking of plus a few from Steve and Barry:

  • old guard (especially important for this first council)
  • new to core development
  • runs a business (deals with efficiency, process)
  • effective at community (able to process all the needs & viewpoints)
  • forward-thinking (pushing things forward)
  • teaches Python
  • part of an under-represented group (relative to python-dev), e.g. gender, nationality, etc. (diversity makes our group richer and helps us make better decisions)
  • has mentored or is mentoring
  • time zone (a world-wide spread potentially impacts council communication and speed)
  • core developer vs. external

Obviously our pool of candidates is composed of people that fall into several of these groups. Think of it as a Venn diagram. :slight_smile: I expect we’ll want to maximize coverage between the five elected council members.

Note that “technical proficiency” is not a category. Nor do I think it should be a prerequisite for the council. Instead, the council should be adept at deferring technical decisions (on a case-by-case basis) to delegates that can make effective choices. (A member of the council could certainly be chosen as a delegate, but that’s up to the council.) FWIW, I hope that this first council feels comfortable right away with pronouncing on a few PEPs (or picking speedy delegates), so we can clear out our logjam. :slight_smile:

Another important consideration is that there’s a realistic possibility that most incumbents (which run again) will maintain their seats on the council. That would probably be fine, but it does factor in to the idea of “the composition of this first council is special”.

“Final” Thoughts

With all that said, below are councils that I (currently) think would be effective for this release. We’re lucky to have a great pool of candidates. The below selections are a reflection of my ideas on composition and not an assessment of any individuals–I mean no disrespect to any candidates. :slight_smile:

strongly transitional

  • Guido
  • Barry or Nick
  • Brett
  • Carol
  • Emily or Yury

more typical (anticipated)

  • Brett
  • Nick or Greg
  • Carol or Mariatta
  • Emily
  • Yury or Victor

FWIW, I don’t intend the above as any form of politicking (telling others how they should vote). It’s a demonstration of how I think we can compose an effective council. Furthermore, neither of the above is necessarily how I will end up voting. :slight_smile: I’d like to see an educator on the council, but wasn’t sure there was a good candidate (David?). I’m also inclined to include Peter or Travis somehow, for the sake of their insight.

Anyway, I figured it would be useful to share my thoughts on the composition of the steering council. I hope you find it helpful.



We’re not composing, though, we’re voting for individuals. Regardless of how carefully you pick your favourite Council composition, the end result has a large chance of being dissimilar. In other words, I think it’s misguided to try to vote for a combination you like as a whole.

Edit: also, I’m not sure what the goal is this topic is. Are other people expected to post their own “ideal councils”? Something else?


Sure. I’m just saying that we, as voters, need to consider more than just individuals, even if the resulting council doesn’t necessarily fit a composition that anyone had in mind. The point of my post was to introduce how I am thinking about it and to encourage people to think beyond individuals too. :slight_smile:

If later we find that composition is particularly important then we can look into corresponding strategies to help with that (e.g. Mariata’s PEP 8011). However, I anticipate we’ll be fine. :slight_smile:


Hi @eric.snow - I have already voted. But your sharing of composition and thoughts, seems to have influence the election process. Perhaps we should avoid and observe this is a quiet period? :slight_smile:


Thanks for posting, Eric. I think it’s totally valid to think out loud about this, as decision-making in a vacuum is the easiest way to reinforce prejudices without considering any other points of view. And since many voters do not know a lot of the candidates as well as you, along with most candidates choosing to avoid saying too much, your added context will certainly help more people make informed decisions.

It is unfortunate that the voting process forces each of us to choose a complete council, as has been discussed in the other thread. We certainly have a number of perfectly good end results available to us, but no way to ensure good pairings. Being able to aim for diversity is important, but I think in every category you mention there will be divided votes (except perhaps for Carol :slight_smile: ). Perhaps if enough voters agree not just on individuals but on who else is needed to balance their contributions, we’ll get a well-composed council at the end.


Thanks Eric and Steve for the kind words.

I’m going to echo what I have in my candidate statement. While I would be honored to be on the Council, I would be equally honored to serve in an advisory role to the council for governance best practices.

There are so many wonderful folks on the slate that I am confident that the inaugural Steering Council will be great and will work to do the best that they can for CPython.


I agree with your comments, @pitrou. In multi-seat elections though, one thing I’ve often seen is candidates running as slates, or people endorsing a slate of candidates. That can counter what you’re observing and make it more likely for a slate as a whole to win (since the combination is being publicized and enough people can choose to agree with that publicized combination).

Without such coordination (or change to something like proportional voting or voting for particular seats), it’s hard to ensure anything about the overall “combination.”

1 Like

In case people aren’t aware – in this vote (unlike the last one), you can log back into Helios and change your votes, any time between now and when the vote closes. So if you change your mind – maybe based on reading discussions – then, you can change your mind :-).

That’s true, and in any kind of community vote there’s always a gap between what an individual vote can express and what will eventually happen. But still, if you think the ideal council should have a mix of X people and Y people, then it’s probably a good idea to vote for a mix of X people and Y people :-).

Strongly agree here. You know that thing where successful engineers get promoted into management, and then they discover that management is a totally different skillset than engineering? The council’s an administrative body, not a technical body, so personally I’m going to be looking for people who I think will be good at delegating, listening, mediating, herding cats, … of course technical skill and a long memory are also valuable, but if they’re missing any particular piece of knowledge then they’ll have lots of experts around to ask.


In certain situations, like if A people are likely to be elected no matter what and B people aren’t, it might be a better strategy to vote only for B people. Otherwise, things can happen like your votes for the A people knocking out the B candidates, or different people not voting for the same B people and causing none of them to be elected (e.g. if there are more B people than spots). This is why I mentioned things like coordinating (e.g. via slates or endorsements), and alternative methods of selection like proportional voting. They can help ensure things about the overall composition that you otherwise can’t.

I wholeheartedly concur.

I suspect the final make up will be interesting and maybe (hopefully?) a little surprising. I’ll abstain from giving my list, but I do think you’ve enumerated some interesting categories. Each person on the list fits into multiple categories, and I doubt anybody fits into all of them.

If you look at where the language and the community is today, you can see a clear connecting thread from Python’s early days, and the positive, inclusive, collaborative, friendly culture that Guido established. I hope, and am confident that the SC will preserve and nurture the best of this, the things we all love about Python-the-community, while keeping in mind what makes Python-the-language great and fun to use. All this while acknowledging the challenges ahead for a nearly 30 year old, mature, language. That’s why for me, some of the most important characteristics will be the ability to project the established wisdom into the new future direction. IOW, keep that thread alive, and weave it into an even better tapestry.


I don’t think this is what people voted for in PEP 8016. The governance PEPs were primarily about replacing the BDFL decision making process.

Also, I don’t think that a) people here should be “managed” or b) that you can successfully manage technical people without having put in the hours on the bug tracker (in this particular instance).


Except that PEP 8016 was specifically about “everyone” delegating the governance design process to a focused group, hence the idea being that the council should establish processes and then remain hands-off as much as possible.

I suspect a number of candidates missed that subtlety (and a larger number of voters?), and that’s why we’re seeing people suggest on other threads that it would be against the spirit of the PEP for the council to delegate on certain things.

Perhaps unsurprisingly, people voted for the proposal that was easiest to project their own ideas onto. Which is why vague proposals and lack of discussion are such poor ways to do decision making :frowning:


I agree with your distinction. People contributing to CPython are volunteers. As volunteers, people choose or not to contribute based on their personal reasons.

In my view, the Council is not managing people in the traditional sense. Instead, the Council is responsible for managing processes that sustain CPython and its development.

To sustain CPython and its development successfully, it would be helpful for the Council to draw on a variety of talents both within the Council members and the greater community. Personally, I trust whoever is selected to the Council to ask insightful questions, gather any needed information, seek input from technical subject matter experts, and consider the risks of any technical decisions.


Agreed. However, the council still has the authority to pronounce on PEPS (and gate ideas early), even if the pattern will ultimately strongly favor delegation. FWIW, my hope is that the council will pronounce on a number of waiting PEPs right away to clear out the logjam a bit. :slight_smile:


I disagree. I’m strongly in favour of this sort of discussion. In a “real life” election, I’d discuss my views with friends. In this context, the Python community are those friends, and I value their opinions. I don’t see it as influencing or politicking, just as a community sharing opinions.

I’m also very grateful and interested to see the candidates contributing - it’s great to get additional insight into how potential council members will respond to questions like this. On that note, it’s a shame that external candidates are excluded from this sort of conversation. Maybe that’s something we should think about for the next election.


Since this is discourse, we can probably just move this topic to the Users category, so external candidates can participate.


FYI I first wanted to send a similar pos (explain how I plan to select my candidates)… but then I decided to keep it private :wink:


Given the 5 vote limit, my own approach to voting for the council was pretty similar to the one that Eric describes: voting for what I considered to be a well-balanced council, rather than only considering the candidates in isolation from each other.

I think the Council needs at least a couple of folks with the “core dev for 10+ years” characteristic, simply because it’s a cat herding job, and in an online community like ours, it takes a long time to build up good mental models of other participants, such that you can make a decent attempt at correctly inferring all the things that they didn’t actually write down in their messages. Observing the core development process for that long also brings with it a host of past examples to compare new situations with, allowing some potential future missteps to be avoided.

However, I also think we’d be squandering an opportunity if we ended up with the Council as a whole being as demographically similar to each other as the criterion of “Python core developer for 10+ years” would currently imply, and instead hope we can achieve an outcome that better represents the complexity and diversity of the overall Python community (both in the sense of “the range of people using Python” and “the range of tasks that Python is being applied to”).

While there are limits to how representative a group of 5 people can be, we ideally want folks from multiple geographic regions, different personal & professional backgrounds, etc, as these are all things that can impact someone’s learning experiences, and hence the way they end up interacting with even something as seemingly abstract as a programming language. On that front, I think Eric’s list of characteristics is a nice way of thinking about some of the potential axes of difference worth considering.

I’ll also note that something we don’t know yet is the impact that the “only 5 votes” limit is going to have relative to pure approval voting. As discussed in Why limit to 5 votes?, my original concern with plain Approval voting was that we’d see experienced candidates getting a lot of “I trust them to keep doing what they’ve already been doing for years” votes, and that would then risk crowding out external candidates and more recently promoted core developers that may not have as much personal name recognition.

While the restriction to 5 votes may go some way towards countering that effect, other participants in that thread pointed out that the effect may go in the other direction, with voters choosing to only approve candidates that they already know well, and hence omitting candidates that they would have been OK with, but don’t know as well.


I voted for a balance, but I’d certainly have voted for more “newcomers” if I’d been able to vote for more than 5. The risk then is that votes get split as a result of that.

But at this point, we can only see what we get and maybe learn from the result for next time.


Thank you all for the discussion. It gave me some things to think about before reading the nominations. I am encouraged that so many people want to contribute.