Since I have reservations on my own level of involvement, I’ll decide whether I candidate or not based on who else has candidated 
(IOW, if there’s a set of 5+ people that I think would make perfectly decent Committee members, I won’t bother candidating and putting myself in trouble for 1+ year)
I think Antoine has exactly the right attitude here: if you don’t like the candidates, nominate some more or nominate yourself. Arguing about the text of the PEP now looks like petty sniping, rather than useful contribution.
Declaring “everyone should do X” is the same thing - if it ought to be done, just go ahead and do it. This is already set up such that you don’t need extra permission to nominate someone or encourage them to self-nominate, just as nobody is restricted from asking an individual privately before nominating publicly. You’re arguing about nothing.
Look, I am not interested in arguing over PEP-8016 (or with anybody) anymore simply because it cannot be undone. What has not being done yet is deciding how to manage the nomination / election process exactly, and I think it is crucial that this gets discussed as openly and publicly as possible and in a civil manner. If allowing external people is the direction the majority of people want to go so be it, but AFAIU this has not been determined yet.
I totally get that you were blindsided by realizing that PEP 8016 allows for external candidates, and that’s a sucky feeling. I hear that. And maybe it wasn’t handled in the best possible way, and that’s partially on me.
But… the text does allow for external candidates, so I’m having trouble figure out what you’re hoping to do now. Is your goal here to convince everyone not to nominate any external candidates, or … what?
I think that allowing external candidates is a good thing.
Something that’s not highlighted enough in the PEPs is the
need for good language design. While we all have a feeling for
what may be right or wrong in particular cases, (IMO) no core
team member except Guido has the required overarching skill and
gut feeling to set directions for the language at a higher level.
Given this limitation and unless Guido plans to join the council
it would be useful to get external help with high level language
design.
1 Like
My original concern even before acknowledging that external candidates are involved derived from Guido’s comment which made me realize that because many core-devs may be too shy to nominate themselves we may end up having few potential candidates to choose from.
That is why I suggested implementing some sort of a 2-step process in which we all publicly nominate each other first, as a possible strategy to minimize “shyness”, collect more candidates and allow us to express a vote based on quality/trust rather than on scarcity of people.
After acknowledging that external people are involved I’m a bit puzzled because I’m not sure I understand what the implications of this may be in practice. For instance, does the newcomer also become a core-dev? What kind of ability or vision is it expected from them? What kind of distribution should we expect in terms of mere numbers? As of today is there an estimate on how many people are actually interested in the role?
Based on the council’s mandate I don’t expect anyone on the council to have strong language design but a good ability to choose the process on how to make those kinds of decisions. So for me personally, I would want people with a skill set aimed at project management/leadership and the ability to identify a process and/or people with good language design.
2 Likes
I personally don’t know, but I would expect it would be something they would work towards as they will be establishing the processes that directly affect us core devs and thus they should plan to be have to benefit/suffer from their decisions. 
I personally think the council’s job is to make sure the Python project continues to function. That means making sure our PEP process continues to function (which includes figuring out how to decide about design-related PEPs without Guido), conduct stuff, representing us with the PSF, etc. Basically the council does project management IMO.
I don’t think there’s any expectation. For me it’s going to come down to who’s the most qualified, external or not. I have no personal quota in my head (although I do hope for general diversity on the council).
Nope. 
1 Like
If the criterion here is “has designed a successful programming language”, I doubt you’ll find an external candidate that satisfies it, either.
If the criterion is something else then I’d like to know what it is
I know a few of these people, and they’ve certainly been willing to throw input our direction 
Though I wasn’t planning to nominate them.
“Deciding how to decide in the absence of personal knowledge” is a big criteria for me. And since this council doesn’t actually do the deciding, this has to be interpreted as someone who can set a policy for how to decide, rather than someone who’s good at reading individual situations. So anyone with experience running a large team or business, particularly with open source exposure, looks like a pretty good choice.
Another somewhat random criteria that will influence my voting is that I’d like at least one of the council members to be in a significantly different time zone from the rest. Forcing the council to work under those circumstances will help ensure any processes they put in place will also work for our widely distributed team.
1 Like
If the criterion here is has designed a successful programming
language, I doubt youll find an external candidate that satisfies it,
either.
That would be taking it too far and I also don’t expect us to find
someone in this first round, but having the possibility is good.
If the criterion is something else then Id like to know what it is
IMO it should be someone who has significant experience in
language design.
I certainly hope that the council will be more than just a
bureaucratic administration committee.
We need a team implementing a common vision, with passion, dedication
and a view for where Python should be heading.
1 Like
Unfortunately, the administration committee is what everyone voted for. PEP 8016 was the only one that didn’t designate a day-to-day process, but instead proposed an extra step of electing a group of people to choose (and continually manage) this process.
So we don’t yet have any idea who will decide whether individual PEPs are in the spirit of Python or not, or how these decisions will be made. We have to choose people we trust to choose these things on our behalf.
(Nathaniel please please cut me off if I’m misrepresenting this. I really don’t want to do that.)
1 Like
I think that is an important aspect which should be clarified because it changes the criteria we’ve been using to elect core developers through a slow, gradual mentorship in order to build mutual trust.
I am not sure if this was the actual intent of the PEP, but perhaps the people involved in its writing could clarify. It appears to me that the fundamental idea here is to include a figure which is deliberately more detached from the technical aspect which characterized the people involved in the development of the language so far, and steer towards a figure which looks more like a manager than a developer. But how is a manager supposed to judge or steer direction over a technical PEP or syntax changes?
I think part of the problem is that since the mandate was originally originally intended for core developers, that assumes that such a technical aspect is implicit and taken for granted. But if we apply the same criteria to a fundamentally different kind of figure then it must be clear what to expect from such a figure exactly, but the PEP doesn’t say.
Frankly, I don’t think this is what most people expected when they voted for this PEP, regardless of whether they understood it included external candidates (and I still think most of them didn’t).
It appears back in October there were 10 potential nominees. Not sure if that’s still the case but it looks like a big number to me compared to the possible core-dev candidates which we’ll be able to collect and which I suspect will be quite a minority by comparison.
For context, that was a rough list of names of non-core developers who are nonetheless known in the Python community and would be acceptable in some sort of influential role. We did it at the sprints in response to claims that “nobody outside the core dev team could possibly be helpful”.
At this stage, it’s not a useful list. None of the people were approached or had volunteered at that time, it was simply a device to show that it was easier to come up with a bigger list of acceptable candidates from outside the core developer team than within it.
As I’ve said in other places, if one of your criteria is “has prior experience merging pull requests”, great, the core committers are an appropriate pool of candidates to limit yourself to. If you are looking for other skills and experience, limiting ourselves to those who were willing to merge code does not make any sense.
Responding to the thread generally:
I would say, the point of the council being “primarily administrative” is to avoid the situation where the same person has to be responsible for both administration and language design, and also to split up the administrative role over several people – which is important both for load-balancing and to represent a broader cross-section of the community.
Since council members are chosen by the core team, I’m sure they’ll have all kinds of skills – technical, administrative, big-picture vision, fine-grained details, etc. I mean, these are going to be people you already know. They’ll be people who have lives and contributions beyond their work on the council. And that’s great, it will help inform their work on the council. It’s not like people on the council are forbidden to provide leadership or have technical knowledge, that would be absurd. It’s just, we’re not relying on them to do all that work; their job is to make sure good stuff happens, not necessarily to do it all themselves. People don’t need to be on the council to articulate a vision for python; people don’t need to be on the council to give advice on language design; etc.
The technical details of the nomination process are already set for this election. I don’t know that they’re the most optimal ones, but they should work well enough, and once we see how it goes we can always tweak them in the future.
But the good news is that everything you’re saying here is totally compatible with what we’re doing :-). There’s a two week nomination period, and if you want to spend that time encouraging and nominating lots of current core devs to run, then that sounds great to me?
PEP 8016/PEP 13 doesn’t currently have any mechanism for someone to automatically become a “core team member” just because they’re elected to the council. The only way for someone to join the core team is by a vote of the core team. Now I guess if someone who’s not on the core team gets elected to the council, that means the core team respects them, and also serving on the council will give them many chances to impress the rest of the core team with their contributions, so it seems plausible that they will eventually end up joining the core team as well. But it’s a manual process, so there will be plenty of time to discuss it if/when it comes up.
2 Likes
And I think this is the tricky bit that is leading to the different perspectives between e.g. @malemburg and @steve.dower as I quoted above. PEP 13 explicitly says the council is in charge of running the project, but it could also drive an overall vision for the language. Add on top of that the fact that either the council itself could be the creators of the vision or they could choose who should propose that vision, and I think it shows the variety in potential expectations placed on the council.
To me this means that if we want the council to handle e.g. creating a vision for the language we can, but then we may want to have more people come forward with their expectations to help frame what kind of candidates people are after as well as what they are going to expect from council members.
1 Like
I understand the rationale. It’s a logical one. But I can’t help not noticing that this was not the position that was expressed in PEP-8016 in its final form as it didn’t clearly express what the general intent was regarding the people involved (core-dev vs. external) and the role they were supposed to have exactly (developer vs. project manager), hence my surprise. Anyway, that boat has sailed, and I appreciate you chiming in and clarify your position.
Sounds reasonable.
Sounds good. I personally agree with Antoine’s position: some core-devs may decide whether to candidate or not based on who else has candidated, but in order for that to be effective nominations should not be submitted too late. Perhaps one can propose themselves as a “potential candidate” and give confirmation nearing the end of the 2 weeks, or we could have a 2-step nomination process as I proposed earlier on, but I’m not sure whether that is contemplated with the current model (probably not) or is desirable.
Again, yes, you can do this if you like. But you can’t force anyone else to do it.
Go ahead and nominate people without asking them if you want, it’s only going to reflect poorly on yourself if they all refuse.
If you’re worried about what the council might or should do, then you’re exactly the person who should be self-nominating and clearly articulating what your plans would be.
Discussing the process itself is done. We have a PEP. So far, frankly, all you’ve achieved is convincing me (and perhaps others) that you don’t have a forward-looking mentality and that I don’t want you on the council.