Both of you seem to be seeing this new council as fairly narrowly scoped and fairly passive (fallback decision making / pronouncements). That seems even more narrow than a PyPA-only focus, which would include topics like UX and tool development which do not fall under the PEP process.
For PEP pronouncements: I’m not sure that that’s a real pain point right now, but if so then I think either Paul or the SC can already add more folks to take on this responsibility? It doesn’t seem like we’d need a council with a voting process for that.
I understand excluding Conda from the primary scope, on the basis that it has its own repository, metadata and ecosystem. Poetry and PDM are PyPI-focused tools though, so it worries me that you’d exclude those. At that point, I’d say it’s no longer a Python packaging council focused on PyPI and related standards and tools, but rather a PyPA council. Also potentially useful, but then let’s call it that.
Re voting, I’m comfortable with PyPA members as the initial voting group, and it seems like the most pragmatic choice.
Re scope, I think from narrow to broad these are the choices for the primary scope/focus (each later one also includes the former):
- PEPs only
- PyPA and its tools/workflows
- PyPI-focused Python packaging tools/workflows
- Python packaging tools/workflows
My sense is (4) is seen as too broad, and (1) is too narrow - so the choice is between (2) and (3).
A scope can evolve over time, so maybe the even more interesting question is whether this is a mostly-passive council for decision making in the absence of consensus on some topic, or if this is a more active council that gets together regularly and aims to drive things forward in a more proactive manner. I’d personally favor the latter, with council members committing to say >=2 hrs/wk of effort, and having meetings (with each other and key projects/stakeholders), writing docs like a roadmap or maintaining a list of key priorities.
Deciding on that now may again be difficult, so maybe it can be resolved by candidates including a short statement with their candidacy that includes what they see as the scope and how they prefer the council to operate? Then voters can take that into account, and the council can take it as a signal and start operating accordingly.
If that seems fuzzy, I’d clarify that it explicitly includes at least the use of build frontends/backends to build binaries and install them directly for other packaging ecosystems. ↩︎
This can be instead of rather than on top of some other activity, it’s voluntary effort after all. To get something impactful done, it seems to me like there’s some lower bound on time investment that will be needed though. ↩︎