Project maintainence 

Given that `requests` has now moved under @psf ownership (❤️), it'd be good to have some clarification around the project maintenance.

On the assumption that Kenneth is fully handing over management for the project, something that needs addressing is ensuring that whoever is on the maintenance team is empowered to take on the missing leadership role. I'd assume @nateprewitt is stepping into this (which would be great) but it's a bit ambiguous from the outside.

* Who is the maintenance team for `requests` now? I guess the "Keepers of the Crystals" docs need updating?
* I think the sidebar Twitter links and "Other Projects" can probably get dropped now that this is a PSF project?
* The carbon ads, footer ads, and donate button probably aren't the right thing to have anymore? I'd love to see  a requests sponsorship program, with sidebar ads helping fund the PSF, who could then in turn potentially handle a part-time maintenance contracts against requests. Probably needs a bit of thinking about. I'd be happy to be involved in helping setup the technical side of this, if required.
* It's not clear what should happen to the "Requests III" call-out. The *substantive* work on supporting both async+sync in the same codebase, and of adding HTTP/2 support have all been in other projects. The `httpx` project is now a good chunk of the way towards meeting the design criteria of "Requests III". For the meantime I think it'd probably be reasonable for the callout to simply drop down to "Requests 2.x is officially in maintenance-mode only. This means we only respond to CVE-level tickets."?
* I guess the footer could now read "A Kenneth Reitz Project, maintained by Python Software Foundation" or something similar?
* Is there anything else the PSF / the maintenance team needs to provide guidance on at this point in time?

> On the assumption that Kenneth is fully handing over management for the project, something that needs addressing is ensuring that whoever is on the maintenance team is empowered to take on the missing leadership role. I'd assume @nateprewitt is stepping into this (which would be great) but it's a bit ambiguous from the outside.

My understanding is that @nateprewitt has assumed the role of primary maintainer and has Administrative privileges on the repository. Though @kennethreitz still retains Admin access to the repository for the time being.
 
> * Who is the maintenance team for `requests` now? I guess the "Keepers of the Crystals" docs need updating?

I believe that should be proposed in a Pull Request. Though I note that it's not clear if the read the docs project has been updated to be attached to this repository. @kennethreitz could you add `ewdurbin` on readthedocs.org to the project that hosts requests documentation? I'll get the build pipeline wired back up. 

> * I think the sidebar Twitter links and "Other Projects" can probably get dropped now that this is a PSF project?

Seems reasonable, but I'm not a decision maker on that.

> * The carbon ads, footer ads, and donate button probably aren't the right thing to have anymore? I'd love to see  a requests sponsorship program, with sidebar ads helping fund the PSF, who could then in turn potentially handle a part-time maintenance contracts against requests. Probably needs a bit of thinking about. I'd be happy to be involved in helping setup the technical side of this, if required.

One request that was made was that the ads are left as is for the time being. I'll allow @kennethreitz to elaborate if he chooses.

> * It's not clear what should happen to the "Requests III" call-out. The _substantive_ work on supporting both async+sync in the same codebase, and of adding HTTP/2 support have all been in other projects. The `httpx` project is now a good chunk of the way towards meeting the design criteria of "Requests III". For the meantime I think it'd probably be reasonable for the callout to simply drop down to "Requests 2.x is officially in maintenance-mode only. This means we only respond to CVE-level tickets."?

This is for the maintainers of requests to decide.

> * I guess the footer could now read "A Kenneth Reitz Project, maintained by Python Software Foundation" or something similar?

The PSF is not acting in a maintainership role for the project, though the discussion referenced above could lead to such a thing if the proposed PSF HTTP Working Group existed to do so. We are however providing administrative backstopping and infrastructure support as needed to projects hosted in @psf. 

> * Is there anything else the PSF / the maintenance team needs to provide guidance on at this point in time?

Please just ask! Thanks for patience in me getting back to this issue.

this wasn't a "relinquisment" of anything on my end, just a movement of the project's "home". No intellectual property has been re–assigned (as of yet). 

Changes to the website can occur over time, but that's completely tangential to this move, in my opinion. Ads can't go away until I find myself a new gig :) I'd like to remove them, but they're literally my sole source of income at the moment.

Removing "other projects" seems strange to me — but it think it's appropriate to shift it to point to Requests-HTML and Black (the other projects hosted by `/psf`).

Comment from the peanut gallery:

> this wasn't a "relinquisment" of anything on my end, just a movement of the project's "home". No intellectual property has been re–assigned (as of yet).

