My only concern with this, is I think that a good thing that this council can do is elect to retire a project… and what happens then? Do those people just lose their vote? Do they become some sort of grandfathered in voter?
1 Like
Assuming the maintainers of the project haven’t asked for a project to exit, it might require a vote in that instance.
Presumably these are things the packaging council can decide and
codify in its charter once it exists. The initial question is one of
bootstrapping.
1 Like
One issue, I feel, should be discussed further are the questions around voting- who is eligible to vote and who is eligible to run for the council. From the discussion so far, we have the following options-
Option 1:
Voter: Anyone
Candidate: Anyone
Option 2:
Voter: Anyone
Candidate: Anyone involved with a packaging tool
Option 3:
Voter: Anyone
Candidate: Anyone involved with a PyPA project
Option 4:
Voter: Self-nominate as voter
Candidate: Self-nominate from voter body
Option 5:
Voter: Maintainers of PyPA projects
Candidate: Nominated by voters
Are there any other options we should consider? Are there any options that seem to be better compared to the remaining options? Which option would you personally prefer to see implemented?
2 Likes
This seems functionally the same as option 1, just with an added layer of red tape.
My gut says:
Voter: Anyone involved with a packaging tool (that has previously been recognized by PyPA in some official capacity) OR PyPA project
Candidate: Nominated by voters
I’m not sure what you’re thinking of when you say “a packaging tool (that has previously been recognized by PyPA in some official capacity)”, or how “involved with” differs from “maintainer”, but otherwise isn’t this option 5?
Option 5 is my preferred option, mainly from an administrative point of view - when setting up the voting process, we’ll need a list of eligible voters (at least, that’s how the SC voting works, and I’m assuming we will more or less follow that) and “Anyone” is impractical for defining such a list. I’d be open to some other definition of who can be a voter, based on some level of demonstrated involvement in the packaging community, but I don’t really see a good way of creating or maintaining such a list of voters.
For candidates, I think anyone should be eligible, but nomination (which can be self-nomination) by someone eligible to vote seems a reasonable way to ensure a minimal level of support for the candidate. I’d have said “anyone from the packaging community” but again that’s impossible to define precisely, so “anyone nominated by an eligible voter” serves as the best proxy for that definition that I can think of (and again, it mirrors what the SC does).
Basically, if we’re going to have a council, let’s follow the SC process as closely as is practical, simply to avoid having to tread new ground.
1 Like
If I had to choose I would definitely have chosen option 5, yeah. My sense of “involvement” includes, say, contributors who have had a pull request accepted. It might be the case that the only “recognition” PyPA offers for packaging tools is adoption as an actual PyPA project. I didn’t want to exclude the possibility of something that’s e.g. the packaging equivalent of requests in terms of notoriety.
With large open source projects I’ve been an election official on or
participated in election policy for, the most common definition of
the electorate is “anyone with a recent commit in the governed
repositories” and the most common definition of valid candidates is
“anyone” (sure you might get somebody out of the blue run for office
but the odds your project participants will vote for them is
basically nonexistent, and it’s just one more place you can avoid
being unnecessarily exclusive).
Next most common definition for electorate I’ve seen is “anyone with
approval rights on the governed repositories,” and next most common
definition for a valid candidate is “any member of the electorate.”
We have PEP 609 which defines concrete terms for groups relating to the PyPA. I think my preference would be to see the voting body be either PyPA members or PyPA contributors and anyone can be nominated by a voting member.
So that’s Option 5 with Voter replaced by one of PyPA members or PyPA contributors. (I lean slightly towards members as triage bit would allow greater participation by people doing critical work).
Regarding @dstufft’s concern relating to “how do we retire a PyPA project”, PEP 609 also covers this. I think it would be fair to retain this policy and allow the voting body as a whole to manage itself.
5 Likes
when setting up the voting process, we’ll need a list of eligible voters (at least, that’s how the SC voting works, and I’m assuming we will more or less follow that) and “Anyone” is impractical for defining such a list.
I entirely understand and agree that “anyone” is not a workable choice but I do worry that limiting voting to just PyPA maintainers is too insular. For example, it would be good (IMO) if the folks who have to live with these tools could have representation in some form. So then I’d propose something like:
Option 6:
Voter: Maintainers of PyPI “critical” projects
Candidate: Nominated by voters
This is an entirely arbitrary cutoff, suggested to comprise a larger but also clearly definable group of people.
3 Likes
I understand that concern, and I mostly agree with it. But as a “practicality beats purity” question, how precisely would we create and maintain a voter list otherwise? When you say “PyPI critical projects”, what precisely do you mean, is that definition stable (in the sense of do projects move in and out of that classification or is it static), how many voters would that imply, and consequently is the resulting voter list manageable? Also, I’d hope that all existing PyPA projects would be included in the project list, regardless of whether they are “critical”, for continuity of governance if nothing else.
I’m definitely not against a voter base that represents users as well as maintainers of packaging projects. But I don’t think it’s crucial - the SC has survived just fine with having a voter list that’s just Python core devs, and (again) I think we should follow their lead unless there’s a compelling reason not to.
Given that there are currently 4,522 projects designated as critical. It is indeed larger, but by a factor of ~100. I don’t think that’s tenable from the perspective of operating elections.
Direct membership for any user of any tool feels like it discounts the role of active maintainers of the projects and the role of a council. Maintainers tend to be aware of what’s commonly requested of the tool via issues (This is why including triager roles is a huge +1 imho), and the council itself should be mandated to have some way of staying abreast of that feedback or accepting it directly in their processes similar to PEP 13’s mandate " * Seek consensus among contributors and the core team before acting in a formal capacity,".
There’s a balance to be struck here and I don’t know that the metric of PyPI critical project is sufficiently limiting to ensure that the voting membership is active, engaged, and manageable.
5 Likes
Any PyPI or PyPA based criteria would likely exclude the members of the communities around conda, Poetry, and so on, wouldn’t it? Is that on purpose? I most likely lost track of what the council and its scope are intended to be.
1 Like
Yes, it would. IMO that’s unfortunate, but not disastrous. We’ve co-operated with the various communities around conda and Poetry for years now, albeit not always as well as we might like. I don’t think we’ll stop doing that just because of a governance detail about how the council is formed. Conversely, I’m not sure that including those communities in the voting group would make a massive difference - note that it’s perfectly possible to have members of those communities on the council, as council membership is open to anyone. If it’s of use, I’ll personally commit[1] to use my ability to nominate candidates to ensure that conda and poetry are not left unrepresented in the council nominees[2].
I don’t think so, it’s more an accidental consequence of the fact that the only really well-defined groups are “PyPA members” and “PyPA committers”.
I think we all have, to an extent 
I’m assuming that having a goal of “facilitating and improving co-operation between the PyPA and other interest groups such as Conda, Poetry or Linux distributions” would be a fairly key part of any scope. At least I certainly hope it will be!
2 Likes
An interesting aspect of this is that it almost works best if non-PyPA projects are not on the council, because then it gives them an actual entity to “negotiate” with. (You could argue the same for CPython core. Some of us core devs are pretty deeply involved and care a lot about packaging, but would we be better off being on the council? Or being able to negotiate with the council?)
Right now, nobody can speak on behalf of PyPA. At minimum, the council would provide that. And so while it feels very nice and inclusive to get council members from other projects, in some ways it’s likely counterproductive.
FWIW my suggestion regarding PyPI critical projects was specifically meant as a mechanism to include folks who would likely have a vested interest in conda and poetry, etc (just in an implicit manner). For example, as a maintainer of such a project, I can note that we have to deal with both pip and conda packages, and have opinions about them both.
I don’t really disagree with @EWDurbin that 4500 (times however many project maintainers) is likely “too big” for a voting pool. Where I do disagree, however, is that I think that only the PyPA maintainers seems way too small, for all the reasons you mention. At least, what I’d like out of “packaging council” (and what I thought was the original goal) was to help bring some consistency and uniformity (or at least better interoperability) across the wider space of Python packaging, and I don’t see how that is encouraged by excluding everyone outside the PyPA.
So I dunno, “top 100[1] PyPI critical projects” instead? My assumption here is that the largest / most-used projects will also have the most involved packaging needs.
Edit:
Right now, nobody can speak on behalf of PyPA.
Ok, sure, but then this needs a different name that reflects that narrower scope (IMO).
or whatever ↩︎
1 Like
One thing we’ve found many times over the years is that the top N projects in any space are often the most conservative. They’ve invested the time and effort to make everything work for them (*cough*numpy.distutils) and would rather that nothing change or they’ll have to do more of that work.
The next N projects probably aren’t any better, but for other reasons (smaller user base means less feedback, less interaction with users and less sense of packaging pains).
I do think “has a critical project” is a pretty good criteria for voting rights, on the assumption that the majority of people aren’t actually interested enough to take them up. But some level of active involvement in packaging projects specifically still feels better.
I don’t really disagree with this either, I just don’t know how to codify and define it in a way that doesn’t involve cherry-picking.
I would assume by the same way we have done it up until now: through PEPs and talking them through here in an open space that anyone can access and participate in.
I hope people don’t view any packaging council as a magical solution here. I personally view the council as:
- Taking the pressure off of (primarily) Paul
- Having someone help unstick us all when consensus can’t be reached
That’s it. The SC effectively does this exact same thing as we still try to make decisions based on consensus and only make “unique” calls when there’s no clear leaning one way or the other. As such, I don’t see how widening voter representation is going to drastically change any of that. As we have always done, if a project has concerns about packaging then I would hope they could come here and voice their opinion constructively. Basically the voters are the people who stand to be impacted the most by the decisions of the council as they maintain the projects that will most likely be asked to change. Comparing to the SC, people from e.g., PyPy are not explicitly brought in to vote even if our decisions impact other Python implementations. And yes we do take into consideration whether something would negatively impact PyPy when making decisions on the SC. Now swap “SC” with “packaging council” and “PyPy” with “conda, Poetry, and PDM” and you get a similar result.
Or to put it another way (depending on your views of your government), we are not electing politicians but people we know most likely already trust, so I don’t think we need to stress too much about representation in the voter base outside of PyPA projects in the name of simplicity and actually making this whole idea happen.
6 Likes
A key issue here is the actual scope of the proposed council’s actual authority, which ultimately is pronouncement of Packaging PEPs.
So for ecosystems that operate independent of PEP specifications, I am concerned that expanding the voting body too far beyond that puts us back in a similar position of dealing with varying specifications.
Perhaps expanding membership to authors/contributors to Accepted Packaging PEPs could be considered?
The PyPA is more and more “PEP first” while the broader ecosystem has made significant contributions in development and authorship of new PEPs to make use cases standardized. Focusing on participation in the PEP process for voting membership provides a mechanism to include anyone who is engaged in what the proposed council would have a definite mandate over.
1 Like