Huh, it actually never occurred to me that that was “extra baggage”. To me, determining who was a core dev, and what that meant, is obviously part of what Guido did and what we need to do to replace him.
Our current process for promoting a core dev is pretty informal, right? Which is fine for easy cases where everyone agrees that someone’s ready, or everyone agrees that someone’s not ready. But sometimes there are borderline cases where there are some +1s, and some -1s, and there are more +1s then -1s, but no-one’s exactly sure what the threshold is. Right now, those cases are effectively resolved by Guido, either directly or indirectly (e.g. someone declares what they think the resolution is, and he doesn’t object). I can’t speak for the other PEPs, but at least for PEP 8016 the reason there’s a process for promoting core devs isn’t because we’re ambitious to change things, it’s because we thought we needed something written down that didn’t rely on Guido.
@pf_moore: if one of these ambiguous cases comes up next year, what do you think should happen?
This also makes me realize I’m a bit unclear on how PEP 8010 and 8011 handle these cases. Right now, I think we all agree that Guido has at least the following powers:
- Pronounce on PEPs
- Decide whether a particular decision requires a PEP
- Decide whether or not an alternative implementation is really Python
- Add people to the core team, remove people from the core team, change the process for promoting people
- Make decisions about special cases, like giving someone bpo permissions without commit permissions, or giving commit permissions but only for the docs
- Change the rules for the governance itself, or for any of the above
The text in PEP 8010 and 8011 makes clear that their leaders can pronounce on PEPs. And originally, PEP 8010 used language like “dictator” that made me assume that everything Guido could do carried over. But I’m not sure! @barry, can a GUIDO do all of the things above, or if not, then which ones? @Mariatta, can a trio do all of the things above, or if not, then which ones?
Well, this kind of concern is exactly why I think discussion is important :-). I think the most productive way to discuss is to act like the PEPs aren’t entirely frozen – obviously we are reluctant to change them now, but it’s better to have a free-ranging discussion and then decide not to change them, than it is to miss out on a critical change that would get broad consensus except everyone was too nervous to bring it up.
I guess that’s true, but even the proposals that don’t ask core devs to vote on PEPs, do still require the core devs to vote on something. For PEP 8016 we were trying to be as minimal as possible – the only hard-coded thing that core devs do is vote for the steering council [Edit: or for changing the governance doc] – but that’s still enough that you need to know who the core devs are. (Cf. the confusion we’ve had with PEP 8000 trying to figure out exactly who gets to vote.) For PEP 8010, core devs still vote in GUIDO and CoP and no-confidence elections, so we still need to have a definitive list of core devs somewhere, and some kind of process for maintaining that list.
FWIW IME the challenge with promoting new contributors is usually convincing them that their opinion is valid and worth expressing. Most people are really worried about overstepping their authority and messing things up.