but, if I understand correctly, [the reason to find a new home for the projects was](https://github.com/not-kennethreitz/team/issues/21#issue-469361786)

> I want to be able to still make contributions to them, but no longer be considered the "owner" or "arbiter" or "BDFL" of these repositories.

And also:

> I will select you (or your organization) to maintain the project if you have a standing history of contributing to open source software, show enthusiasm / meager eagerness to learn, or have an interest in keeping the given project alive.

but:

> The PSF is not acting in a maintainership role for the project, though the discussion referenced above could lead to such a thing if the proposed PSF HTTP Working Group existed to do so.

(which is something that [Nick Coghlan already anticipated](https://github.com/not-kennethreitz/team/issues/21#issuecomment-513033517))

Perhaps it's only my impression but I'd say that, for outside observers, this thread/situation is a bit difficult to understand. If, "in the spirit of transparency", anybody wants to clarify the next steps, especially if the project is looking for new (co) maintainers, and also for readers trying to follow on the actions of the PSF, it would be much appreciated.

Hi @Juanlu001,

I’ll chime in with some thoughts. We’ve had the project in maintenance-only mode for most of the year due to changes in maintainers and my limited availability due to work constraints.

We had a similar conversation in the http working group about the future of the project, which prompted Tom to open this thread.

My understanding is the psf is an umbrella to house Requests, but will not be providing support. I’ll have time to more actively maintain the project again in the next week or two. At that point I’d like to start working through the issue backlog since January.

For the future of the project, I’d personally welcome a couple additional maintainers, but think we should organize that through something like the http working group. We would benefit from some governance and vision alignment on the future of the project alongside other new http infrastructure projects.

For immediate steps, we need to get the test suite working properly again. Once we have things stable we can start looking at releasing versions with bug fixes and minor feature tweaks at a more stable cadence.

Edit: I’m going to reopen because there are still some logistics that need to be worked out for the project going forward.

To be clear — I do intend to reassign IP, at which point this will be an official "handoff". Those discussions have yet to occur, though.

Everything @nateprewitt says is :sparkles: :cake: :sparkles: :)

Given #5199, I think it'd be nice to have this issue sorted, have there been any updates regarding how the project will be maintained from now on @nateprewitt?

@kennethreitz, you don't need to transfer your IP in order to hand over maintenance to PSF, it's perfectly fine to list the original author's copyright notice in the license, but for a new team to continue managing the project.

Right now it appears there is a pressing need to consider disabling direct commits to the master branch, and to turn on mandatory reviews for pull requests.

The commit history is frightening honestly.  @kennethreitz Why do you commit directly to master (instead of in branches) and without squashing your commits with meaningful commit messages?  Having pages and pages of "Update README" commits is incredibly bad practice.

@fgimian I don't know if this was discussed at all here, but I think ideally nobody in a project should have permissions to commit directly to master. But getting the project maintenance direction in order first is more important in my opinion.

@dessant Presumably @kennethreitz is the creator and owner of the the Requests wordmark and the HTTP for Humans™ common-law claimed trademark, which are not covered by a software license, and possibly other claimed trademarks, logos, etc. As these are part of the identity of the project itself, I would imagine these are what he may be referring to. For a project that is not covered by a CLA, i.e. copyright is not assigned to one central organization but each contributor retains their own, if he chooses to transfer his copyright ownership to the PSF it naturally would only transfer that of his contributions, which is of limited (though not zero) effect.

Actually, with regard to @kennethreitz transferring copyright, it may be already effectively accomplished, depending on what [this requests3 commit](https://github.com/kennethreitz/requests3/commit/01b4861f19625791afba02d6d8146a26f53a8d8d) was intended to mean legally, which is not clear from either the content of the commit itself or the 3 character commit message.

If it constitutes merely a change in the license of requests3 for future contributions, then has no practical effect (other than breaching the code's own license either way) since there have been no substantive commits to the repo since it was pushed, and thus entire work is still licensed Apache 2.0. Alternatively, if was intended to relicense all of @kennethreitz 's contributions up to that point under the license as well, those contributions are now in the public domain and _everyone_ owns it, including the PSF; there are no rights remaining that can be transferred other than the aforementioned trademarks.

@CAM-Gerlach Thanks for sharing, I believe that's important, and maybe it should be an issue on it's own, in regards to this issue "Project maintenance", I don't think it's very important though. 

Can any maintainer push for this repo to have a release manager/release plan or anything similar? I'd love to help out, but I haven't contributed to this project at all, although given how widely used it is, we should get it sorted.

Forgive me if this work has been happening but I didn't see, here are the things that need to happen collected from this Issue:

- @nateprewitt "For immediate steps, we need to get the test suite working properly again."
- @nateprewitt "For the future of the project, I’d personally welcome a couple additional maintainers"
- @dessant "Right now it appears there is a pressing need to consider disabling direct commits to the master branch, and to turn on mandatory reviews for pull requests."

Since all questions/suggestions by @tomchristie have been answered/corrected, should we create additional issues from the points above and close this issue?

For what it's worth, it looks like Tidelift would be able to [fund requests maintainers with $417/month](https://tidelift.com/lifter/search/pypi/requests). It [works well for urllib3](https://medium.com/@shazow/open-sourcing-urllib3s-finances-e183740fcba7), so it might be worth a try?

@LuRsT Sorry for going off topic; I actually subsequently created psf/requests#5262 about the bigger implications of that very issue. Thanks.

Not sure if you're looking for funding suggestions for maintainer time, but [OpenCollective ](https://opencollective.com/spyder) worked well for us on the Spyder team to easily crowdfund a $7500 yearly maintenance budget from mostly just regular users with minimal promotion (on top of grants and paid developer time), both orgs/companies can sponsor you and the PSF can be designated as the fiscal host. It also enables better transparency by documenting each expense when money is withdrawn, so donors know when, why and how much money is being spent (which I recall was a major critique of past Requests fundraising campaigns).