I agree that many issues are still unresolved.
This is something that had been nagging at me as well. Lucky for us, I don’t think anyone’s going to try to game the system by suddenly giving commit privs to a bunch of people to stuff the ballot box. But it still seems like some distortions could arise. In particular it could mean that projects that are important to the packaging ecosystem, but are maintained by a small, overworked team, could wind up with less voice than might be warranted.
This gets at what I see as the crux of the issue, which is: who is this packaging council for and what substantive actions will it take? In my mind I have two possible answers to this.
One possibility is that the packaging council is for management of packaging projects. In this case the question of “imposing decisions” becomes very relevant. I’m skeptical that such imposition will be very successful. So in this case it’s unclear to me what meaningful actions the PyPC might take. Maybe it can approve or reject packaging PEPs, but it can’t make anyone follow them.
The other possibility is that the packaging council is for messaging to Python users. In this case the council’s main task is not to manage the projects themselves, but rather to distill the work on those projects into documentation and recommendations that helps users navigate the landscape of tools. My perception is that this also could be fraught, both because there may be reluctance to “pick winners and losers” and because, even if such reluctance could be overcome, it’s unclear there’s consensus on what to recommend.
However, it at least seems in the realm of possibility to me that a packaging council could get to a point where it would release a document that says “Tools X, Y and Z exist to do such-and-such. We recommend X for the following reasons. Here is a guide on how to use it. Watch this space for future updates.” At any rate it seems more plausible than “Tools X, Y and Z exist to do such-and-such. The way X does it seems to be the best. Therefore, we’re telling Y and Z to start doing it that way.”
So the second view (namely, PyPC is for user-directed messaging) seems more doable to me. And under that view the council’s main task would be to create such documentation and make clear recommendations (which might include, for instance, saying “We don’t recommend Tool Z because we standardized on PEP 12345 and Tool Z has not adopted that”).
Because of that, I’m uncertain as to the practical impact of the sections of the PEP about liaising with or managing tools, requiring implementations to do this or that, etc. In the end, anyone maintaining a tool who doesn’t like what the PyPC says can just ignore the PyPC, fork the project if necessary, and do whatever they want. The only real power the council would have is to say “This project is officially recommended and that one isn’t.” So maybe that should be foregrounded more in the PEP.