Change: Instead of casting this governance discussion as a governance discussion, cast it as a standards definition discussion. (Or, split the discussion into at least two pieces, one of which is a standards definition discussion and one of which might still be a governance discussion.)
By “standards definition discussion” I mean one where a considerably reduced scope of powers is under consideration, but where the scope of applicability and relevance is expanded far beyond only the PyPA.
In particular: instead of working to define a body that sets direction for projects; work to define a body that collaborates to define standards for:
- Distribution of Python
- Packaging of Python-containing or Python-interfacing code (as PEP517, PEP518, PEP621, and others already have)
- Creating of self-contained artifacts containing Python (optionally + other) code/executables
- Compiled extension modules
- (various others; specifically avoiding an exhaustive list here)
This standards body should allow for membership by any stakeholder in Python distribution and packaging: Conda, conda-forge, Spack, Conan, Nix, CPython, [insert all the Linuxes], shiv, PyInstaller, build, Hatch, Windows, MacOS, [so many projects and types of project I’m leaving out].
It would be a big, sprawling thing, likely requiring multiple internal working groups, each focused on a specific standards/interop topical area. But I see this as unavoidable, because Python distribution and packaging is a big, sprawling, diverse thing.
(This is something of a remix of posts above by Paul Moore (one, two, three, four) and Anderson (one, two), though I’ve been thinking about it since PyCon US this year.)
Effect: Allows standards discussions to evolve and grow beyond the borders of the concerns of the PyPA project membership, including bringing in currently-walled-out users and stakeholders. These discussions could then proceed independently from any PyPA or PyPA+(C)Python governance discussions we may want to continue with.