IIRC, this was related to CoC violations - the PSF board can remove folks from the PSF’s membership for violations and this council has oversight over a portion of PSF-managed funds (which will shiftover from Packaging-WG). Requiring PSF membership allows for covering the edge case around that.
(AFK, this is purely off of my flawed memory of a discussion from PyCon US)
Sorry for my delayed replies to other posts, but as a brief question:
Is there any public background/context for this, e.g. the history/scale/etc? My understanding is that the SC also have control over a budget, is there a parallel to be drawn there?
My first thought is that I’d expect the SC to remove a member of the Packaging Council for severe misconduct (on advice of the Conduct Committee), rather than the PSF Board, but I want to do more background reading here. Are there public minutes or etc from the PSF discussing this matter and/or their (corporate) view?
Can someone answer this question, please? At the moment, I’m not at all clear what the status of the current vote is, and I’m holding off on voting until there’s some clarity. I’d be extremely annoyed if the vote got closed and accepted as valid before I’d voted. Even if there’s no clarification on any of the other points raised here (not least of which is whether the vote is valid now that I’ve clarified that I didn’t second the proposal to start a vote) I’ll need to decide how to cast my vote based on incomplete information - I still want to vote even in that situation.
Speaking as someone who has been involved in many voting controversies over the decades, don’t take this one too seriously. A collection of non-anonymized “+1”/“-1” comments on a mailing list (or GitHub issue), with no specified time limit, and no specified quantitative criteria for how “won” or “lost” will be decided, isn’t a “serious” vote. It’s more like an attempt to solicit more information about community sentiment.
Which has its place too. If it was intended to be materially more than just that, the process is insufficient. But as-is, the vote is running 100% for “+1” now, so community sentiment is clearly in favor. Making the process more formal would be exceedingly unlikely to change the already-obvious outcome of this poll (a more fitting name for this scheme than “vote”).
I hope you’re right, but I thought this was the PyPA vote described in the PEP and as such is the formal approval by the PyPA of this PEP. If it’s the latter, it’s far more significant than just soliciting information.
(The fact that it’s not obvious whether this is that vote is another flaw in the process, unfortunately…)
In reality, there are enough +1 votes on the github issue at this point that what I vote is essentially irrelevant (barring a last minute influx of disgruntled PyPA members voting -1). But as a matter of principle, as the current PEP delegate for packaging issues whose role is being replaced by the packaging council, I’d like my vote to be counted.
I can’t address that, alas - anyone’s guess is better than mine .
If it’s any consolation, all organizations tend to view voting in novel contexts as an afterthought. When a new context pops up, it generally takes several elections before people work out all the obvious (in hindsight, or with foresight by people who’ve “been there, done that” repeatedly before) problems with the approaches tried so far.
Entirely irrelevant, in fact - except perhaps symbolically. Which can matter too.
Won’t happen. Trust me on that .
Thoroughly understandable. To be sure we’re on the same page, this is the link I eventually found:
Assuming that’s the polll (“vote”), I think you should feel free to vote right now. If you change your mind later, I don’t see anything to stop you from deleting your original “vote” comment, and adding your new choice as a new comment. A lack of defined process cuts in all directions.
This PEP likely requires an atypical approval process, given the parties that must agree. To that end, the authors will submit this PEP … 2. for a vote on the pypa-committers mailing list, in accordance with the process outlined in PEP 609
The proposal will be put to a vote on the PyPA-Committers mailing list, over a 7-day period. Each PyPA committer can vote once, and can choose one of +1 and -1. If at least two thirds of recorded votes are +1, then the vote succeeds.
“Each PyPA committer can vote once” suggests you can’t change your vote.
Abstentions have no effect on the result:
If at least two thirds of recorded votes are +1, then the vote succeeds.
Yes, but that document also requires that a vote is seconded in order to be valid. This vote hasn’t been seconded (partly my fault, as I wasn’t sufficiently clear that I was only seconding the idea of using github to collect votes) so it’s not clear (to me at least) that the PEP 609 rules apply. Hence my questions.
Of course, someone could come along and second the motion to vote after the fact. But then, should the voting period be extended to be a week after the vote became valid as a result of being seconded? I don’t know, it’s all a bit of a mess.
And I remain concerned that we’re starting a vote while people still have significant discussion points unresolved. At the moment, I don’t see the people who have asked for clarification voting -1 on the existing proposal - like me, they seem to be abstaining in the hope that clarification comes before the voting period ends. I really don’t want to advise people to vote against the proposal - despite its flaws, I think it may well be as good as we’re going to get - but I absolutely don’t think it’s representative to have the vote get closed while people are still asking for clarification on important points.
Yes, at some point we have to say “PEP 772 as it stands is what we’re proposing. People now need to vote yes or no, further debate won’t change the proposal.” But I think we need to be very clear that’s what we’re doing - and @pradyunsg’s post simply wasn’t that clear (to me, at least, as demonstrated by the fact that I thought I was seconding one thing, and Pradyun thought I was seconding something else )
I don’t want to wreck PEP 772 by voting against it[1] or by lobbying for others to vote against it, even though I really don’t want my ability to vote on packaging issues to be tied to a PSF membership that I don’t want. But if it’s that or nothing, I’ll live with it.
I think I’ll drop this now, and vote +1 (meaning “slightly more in favour than against”, but there’s no +0.5 style nuance available). I’ve said my piece, and I think anyone who’s interested in the points that have been made has probably already responded. At this point, I’m pretty burned out on governance, and I just want it to get sorted one way or another. I don’t think that’s a great place to be, but continuing to fight won’t help. If the vote is declared invalid and a new vote started, we start from scratch anyway.
Although as I already noted, there are enough +1 votes already that I don’t think it matters in reality. ↩︎
Who are you asking to declare the vote invalid though? @pradyunsg or someone else? Or are you expecting a community consensus to form?
If the latter I do not think that will happen, if you expect someone specific I don’t think you’ve been clear enough who.
Given you seconded the proposal which initialed the vote, and have now retracted your seconding, and (I assume) have moderator rights on the GitHub repo, I wouldn’t see it as an abuse of power for you to take unilateral action and halt the vote by locking the thread and editing the post.
I guess @pradyunsg, as he initiated the vote. Or one of the other PEP 772 authors.
I don’t know if I have moderator rights - I do seem to have a “lock conversation” button, but I don’t think I can edit posts. However, I do see it as an abuse of power to do that, and it’s not something I’m willing to do.
By the way, to be clear, I didn’t “retract” my seconding - I never seconded a proposal to vote on the PEP in the first place. At best I was unclear about what I was seconding, because I’d misunderstood the purpose of the post I was responding to (it never even occurred to me that we were ready to go to a vote). The claim on the vote issue that I seconded the proposal to go to a vote is simply wrong, I’m afraid.
Part of the problem here is that to my knowledge, PEP 609 (the current PyPA governance document) doesn’t have any rules on what to do when things go wrong, so we’re in somewhat unknown territory.
This is intentionally left unspecified, and somewhat loose as well – the PEP largely does not put restrictions on the specifics of how the PC conducts itself and, this in particular, is an aspect that I don’t want this PEP to go down the rabbit hole of putting too much detail on/restrictions on.
These apologies are appreciated – it has been discouraging to get posts bringing up concerns on a proposal that has been discussed in many forums, has been up for discussion on this one (as a third round) for about a month, has gone through a PSF board vote, has had a discussion about what the voting process. In particular, since these concerns have come up after the multi-phase approval process needed here has been begun (which led to subsequent sense of urgency asking for the vote to be called off).
The mental model I have for the packaging council is that this is a group that multiple other groups with “formal” powers are delegating powers to this group – such that this group becomes useful (with the ability to override where appropriate). With respect to the SC, that’s delegating the PEP approval stamp powers.
Practically, the PC is a “sibling” to the SC, rather than “under their purview” or so (only a subset of powers come from the SC). We do have the SC serving as a governance “fallback” though, helping fill out gaps when an atypical/difficult-to-design-for situation happens.
If someone gets removed by the PSF board for CoC infractions, I don’t think an additional layer of indirection with the SC should be needed – especially since I don’t want the SC to be responsible for enforcing behaviours on this group either (eg: a PC member might not be a voter for the SC, and I personally don’t want a “you don’t vote for people who have power over you” situation).
I don’t believe this was discussed by “the PSF” as an entity. The decision to add this was made by the PEP authors. @AA-Turner What are you looking for here?
I’d like it to be in some permanent document somewhere. We made a decision that packaging PEPs are not “living documents”, and that means that having the PEP be the only place (or even the main place) someone should go to find out how to register to vote isn’t in line with our policy.
Sorry to be pedantic here, but this is very much about ensuring people don’t feel disenfranchised, or that there are obstacles in the way of them participating in packaging governance. So details matter.
To say more, I’d have to see what the actual documented process is, and try it out. I’d also need more information on what “being a PSF member” means in practical terms (Will I get unwanted emails about non-packaging PSF matters? Can I opt out of those? Can I opt out of voting in PSF elections while still maintaining my membership at a sufficient level to vote in packaging matters?) and I’d hope the document provides such information (or at least, links to it).
In general, PEPs are no longer substantially modified after they have reached the Accepted, Final, Rejected or Superseded state. … Active (Informational and Process) PEPs may be updated over time to reflect changes to development practices and other details. The precise process followed in these cases will depend on the nature and purpose of the PEP in question.
Outside packaging, other Process PEPs are occasionally updated, such as 13 for updates to the voting process and links to the current SCs, and 731 to reflect the current WG membership.
If packaging Process PEPs have a different policy, is this documented somewhere?
Good point. I don’t know. I’m not even sure that there is such a thing as a “Packaging process PEP”. (There is just one, actually - the PyPA governance PEP But it’s never to my knowledge been modified.)
My main concern was that the PEP doesn’t get the “this PEP is a historical document” banner.
Now we’re getting really meta I apologise for starting us down this rabbit hole.
There’s no specific policy I know of for packaging process PEPs, but there is a general policy (stated on https://www.pypa.io) that PyPA specifications should be hosted separately with PEPs simply documenting changes to the spec. I’m happy to accept that process PEPs are different here.
This is going way too deep though. Given that process PEPs are permanent, living documents, I’m fine with having this in the PEP. To be a bit more concrete, it could go in the Packaging Council Electors section “Responsibilities”, which at the moment assumes the reader knows far too much about PSF processes, and so would benefit from clarification for non-expert readers anyway. I’d suggest adding in there:
A link to the page you need to go to, in order to become a PSF member.
An explanation of the “community contributions” rule, with explicit mention that participating in discussions here counts as contribution.
A clear statement that it’s possible to become a PSF member solely for the purposes of being a Packaging Council Elector, with no commitment to active participation in the PSF itself.
Ideally, an explanation of the process you should go through to “opt out” of PSF matters other than packaging council related ones. The PEP currently says “PSF voting members may opt-out (annually or indefinitely) from Packaging Council elections independently of their choice to vote in PSF Board elections”, but IMO that doesn’t make it clear enough that you can opt out of PSF board elections while still participating in PC elections (assuming you can!).
(We might need some process to ensure that PEP 772 is updated if any of these PSF-controlled details get changed, but I don’t think that’s unreasonable - I wouldn’t want changes in the PSF “community contributions” rule, for example, to suddenly change who’s eligible to vote in PC elections, without the packaging council and community having a say in that matter!)
I think folks didn’t click through on the link I included, and Discourse rendering of the link made things confusing…
I’m specifically saying that we’d add an entry in the list at the end of the PEP to say that in the packaging council “operational suggestion” – to provide a document covering these details, with this suggestion living in the PEP directly and the inaugural council doing the relevant work.
IDK if you’re being pedantic – I agree with you! I’m asking if a specific way to do this is sufficient.
Do you want this before the first election? Or, would you be OK with this being available after the first election?
I’d need it before the first election as otherwise I wouldn’t know how to register to vote…
(Yes, I could probably find out some of it for myself, but likely not the stuff about opting out of PSF elections - which I suspect the PSF may not even have considered yet.)
Fair enough! I think when I’m inclined to do then is add that operational suggestion as well as write a blog post detailing this as a part of communication around this PEP.
I never like the Discourse rendering of links. It’s both too wordy, and doesn’t make it clear when you’re linking to a subsection on a page.
But just to circle back to this, I think “how to ensure you’re eligible to vote” is important enough that I’d rather it wasn’t buried in an appendix, especially not one described as “suggestions”…