Amending PyPA Governance to permit for use of PyPA funds

Packaging
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. ↩︎

2 Likes
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.

3 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.

4 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.

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.

3 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.

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.