I agree. I suspect we may even end up not reaching the 5-people threshold. We could assume a 2-step process in which all core-devs can nominate each other as in:
assume that all core-devs are potential candidates and nominate them during a certain time window (say 2 weeks)
at the end of this phase the nominated candidates can decide whether to accept the nomination or not and only then the final voting process can start
Phase #1 would basically help ending up with a bigger (> 5) pool of candidates to choose from and would also help instilling trust in those “shy” people who may not even consider candidacy right now but may change their mind later.
Between phase #1 and phase #2 we could even decide to have an intermediate phase to help people make a well thought-out final vote and either:
have a neutral third-party person who collects and publishes candidates’ past accomplishments
start a public discussion in which people can express their (motivated) preference for candidate X or Y
I’m not worried. I know of at least 3 core devs who have expressed interest in being on the council and there’s already been one external person who has asked for someone to nominate them and I know of at least one other external that some people are interested in nominating. I don’t think we need to prematurely worry about not having enough candidates.
I think a better solution is to say that self-nomination is not a bad thing and core devs should feel free to do it. And then on top of that everyone should feel comfortable asking someone if they were planning to self-nominate or whether they would be comfortable being nominated.
That would mean 3-5 potential candidates at minimum and perhaps a bunch of others at best. If voters have fewer people to choose from, some of the candidates may end up in the council just in order to meet the original 5 people requirement, not necessarily because they are people who are trusted to fulfill such a role.
Also, weren’t the candidates supposed to be core-devs only? My understanding was that PEP-8013 was the only proposal explicitly allowing external candidates.
I personally don’t think we know what the “best” results will be yet since we have not even opened up nominations. We have two weeks to push for more nominees if we look like we will be short on choices.
At some point before voting started the PEP was updated to open it up to external nominees.
If anyone’s curious about the history, this was based on a suggestion from @steve.dower and the discussion happened in this thread.
Also as a general comment: please remember that we don’t have to anticipate every possible problem right now; we can see how it goes and then adjust based on what we learned :-).
Well, let me say that is unfortunate because the PEP is not explicit about this point as it just states:
The steering council is a 5-person committee
AFAICT that’s the only part in the document which implies the involvement of “external persons”. I personally had no idea that was the actual intent. The change was introduced here and the rationale was:
Removed the requirement that council members have to be core team members; added the requirement that non-core-team council candidates need to be nominated by a core team member. Steve Dower is worried that we may have a shortage of core team members who are willing to serve on the council.
…which is basically the same concern which is being expressed in here. For the record, PEP 8013 The External Council Governance Model (which on the other hand is explicit about it) is the PEP which received the less consensus amongst core developers.
I’m sorry if this detail wasn’t clear to you. It was discussed publicly and AFAICT the text is unambiguous, but you’re right that it doesn’t explicitly say that non-core-team-members can be on the council, it just doesn’t forbid it.
PEP 8013 isn’t really comparable; it said that core team members were forbidden to serve on the council.
In any case, any council member has to not just be nominated, but also pass a vote of all core devs, so I don’t think there’s much risk of random people sneaking on behind our backs.
I believe this detail wasn’t clear to the majority of people who voted for PEP-8016 and who didn’t take a closer look at the discussion or noticed the commit, not only me. The people were supposed to vote the final incarnation of the PEP. They weren’t supposed to read and interpret the bits of information which was scattered between a PR commit message and a long discussion which took place on Discuss over the course of almost 2 months.
I disagree. As I said the concern here is that if few core developers will propose themselves for candidacy (as I think will be the case, and which was the very rationale of this change), it will be inevitable that some external unknown person will end up in the council simply in order to fulfill the 5-persons requirement.
And that is why I think a possible solution would be having all core developers publicly nominate each other first. One may decide to reject the candidacy but accept it in case the alternative is to have an external unknown person instead. This way we can understand who are the ones which are deemed more trustworthy by the core-dev community, and also end up with a bigger pool of valuable candidates to choose from.
Unfortunately it’s too late if people didn’t pick up on this detail either during the discussion or in the PEP itself.
I still think we are prematurely worrying here. I say wait until the nominations have been open for at least a few days before worrying whether we are going to come up short.
And as for “unknown” external folks, every name I have seen floated are known to at least a subset of core devs do know. But if you don’t like the option then simply don’t vote for them.
That means 96 opt-out nominations, of which 62 felt engaged enough to vote. To me that suggests we are going to end up with a huge amount of people won’t speak up because they are not engaged enough to notice they were nominated by you simply by being a core dev (of whom some I would argue are less known then some of the external candidates I have heard proposed).
Right, there’s a big difference between “core developers must be subjected to external oversight” (the unpopular PEP 8013 model) and “core developers are free to nominate folks outside the core development team that are willing to volunteer their time to offer the core developers advice on governance and language design questions” (what the chosen PEP 8016 allows for).
Personally, I’ve already written to one person outside the core development team that I think could offer us some valuable Python user community insight if she has the time to spare for it, and if she agrees to be nominated, I think there’s a reasonable chance that enough other core devs would agree with me that she might be elected to the inaugural Steering Council.
I’d encourage other core devs to approach the problem the same way: if there’s someone that you think could provide language design and community governance insight beyond what we already possess within the core development team, and you think there’s at a least chance they might be willing and able to volunteer their time to help us out, then there’s no harm in asking them (privately!) if they’re interested in having you nominate them as a candidate for the inaugural Steering Council.