I found that drawing some pictures helped clarify my thinking. Maybe they'll be useful for others too:
On Thu, Aug 30, 2018 at 5:52 PM, Donald Stufft email@example.com wrote:
I’ve been kind of on and off again in my time lately, so I haven’t had much time to push this. However I would like to bring back the discussion here to Dustin’s proposal.
Besides the specific process itself, here is the basic gist of it:
- Individual projects still control themselves.
- The PyPA handles cross project decisions
- Specific topics get a Interest Area Authority delegated to them, to act as the final decision maker (e.g. BDFL-Delegate).
- Topics without an IAA, or ones where the IAA recuse themselves for whatever reason (time, conflict, whatever) fall back to voting by the PyPA committers.
- No longer using the PEP process except for actual changes to Python itself (e.g. ensurepip would still have been a PEP, PEP 440 would not).
Basically I think this is overall a good thing for us. The basic structure is largely similar to what we had setup under the PEP process, except instead of authority being delegated by the BDFL, it’s delegated by us, the PyPA. Ultimately I think this is better, because we’re the folks investing the most time and effort into this space. Particularly with python-dev grappling with what the future decision making process is for python-dev (which is going to change the PEP process).
I think it would be confusing for us to have a process strictly for governance stuff, and then another process for non PEP-worthy changes, but that still are cross team, and then the PEP process itself. It’s a lot easier and simpler if we just use the same process for it all. Obviously we’ll still have the PEP process for changes to the interpreter or standard library, but that’s a pretty easy clear line to draw between “third party packaging stuff via the PyPA” and “First party standard library / interpreter”.
I know that Paul was concerned about his role, and ultimately I think that with the changes Dustin has made, that role is preserved as an Interest Area Authority (assuming the PyPA votes to keep him in that role! Which I see no reason why we wouldn’t). However it gives us a better answer for what to do if Paul steps down, or feels the need to recuse himself for one reason or another (or the extremely unlikely situation that an IAA starts making harmful decisions).
I also know that Nick has a few concerns with accessibility to the wider community, which I believe I addressed in the other email thread, but to reiterate, I don’t think that the wider community cares one way or another, and I think the biggest benefit comes from being able to tailor this process to what we need. So we can adjust it as we go along to what makes the most sense to us, without having to go to python-dev and get them to change their process to fit our needs.
All in all, I’m a big fan of the proposal, and I think it is the right direction for us to move in. _______________________________________________ PyPA-Committers mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mm3/mailman3/lists/pypa-committers.python.org/