[withdrawn] Amending PyPA Governance to permit for use of PyPA funds

Packaging Coordination
1

Hello all.

(If you don’t know who I am. I’ve been a committer of the pip project since 2025 and a PyPA member for even longer through bandersnatch.)

PyPA is a fiscal sponsoree of the Python Software Foundation. This enables the PyPA to collect donations through the PSF. However, even with PEP 609 accepted, there is no established process to allow the PyPA to use any of its funds.[1]

Over the years, the PyPA has collected funds from GitHub Sponsors, Tidelift, and thanks.dev. Some of the Tidelift revenue is routed to the individual project maintainers as per existing agreements, but otherwise, our funds are mostly sitting unused.

(There are PyPA fiscal statements available, but I’m not sure if I can share those publicly?[2] If you’re a PyPA member and curious, reach out and I can provide a link.)

For context, the pip project is exploring the possibility to using PyPA funds to sponsor part-time contract development on pip.[3] For this to be even administratively possible though, we need a mechanism for the PyPA to vote on whether to use its own money.

I’ve thus drafted an amendment to PEP 609 that allows for votes on the use of PyPA funds. It’s worth noting that under the fiscal sponsorship agreement, all disbursements are subject to final approval by the PSF.

The main thing I’ve left out are more specific details on how the funding is adminstrated after a funding vote succeeds. The problem is that, AFAIK, no one has seeked PyPA funding since the initial agreements, so I (and we collectively, probably) don’t know what is the exact process. I am hoping to document this if/after the pip’s proposal is approved.

I’ve already ran this language past @dustin who is the legal official between the PyPA and the PSF (and would be involved in approving any disbursement of PyPA funds). Since this is the first major amendment to PyPA Governance since the adoption of PEP 609, I thought I’d raise this for discussion before putting this amendment to a formal PyPA-committer vote.

The proposed plaintext changes are included below. There is also a rendered preview available if that is easier to read:

diff --git a/peps/pep-0609.rst b/peps/pep-0609.rst
index df53a563..b82642a0 100644
--- a/peps/pep-0609.rst
+++ b/peps/pep-0609.rst
@@ -71,6 +71,8 @@ Goals
 The following section formalizes the goals (and non-goals) of the PyPA
 and this governance model.
 
+.. _`PyPA's goals`:
+
 Goals of the PyPA
 -----------------
 
@@ -216,6 +218,33 @@ Removal of a project from PyPA
 
 Proposing the removal of a project in the PyPA organization.
 
+Approval for disbursement of PyPA funds
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Proposing the use of PyPA funds to pay for project development,
+maintenance, or any other activity that advances the :ref:`PyPA's goals`.
+
+Proposals for funds must, at the bare minimum, include:
+
+- A specific dollar amount, either as a fixed sum or as an ongoing
+  expense
+- A clear rationale for why PyPA funding is being sought out and
+  and how this aligns with the PyPA's stated goals
+- An overview of how the funds are going to be spent
+- Evidence of support from committers of the PyPA project(s) seeking
+  funding
+
+It is recommended that PyPA members connect with PSF Accounting before
+putting forward a funding proposal. They can provide information on:
+
+- PyPA's current balance
+- The legal requirements before funds can be disbursed
+
+As the PyPA is a fiscal sponsoree of the Python Software Foundation,
+PyPA's funds are owned and managed by the PSF. All expenses are
+ultimately subject to final approval by the PSF, in accordance to PyPA's
+fiscal sponsorship agreement.
+
 Updates to the Governance/Specification Processes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -253,6 +282,10 @@ incidents involving their projects, PyPA members are expected to
 report those incidents up to `the PSF Conduct WG`_, for recording
 purposes and for potential assistance.
 
+History of amendments
+=====================
+
+* 2026-03-23: Permit committer votes for the use of PyPA funds

  1. I’ve been told that this language is missing from PEP 609 due to an oversight / the fact that the PyPA didn’t have significant funds while PEP 609 was being voted on. ↩︎

  2. It’s probably fine, but I don’t need to get myself in trouble unnecessarily :slight_smile: ↩︎

  3. I don’t want to share it too much publicly since it’s still very much a draft, but the hope is bring it to a vote in the near-term future. ↩︎

