I agree that this feels like the wrong choice to me (and I strongly agree with all of the points @AA-Turner makes here). Personally, I’m not a PSF member and have never had any interest in becoming one. Sure, it’s easy for me to do so, because I certainly spend 60 hours/year on volunteer work, but I’ve no interest in being a PSF member for any reason other than to vote in the packaging council elections.
Furthermore, I’m uncomfortable that PSF members who have no direct interest in packaging can vote. While most almost certainly won’t, I’m concerned that some might (either from a sense that it’s something they “should” do, or because they have some type of single-issue interest). We currently have a very active and engaged packaging community, and this decision risks, in my view, diluting the impact that community has on the governance of the packaging ecosystem.
Certainly I can see the argument that there’s no easy way to capture “the packaging community” in a straightforward way. But is that a reason to pick a flawed approach? This is arguably the single biggest change to how the packaging ecosystem is governed, and I think we owe it to the community to do it right.
My preferred option would be to create a specific packaging voters list. It could be seeded with the people with commit access to PyPA projects (which isn’t precisely the same as the pypa-committers list, so maybe we need to merge the two). And in addition, we could allow people to request that they be added to that list - doing so would be no more problematic than the existing PSF “self declaration” process. The numbers would be relatively small, so if we added a manual review process to verify requests and the initial seed group, that seems reasonable. I’d be willing to help create that initial voter list. I know something along these lines was discussed previously, and dismissed as being a lot of work, and having the potential to miss important contributors, but I’m not convinced it’s so much worse than the PSF membership approach (it trades more up front effort for a more focused list - which is the right trade off IMO).
I’m sorry that this is only coming up now, but honestly, I hadn’t realised that we were as close as we seem to be to the point where this happens. It’s quite different from the normal packaging PEP process, because of the voting mechanism.
By the way, some specific questions on the voting process:
- How long is the voting period? I’m concerned that if there’s a deadline, there’s pressure on this discussion to reach a conclusion ASAP, just to meet that deadline. There’s no mention in the issue of the voting period.
- Can people change their votes? Given that we’re asking significant questions here, what happens to people who have already voted and whose views may be swayed by the comments made here?
- How will people who haven’t voted when the voting period closes be counted? Clearly there are a number of people (myself included) who have strong opinions but don’t feel ready to vote yet. So treating them as having abstained seems wrong.
I’ll note that when I seconded the vote, I was really only agreeing to the idea that we handle voting via a github issue. I wasn’t saying “let’s go ahead right now”. And in particular, I don’t think that we’re ready to initiate the PEP 609 process of a week to vote, with a 2/3 majority on a simple yes/no question. I apologise for misunderstanding what you were asking for @pradyunsg. I’ll update my post seconding the proposal to make that clear, and add a new post in the same thread pointing to that update. If that means the current vote needs to be abandoned and restarted, then I apologise for the wasted effort.