Same goes for me, considering your clear aversion about having core developers into the council. Now let’s call it even and stop this here please.
Two remarks:
- Even though I agree that the council should primarily be selected on having management skills I think that having decent technical and language-design skill in there too. Even if it is only because of how the outside world will view it: the council will be seen (by the outside) as being the body that has supreme power over where Python is heading. And it might be bad (note: might, depending on how things go day to day) if Python gave the impression of being run by a management committee.
- My reading of external council members is the intention is that these are people that are pretty central to Python that just happen to not have their commit bit set. So, not random outsiders, but people from within the community.
1 Like
Seeing the discussion and the obviously different views of the
council should represent, I think we need more clarity on its
purpose and intention before starting the nomination process.
When voting on PEP 8016, my understanding was that the council
will essentially replace the BDFL role. The single most important
part in this role is setting the future of where Python will be
heading and that cannot be achieved by delegating the task to
some sub committee. Management without vision won’t get us
anywhere.
We also have to stay realistic here: core developers are
not necessarily managers nor do they want to be, but they are all
passionate about Python, so given Brett’s characterization of the
council as management board, only a few core team fit his role
description.
What I’m pretty sure we can achieve is to have core developers
in the council agree on a vision and then have them delegate
the management to sub committees.
1 Like
Generally, the intent of the council is that they’ll further define the PEP process, but that ultimately the buck stops with them, much the way it did with Guido. The specifics of what exactly that means is largely left up to the council itself (again as it was with Guido).
The council could decide that they want to retain the final say and pass every decision through them as if they were just a 1:1 replacement for Guido. The council could also decide that they want to handle things by delegating to a subject matter expert for every PEP and act largely as the group who signs off on who that subject matter expert is. They could also decide to utilize project wide votes for each PEP.
They can even decide to use different processes for different PEPs (to either experiment, or perhaps different PEPs might make sense to be treated differently, for example packaging PEPs vs ones that change language syntax).
Really the key difference between 8016 and the other models, were that the other models tended to be fairly rigid in how the PEP process worked once we adopted that model because they were defining the entire process from start to finish. 8016’s approach was largely that we’d replace that ultimate decision making ability to adjust the process that Guido had, with a council, and then empower the council to sort of go from there.
This provides us with flexibility to experiment with different models for different PEPs, and to just adjust the process as time goes on without having to invoke a project wide vote of all of the core developers for a “amendment” to our “constitution”.
One great, historical, example of the kind of flexibility that I think this gives us is the area of packaging PEPS, where the idea of a sort of long standing BDFL delegation for that subject area wasn’t really a part of the PEP process, but with Guido’s nod we started doing that and it’s worked out well for us. It would have been a lot harder to do that if we had to trigger a vote amongst all of python-committers to allow that mechanism to be added.
That flexibility also makes it difficult to pin down exactly what things will look like, because ultimately it will depend on who is elected to the steering committee and how things somewhat organically evolve over time. The first couple slates (and particularly the very first one) are likely going to set the tone for exactly what role the committee takes in the over all language design, but that isn’t going to be etched in stone either, and can (and likely will) change over time with different people within the council.
In a way, 8016 is both a replacement for the BDFL role, and not. It replaces it in that they have wide power over much of Python, and the specifics are somewhat nebulous to provide flexibility over the long haul much like Guido has always had. In a way it does not replace it though, because one of the intent of the authors of 8016 is that they’ll use that power sparingly (although the flexibility inherent in the design means authorial intent doesn’t fully matter here, and it’s in the hands of the council now).
Hopefully that’s helpful?
5 Likes