3 Likes
PEP 772: Packaging Council governance process (Round 3)
PEP 772: Packaging Council governance process (Round 3)
2

I think it’d be good to get PEP 772 over the line and the first Packaging Council seated, this looks exactly the sort of thing they should oversee.

7 Likes
3

Does it seem like we’re close to that? I agree that it would be great to get this done, and that this should be the responsibility of that council, but I wouldn’t want it to block the pip team from using the funds for development in the short term if it takes a while, especially if the premise of enabling the PyPA to use its own funds is uncontroversial otherwise.

5 Likes
4

I’d like there to be a packaging council in place for this, but I don’t know if that’s one month away or five years away. And I don’t think we should block being able to distribute funds for valid work on an unknown timeline. Unless anyone has a concrete update on this?

1 Like
5

Last I heard:

6

Yeah, I agree. IMO it is fine to go through with the proposed change for now, allowing work to start.

Waiting for the PEP alone isn’t enough without expanding the scope, which would only delay it even further.

Having the PSF in charge of authorizing the usage of funds makes sense. Moving the responsibility to the Packaging Council would raise a set of issues regarding conflicts of interest, which we would need to figure out before putting this proposal into effect. Even after reaching a concensus on the rules, we’d probably still want the PSF as a final arbiter anyway, to overview enforcement.

Managing funds is something the PSF board is used to doing already, so I’d imagine they’re even better equiped to do until the Packaging Council creates its own processes.

All that seems still a long while away. I trust the PSF board to take the community feedback into account, and to manage the PyPA books responsibly until we are able to take over. I wouldn’t want to block important work until all these pieces fall into place.

1 Like
7

Agreed. +1 from me on the proposed change to the existing rules. Even after the packaging council proposal is approved, there will still be work to do to hold elections, form the council, set up basic processes, etc. I don’t think we should hold up useful work while all that goes on.

And without giving too much away about the proposed work on pip, it’s somewhat time dependent, so that waiting for the packaging council could easily lose us the opportunity to do the work at all.

6 Likes
8

Then this approach definitely seems the practical thing to do :+1:

9

+1 from me as well on the proposed changes to the existing rules. I think the timeline for the Packaging Council is too much of an unknown at this point that this seems like a reasonable approach until we have the PC in place.

10

Sorry to sidetrack a bit, but is there a best place to keep an eye out for the announcement/discussion of whatever this project is? I’d assume either right here in the DPO packaging category or on pip’s GitHub issues.

The mystery has piqued my interest

11

I’m not sure this should be an amendment. Generally speaking we only amend these proposals when it’s required to add some kind of clarification or fix to it. Fundamental extension to the model, such as this one, are generally dond through new proposals.

1 Like
12

I can write a new PEP that extends PEP 609 (or replaces it? not sure how this would work procedurally), but I will need a PEP sponsor in that case. The process will be the same, however, since the changing PyPA governance is governed by PEP 609:

A PyPA member can put forward a proposal and call for a vote on a public PyPA communication channel. A PyPA committer vote is triggered when a PyPA committer (not the proposer) seconds the proposal.

PyPA committer votes are required for, and limited to, the following kinds of proposals:

[…]
Proposing changes to how the PyPA operates, including but not limited to changes to its specification and governance processes, and this PEP.

So this will require a PyPA committer vote and probably approval by the SC since I don’t think this quite falls under the current standing packaging delegations.

13

If the consensus is that a PEP is needed I’ll happily sponsor it. But personally, I’m not sure it does need a PEP. According to PEP 609 PyPA committer votes are the mechanism for updates to the governance/specification process. So IMO, publishing the proposed change here and following up with a PyPA committer vote is perfectly acceptable.

6 Likes
14

I honestly don’t feel like I have enough influence/presence/authority to have any say in whether a whole PEP is needed. I will follow whatever the general consensus is. I’d prefer not having to write a whole new PEP, but if people feel like it’s important, I will write one.

