Maintaining requests

[njsmith]

Kenneth has transferred the Requests repo to the PSF: https://github.com/psf/requests

This is a major change for the project and the Python community as a whole, and I think a positive one that a lot of us are excited about. But it leaves a lot of details to work out! So here's a thread where we can discuss what happens next, and a few questions to get us started:

Interested parties

• The Python HTTP working group, which we're still getting set up. For those who aren't aware, this was @theacodes's idea to form an umbrella to try to coordinate efforts across projects and with the PSF (though Thea, you don't seem to be a member of the org – is that intentional?). There's an overview here.

• The PSF: CC @ewdurbin

• The Requests maintainers: IIUC, right now this is basically just @nateprewitt?

Is there anyone else who should be CC'ed?

What's the goal?

I'm pretty sure that the folks who've been involved in the python-http group discussions so far are all interested in seeing Requests become a regular community-maintained open-source project, with oversight and fiscal sponsorship from the PSF, and are eager to help make that happen.

Ernest, what's the PSF's plan for handling its new project?

Nate, what are you thinking? I don't know if you were even involved in any of this discussion so far, despite being the main maintainer for the last few years...

Transfer logistics

As far as I know, the Requests project's main assets are:

• The repo and issue tracker: now held by the PSF
• The requests name on PyPI: according to PyPI's database, this is owned by @nateprewitt, Cory Benfield, and Ian Stapledon Cordasco. IIUC, Cory and Ian are actually retired from involvement with the project (which is why I haven't @'ed them). So really just Nate in practice.
• The python-requests.org domain name. Does anyone know who owns this currently? This is an actual legal asset, and one of the major purposes of the PSF is to hold onto those, so ideally that's where it would end up, but I don't know if anyone is working to make that happen...

[nateprewitt]

Hey @njsmith,

Thanks for kicking this thread off! Yeah, I believe I’m the only one left with the keys at this point. I’m hoping to finally have some more time starting mid-August to help clean up the last 6 months of backlog. Super excited to get some new faces involved with the project.

As far as assets go, I can add whomever we need to the PyPI account. We’ll probably want to work out logistics for how we’re handling maintainership going forward.

The python-requests domain is still owned and operated by Kenneth at this point unless something has changed in the last month or so.

I’m happy to be involved with Requests/the working group to whatever extent you need. Just let me know how I can help.

[njsmith]

I’m happy to be involved with Requests/the working group to whatever extent you need. Just let me know how I can help.

I think we're all trying to answer that question :-). But I sent you an invite to join the org.

[tomchristie]

This is a major change for the project and the Python community as a whole, and I think a positive one that a lot of us are excited about.

Indeed - seems like a really good step forward.

Possibly jumping the gun a bit here, but something that I think the project could be taking far better advantage of is using a sponsorship program to fund ongoing maintainance.

There are currently carbon ads in the sidebar, and BuySellAds footer ads. I think that there's a bit of an oppourtunity to replace those with a more direct ongoing-sponsorship model, in a similar way to https://fund.django-rest-framework.org/topics/funding/#corporate-plans

REST framework has had some modest success with that approach, and it'd be great to see something similar happen with requests.

[njsmith]

IMO that makes a lot of sense as a long term goal, though we're going to need to sort out the basic governance and fiscal sponsorship stuff before we can start soliciting for anything like that. (I'd say this for any project, but for requests we need to be extra careful to do everything by the book, especially now that the PSF's reputation is on the line.)

Another option that might make sense, especially in the intermediate term after we're set up to handle money responsibly but before we have a full sponsorship program: ReadTheDocs has a program where they manage the ads and split the revenue with the project.

[tomchristie]

Sure thing. In any case let's wait until the maintenance team and other basics are sorted out for the project.

[theacodes]

though Thea, you don't seem to be a member of the org – is that intentional?

Yep. I'm stepping away from most of my Python community obligations as I adjust to my new job on the Flutter Developer Relations team.

Let me know if y'all need any specific help from me, though. Good luck. 💜

[sethmlarson]

Welcome to the team @nateprewitt! We're happy to have you on board. :)

We should probably write up what we want to accomplish to get to the point where we can handle money and legal assets. What did the PyPA do to achieve this (if it's been done by them at all)?

[njsmith]

Well, we'll need an answer from @ewdurbin or others at the PSF to say what specifically they want to do. But my guess is that they'll be looking for:

• Some kind of committee to handle money/legal stuff, with a charter and a vote from the PSF board to set it up.

  For packaging, the money/legal committee is the Packaging Working Group, which you can read about here:

  https://wiki.python.org/psf/PackagingWG
  https://wiki.python.org/psf/PackagingWG/Charter

• Some kind of plan for maintaining the project and making technical decisions. This might be the same as the committee mentioned above, or might not. For packaging, the various project each have their own maintainer teams.

  Requests is in a tricky place because it's kind of a blank slate how the project will be maintained now that Kenneth is stepping back, and it's also super important and a lot of people depend on it. We don't want to hand out commit bits and then belatedly discover that everyone's got a different vision for where it should go and start fighting over it in PRs. I don't think we need like a 100 page governance document or something, but IMO it'd be a good idea to write down a few paragraphs about what our goals are and how we'll make decisions if there's an argument.

[tomchristie]

Filed an issue to try to hash out some of the basic maintenance questions... psf/requests#5149

(All stuff that seems immediately relevant, regardless of whatever longer-term intentions the PSF has)

[ericholscher]

Another option that might make sense, especially in the intermediate term after we're set up to handle money responsibly but before we have a full sponsorship program: ReadTheDocs has a program where they manage the ads and split the revenue with the project.

Wearing my RTD hat, we would definitely love to work with y'all on getting a rev share setup as a short-term step here. We are also looking at expanding our advertising program into something where we partner with a project to offer a DRF-style sponsorship program. We have been having some internal discussions on this, and would love to work with y'all to figure this out for requests. The goal would be to build a repeatable model that could be used for other projects as well going forward, with much credit to Tom & DRF for showing the way on this.

Figuring out governance is a requirement for these discussions, but I'll be following along and we're happy to help however we can.

[njsmith]

@ewdurbin Ping?

[ewdurbin]

Thank you for repinging.

As far as Working Groups go, I don't have excellent guidance for the proposed HTTP Working Group. Although I'm a member of a number of Working Groups, I have not been part of organizing the creation of one. I think a good initial step would be to send information to psf@python.org.

Organizing a Working Group around Python HTTP is an excellent first step in creating governance around requests as well as other HTTP codebases that may find a home in @psf. For now, the psf/requests projects' transfer is primarily a matter of administrative oversight (access control, permissions, repository ownership) with the expectation that the maintainership handoff has the bases covered for day to day changes.

Remaining artifacts need to be addressed one by one, which I note in Tom's issue filed at psf/requests#5149. We'll need to step through those one by one, but that issue seems like the better venue for those.