How can we make PSA more responsive towards issues/PR/new versions

[atodorov]

Highlighted in #428, but I think this has been raised up before, many community members are worried that PSA appears to have only 1 active maintainer, namely @omab who is the original author and he appears unresponsive for periods at a time.

At the same time pull requests are left open without code review or merge for extended periods of time and sometimes timing is critical. The referenced PR is about GitHub API deprecation which has a deadline later this year.

Some folks have expressed the desire to become co-maintainers, myself included, however there are many other options. I am opening this issue to prevent hijacking the conversation in other threads and as an attempt to figure out how the community feels.

Please use emojies (top-right corner) to react on proposed solutions instead of +1/me too comments.

If your ideal solution isn't listed make a new comment to describe it.

[atodorov]

Become co-maintainer (with merge access and possibly push access to PyPI).
Vote 👍 if you volunteer to this.

[atodorov]

Help review PRs, contribute tests and fix issues without merge access/push access, e.g. help whenever you can but don't fully commit to PSA.

Vote 👍 if you volunteer to this.

[atodorov]

Donate financially via OpenCollect

Vote 👍 if you commit to $5 or more per month

NOTE: not all donation options may be available to everyone incl the beneficient

[atodorov]

Pay for subscription support, e.g. +1 devel priority for every subscriber or some fixed time period (e.g. 2hrs/week) in which maintainers agree to work on the project.

Vote 👍 if you commit to $15 or more/mo

[atodorov]

Fork the project and continue independently.

FTR I think this is a terrible idea b/c it will polarize the community and people who are willing to help but it is a possibility nonetheless.

[timabbott]

I suppose we should add the other option I've seen work: Create a temporary, friendly fork and maybe pypi listing (social-core-temp?) to resolve near-term issues like #370 and #428 with the plan of re-integrating with the main project as soon as @omab is able to be active or add maintainers.

[timabbott]

I run Zulip, which like just about every Python webapp has a strong dependency on python-social-auth for authentication. And I think the fact that this project hasn't moved in 6 months is a critical issue for all of the projects and businesses that depend on it. There are multiple issues with deadlines without any activity (#370, #428), and given the sole maintainer @omab is out of contact, I don't think we can be confident in the project's current ability to react to a potential future security issue or do other time-sensitive work.

I think it's really important to emphasize that @omab is not to blame here; he created this amazing project that's an important dependency for the Python ecosystem, with good automated tests and everything. I really really appreciate what he's done, and it has saved me and thousands of other developers countless hours of time that would have been spent duplicating tricky, security-sensitive work. We just need to either find a way for @omab to have more time for this project and/or to add more maintainers.

In terms of specific help to offer, the Zulip community is happy to help to the extent we can, including but not limited to:

• Cash (though I'm sure other businesses have a lot more to spend than the Zulip, which is a bootstrapped 100% FOSS company, but I'm happy to be one of the first to say they'll gladly pitch in).
• Support from Zulip folks who've worked with python-social-auth in the past (I have no free time personally but @mateuszmandera, who maintains Zulip's authentication system, should be able to help at least with getting the project back on track).
• Helping find volunteers interested in becoming maintainers for this critical part of the Python ecosystem.
• Helping with organizing, evaluating candidate maintainers, etc.

I think the project is a great state technically; I don't think there are major changes that need to happen other than making sure there's a team of competent folks who have the free time and energy to tend it.

I encourage everyone at a business using python-social-auth who sees this message to subscribe to this thread so that they can follow the discussion here (and to talk to their manager to get permission to upvote if their business can pitch in). Hopefully, we'll be able to get in touch with @omab and work out a plan for how to add new maintainers to this project in a way that he's happy with.

[mateuszmandera]

Yup, I've worked a bunch using python-social-auth in the Zulip codebase and I'd be happy to help out with maintenance. I'd be able to dedicate a bigger chunk of time at the beginning, to help sort through the backlog - afterwards I won't have as much time, but committing enough to review PRs and do some necessary fixes that pop up with time shouldn't be an issue.

[atodorov]

+1 for what @timabbott says. I run Kiwi TCMS and I can contribute with the same items on our side. I can join forces with @mateuszmandera on cleaning up the backlog as well.