In the meanwhile, I’m going to send an email to PyPA-committers to bring attention to this thread. This will be NOT be the formal PyPA committer vote, just seeking more eyeballs on this proposal.

15

I’m still honestly not sure if the proposal will ever come to fruition (as evidenced by the logistical and administrative hurdles, including this one), but sure, it can be announced on DPO if approved. You’ll also find out when it goes to a formal PyPA-committer vote (if it ever happens).

The mystique is explicitly because I don’t want to make promises or get people excited for nothing. You should consider the proposal dead in the water until the hurdles have been cleared :slightly_smiling_face:

1 Like
16

Just a point of clarification: while the PyPA is a fiscal sponsoree of the PSF, and the PSF does exert some oversight on how funds are used, this is mostly from an accounting/compliance perspective. The sponsorees have a high degree of autonomy in determining how they use their funds, and the PSF board does not vote on individual proposals to do so.

Currently I think this responsibility should lie on PyPA-committers, and post-PEP 609 it should be the council. However, I think the same conflicts of interest remain here regardless, so @ichard26 the proposed amendment to the PEP should probably address this (i.e., by requiring potential recipients of funding to abstain from the vote).

6 Likes
17

Agreed! While other committers of the project(s) seeking funding must support the proposal, they should be excluded from the PyPA-committer vote as it would be a conflict of interest. I will update this in a future revision which will come tomorrow or Wednesday, once there has been some time for more discussion.

Edit: or do we want just to exclude recipients of funding? Like if a project desires to contract a non-PyPA member, should the project committers be able to vote? I feel like if a funding proposal is being brought forward by a project, the project team should already have consensus approving the proposal, thus they don’t need to included in the vote. Including them would unfairly tip the vote in the project’s favour, which is undesirable since the consequence is ultimately PyPA-wide as it’d be drawing from the PyPA’s funds as a collective.

Thinking about it some more, we may want to add language stating that if any relevant project committers oppose the funding proposal, then the proposal shall automatically fail and may not be voted on

1 Like
18

For the record, Dustin has reached out to the PSF folks to ask whether PyPA’s financial statements can be shared freely to the public. If they give me the go-ahead, I’ll provide an update on PyPA’s financials. However, I will note that when I last talked to the PSF, they were behind on the PyPA books, so the latest numbers will likely be from early 2025.

19

Another update, PEP 772 has been approved by the PSF Board. The next step is a PyPA vote.

So, assuming that PEP 772 doesn’t get derailed again, it seems probable it will achieve final approval in the same timeframe of our draft pip proposal.

As Paul has mentioned earlier, waiting for the inaugural Packaging Council to be elected and establish working agreements with the PyPA will render pip’s proposal infeasible due to scheduling. The current text of PEP 772 purposefully excludes any specific language indicating the governance or technical relationship between the Packaging Council and the PyPA. This is particularly problematic since once approved, it will supersede PEP 609, leaving us in a temporary state without any process to vote on any PyPA-level activity, including any funding votes.[1]

This leaves this proposal in an awkward state. I would like to push this forward for pip’s sake, but I will admit that spending money while our governance may or may not be changing is a bit sketchy.

I would propose an alternative solution of doing an one-off PyPA committer vote to approve funding for pip’s specific proposal, but this is strictly prohibited by the current language of PEP 609, so this is not an option, unfortunately.

Any thoughts? Would people be comfortable with this amendment with the understanding that it will likely be only invoked once for pip’s proposal? I’d like to make this happen, but the timing is awkward.

  1. In practice, it’s possible that PEP 609 procedures (e.g., approving the addition of a project to the PyPA organisation) will be followed in the weird transition timeframe between PEP 772 final approval and the adoption of formal working procedures between the PC and the PyPA, but I’m honestly not sure. ↩︎

1 Like
20

+1 from me, my tidelift for flit contribution goes to PyPA – for both the project and pep amendment.

I would suggest leaving the door open to appoint a small group of trustees any whom can validate usage of funds under a certain small amount (say $500 USD one time expense, $20/monthly expense) unless it’s for their own work. This could be useful for something like paying for extra GitHub action, or any other tools that might be useful on a case by cases basis.

1 Like