Take over abandoned spotipy

[felix-hilden]

Request

I'd like to transfer the ownership of the abandoned spotipy project (RTD, GitHub) to myself (RTD profile, GitHub) and move the original project to plamere-spotipy.

Rationale

I have rewritten a Python package for the Spotify Web API. A transfer has already been initiated on PyPI after declaring the owner to be inactive and the package abandoned according to PEP 541, which reportedly influenced your policy as well.

I'd like to take over the RTD project as well, because the packages have the same application domain so they could be confused. If we host on another project name, users of the package could find outdated and incorrect documentation. But I understand that it is valuable to also keep the original documentation available.

Abandonment

I do acknowledge the package is not abandoned by your standards. I was originally concerned with the 100 monthly views requirement, but it seems one of the abandonment conditions (no proper documentation) does not hold either. However, in an issue I posted regarding that view limit, stsewd stated that you are flexible.

In closing

With this in mind, as the package is transferred on PyPI and we look for a place to host our documentation, having the same project name on RTD seems like the only correct way to go.

But I'm not sure how you handle transfers or what would be the best way to do this. Should I claim the plamere-spotipy project? Or should I simply publish a different version for the original documentation? Here's our current transfer plan.

[stsewd]

Hi @felix-hilden I've sent the email to the user today. If the user doesn't reply I think we could just rename the old project to spotipy-plamere, and your project can link to that project saying where to find the old docs.

/remind me about take action on this project in 6 weeks

[reminders]

@stsewd set a reminder for Dec 19th 2019

[felix-hilden]

Thank you for the reply and taking action!

The more I think about it the more just using a different version number seems appealing - if I've understood the feature. Do you agree or do you think renaming is still the best option, any previous experience with similar situations?

[stsewd]

The more I think about it the more just using a different version number seems appealing

That can be possible, but not easy, and maybe prone to errors. This is because all versions in rtd came from one repo. So, you'll need to point to the old repo, activate/build the versions, point to the new repo and build the new versions, but you should be careful to not have collisions (versions with the same name). Also, that is hard to replicate if needed in the future.

But if you mean just increasing the version number on your repo (like 3.0 would be the "first" version) and keep the old docs till 2.2.4 (separate projects) that would work.

[felix-hilden]

I think that's pretty much just it. We plan on publishing one more doc in the 2.x series that has deprecation information and then from 3.0 on. So it could work. Let's see what the best solution would be.

[reminders]

👋 @stsewd, about take action on this project

[stsewd]

@felix-hilden time has arrived! Let me know how do you want to handle this, give you permissions or rename the old project.

[felix-hilden]

I'd like to have permissions to the old project, please! I think the version numbered solution is better. And we are still considering what to do with the project together in the original repository.

It's too bad Plamere has been so inactive... But thanks a bunch for your help!

[stsewd]

Done!