[omab]

Hi,

I'm very happy to witness this interest on the project and I'm sorry it takes so long for me to bring an answer to this topic.

First, let me address the key suggestions mentioned above:

1. Introduce co-maintainers
   I'm open to this, one of the main purpose of moving python-social-auth to a Github organization was to open the doors to more maintainers, sadly previous attempts didn't work out very well.
   A plan needs to be worked to implement this, for instance I'd like to start by defining proper contributions guidelines and maintenance process (maybe restrict merges to master but not to a RC branch, and automate PyPi releases).

2. Help with PR reviews
   Extra eyes on new code changes is always welcome, this accompanied with automated processes (tests, syntax checker, etc) and well defined guidelines (like issues and PRs templates) are a nice combination to ease the process of adding contributions into the codebase.

3. Financial support
   I've never pursued this project to be profitable, although I have a donate button in the different READMEs, it was with no expectation of getting a significant cash flow. I still think the same, this project is open source because I believe in the model and it's my 2 cents contribution to the community.

4. Paid subscriptions
   This feels close to the previous point, and frankly, I'd prefer to not reach a point where there's a version with features for paid subscribers and another open source, or differentiation between contributions because there's monkey involved. Being open source was a key to this project since the beginning.

5. Fork the project
   I agree fragmentation is not good for libraries and it should be the last option to avoid a project dying, I'll be happy to transfer the organization to somebody capable enough or under the PSF umbrella before letting it die.

The plan

Here's the short and long term plan I'm considering implementing now.

Over the following week (one or two weeks) I'd like to clean the house, this means:

• Merging outstanding PRs following a order based on urgency (API compatibility changes on providers, urgent bug fixes, etc)
• Closing stagnated issues (reduce backlog)
• PyPi release with last changes

Any help to identify priorities and provide code-reviews is very welcome.

Once the project is in a better shape, I'd like to dedicate time to improve the different processes:

1. Define a proper issue template, this will help to increase the reports quality and ensure enough information to develop solutions / features / etc.
2. Define a proper PR template, this will help to speed up the contribution process if a PR proposal is well formatted, this also involve policies like having tests or proper changes to existent ones.
3. Polish automation around PRs, flake8, test, any red flag means that the PR won't be reviewed until fixed.
4. Split development efforts from the master branch, developments is based on a devel branch, PRs are merged into it and master is used to manage releases.
5. Automate releases by using the Release and Action features on Github.

Finally, the third phase, open the doors to co-maintainers. A maintainers team will be created with permissions to review and merge PRs into the development branch. Later, another team will be created with permissions to issue new PyPi releases.

At first, I'll reserve the right to determine who will join the maintainers team, but feedback is welcome and I'll take it into consideration. Later I'd like to open this as well, and be a decision held by the whole team.

Coordination

I've created the Slack workspace https://python-social-auth.slack.com (invite link) as a medium to coordinate efforts (dedicated channels will be added as they are needed).

Thanks @atodorov and @timabbott for your feedback on this topic. I've been approached by more people the last few days as well, also many thanks to them (Asher Foa, Liz Henry and Sumana Harihareswara).

[brainwane]

Thanks @omab!

As of March 17th, v3.3.0 of social-auth-core is on PyPI.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[timabbott]

I feel like running stale-bot on this project seems like a mistake; it doesn't have a ton of issues, and it's a lot better to do human issue triage than have an automated bot close issues with useful context.

(Not commenting on whether this specific issue should be closed; just on stale-bot).

[timabbott]

I guess back to the original question around this issue, @omab are you up for adding additional maintainers to this project? It seems like bringing on an additional maintainer would be a good investment to make while there are folks interested in doing so that would likely pay off long term.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[timabbott]

@omab just checking in on the idea of adding more maintainers. I don't think it makes sense to close this issue as stale as it hasn't been resolved.

[atodorov]

@omab just checking in on the idea of adding more maintainers. I don't think it makes sense to close this issue as stale as it hasn't been resolved.

Hi @omab,
any news here ? We've been patiently waiting for some kind of response on your side but apart from a few merged PRs and resolved issues nothing has changed in the past few months. If you aren't open to adding new members to this repository just let us know, so we know what to do.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mateuszmandera]

