For me, the major thing I’m wary of in the governance proposals is anything that increases the burdens on regular core developers beyond what I think is reasonable to request of a volunteer participating in their own time. A lot of that view is purely selfish (since I fall into that category these days, whereas I got a fair bit of paid upstream time to spend as I wished while working for Red Hat), but part of it is also about avoiding raising the barriers to core development so high that the only way to climb them is to be paid to contribute.
So for me, that rules out PEP 8012 (primarily due to the weird clause where folks have to seek permission from other core devs in order to withdraw from an interest area, but the PEP as a whole just reads as “more work for core devs than I’m personally prepared to take on” to me, even if it isn’t intended that way).
It also rules out PEP 8014, since that pushes a lot more decision making down on to votes of the entire core development team, which strikes me as worryingly similar to the original “everyone votes on everything” model used in the PSF that was ultimately replaced by the formal PSF Working Group model (where folks could opt in to voting for the things they cared about, and everyone else was only asked to vote in the annual Board elections and for changes to the by-laws).
For the rest of the proposals, I don’t think that much would actually change in the day to day experience of a core developer, so they all manage to pass that hurdle.
PEPs 8016 (Steering Council) and 8015 (Python Community) both feel like they’re staking out different positions on a Steering Council model, and my preference between them is for 8016, as I think it gets the balance between over- and underspecification right, whereas 8015 attempts to specify things that don’t need to be covered by this governance vote (like how we interact with the PSF’s Code of Conduct committee, which I think is independent of technical governance).
PEP 8011 is actually my favourite proposal, as I think it would end up being pretty similar to a PEP-8016-style steering council in practice, but with one key difference: the use of ticket voting for council elections (such that you vote for an entire council at once), rather than electing individual council members. That’s a really interesting idea to me, since it allows for deliberate construction of tickets that have particular properties (e.g. at least one newer core dev, at least one veteran core dev, at least one core developer that’s also active in the Scientific Python community, etc), such that folks can vote for the ticket that they feel offers the most appropriately balanced set of perspectives, rather than voting for individuals and then hoping the end result will still represent a reasonably broad cross-section of Python community perspectives. It also provides an interesting way of managing the corporate influence question, as I suspect folks would be wary of voting for tickets where even two of the candidates worked for the same organisation, let alone all 3 of them.
I think PEP 8013 is an interesting idea, but I also think we already have a relatively independent oversight body in the form of the PSF Board, so I don’t think we need another one at the technical steering council level. (Yes, the Board stay out of technical decision making, but the control they have over resources and infrastructure gives them significant leverage to intervene if our collective management of the core development process were ever to get so far out of whack that they felt obliged to step in)
Finally, while I think it’s good that PEP 8010 is an available option so folks can vote for perpetuating the status quo if they really want to, I think it would be a genuinely missed opportunity to switch to something more sustainable if we went that way. I don’t know yet if I’ll rank it below “Further discussion”, but I might 