This still shouldn't be closed, so posting to stop stalebot.

[nijel]

The plan described by @omab in #445 (comment) sounds good, but it doesn't seem to move much forward. I don't think it's necessary for you to do the clean-up first before getting more people on the project - many people have offered help and I'm pretty sure they can help with getting the project into shape you have described. I can help with this as well.

It's apparent that @omab no longer has much time to spend here and that's understandable. He has done great job in building this software and priorities change. It would be great to get more people on the board and move the project forward.

And some more remarks:

PyPi release with last changes

That's something only @omab can do right now, the 3.4 release seems to be missing there, see #485

Closing stagnated issues (reduce backlog)

There is nearly no backlog thanks to stale bot closing nearly everything.

Merging outstanding PRs following a order based on urgency (API compatibility changes on providers, urgent bug fixes, etc)

I will look at some PRs later today to review them.

Polish automation around PRs, flake8

Something like #522?

[atodorov]

@nijel welcome aboard.

FTR as can be seen from the previous comments several people have expressed desire to become co-maintainers with write access to both GitHub/PyPI for pushing new releases. @timabbott and myself have been most vocal about it. We did talk about this on Slack 6 months ago as well.

However up to now I haven't heard back from @omab what would it take for others to be granted access to the repository (e.g. how to establish a level of trust that we'd not fuck up everything). IMO this is a necessity before having others as co-maintainers, at least that's how it is on multiple other repositories where I am an official co-maintainer.

[digismack]

It looks like many pull requests are being closed by stalebot. People are spending time and effort to improve the library and their contributions are being wasted. This library has a lot of usefulness to the Python community and it appears to be withering away without any dedicated maintainers. This is really unfortunate. At this point is there any realistic path forward besides forking it?

[andersk]

Have you considered transferring the project to Jazzband? It was designed to make sharing maintenance and release management work for Python projects as painless and automated as possible. Seems like a great option to look at if you don’t have time to deal with all of that administrivia yourself.

[digismack]

I second the idea of transferring to Jazzband. They maintain several other very useful Python/Django projects that I've used and they are pretty responsive to pull requests and generating regular releases. (Also, yay, I learned a new word – administrivia).

[nijel]

This issue is open for more than 9 months now and nothing has changed meanwhile. I think it's time to figure out how to move forward without @omab's cooperation. Jazzband sounds like a good option where the repo could be placed. The tricky part would be PyPI packages access, but that can be handled as well (see https://www.python.org/dev/peps/pep-0541/).

[andersk]

I agree that it’s time to move forward. I note that the PEP 541 definition of abandoned requires “no releases within the past twelve months”, which won’t be true for another three months. Perhaps we can argue for an exception on the grounds of apparent security issues (#533, #538)? If not, the package will need to be renamed.

[nijel]

First thing is to re-start development and process existing pull requests (most likely it will be needed to go through the ones closed by stale bot). The release is the last step to take and given how fast are things moving so far, the extra three months might easily pass until then. My preferred solution still is that @omab hands over control to new maintainers instead of going through PEP 541.

Also, the transfer to JazzBand expects repo to be transferred, what is not possible without @omab doing this.

PS: Not sure if JazzBand is the best way to go, it has it's issues as well, see jazzband/help#196

[omab]

I'll take into consideration moving the project to something like JazzBand in the future but first I want to try opening to maintainers the organization, I know my original plan wasn't fully implemented and it stagnated, but still, I'd like to give it a try.

I've put an open-for-maintainers notice in this project README.md and also open #539 to raise visibility.

Also, stale-bot won't be closing PRs anymore and I've re-open those marked by it.

Hope this efforts help to improve this project health.

[whitej6]

If the project is still looking for maintainers I would like to volunteer. Currently the projects I am maintainer of rely on social auth core and I have done extensions of social core for deployments to support additional backends and pipelines.

[nijel]

The project definitely needs more hands on handling issues and pull requests. There are few people doing that now, but with very limited scope and time. See #539 for getting maintainer access to the repo.

[whitej6]

I found @omab's email via his GH profile link to his personal site. Sent an email but wasn't sure if that was the right contact email.

[davidhalter]

Should be fine. I think I contacted him in the same way.