What to do with abandonned/unmaintained/orphaned projects?

[guyzmo]

Hi,

I'm posting this issue following an IRC discussion about what would be the policy in case a maintainer of a project is not around anymore (in case they left to become a shepherd in the mountains far from all technology… or when they die, because that happens too).

To quote @dstufft on IRC, that's what the current policy is:

We have a fairly adhoc process that skews heavily towards "if we can't get permission from the original maintainer then nothing happens"

Report a project as orphan?

As a developer and direct user of Pypi's warehouse, I'd be happy to be notified when a given published project is orphan (or likely to be orphan). So it'd be great to have the ability to report that a project is likely to be orphan (with justification for the record, like the date of the last official repository's commit, the number of PR/issues that have been opened but never answered…), so that after proper failsafes against abuses, orphan projects can be spotted easily in pip search, on the project's pypi's page and with a warning on pip install.

Transfer maintainership

As a sole maintainer of a few minor projects on pypi, if at some point I disappear from digital life (which I hope will happen in a very very long time ☺) and I'm unable to maintain or transfer ownership of projects I've been working on alone, I don't want to see them becoming orphans, with nobody able to take them over.

I thought maybe a good idea would be to add in the account preferences a person the maintainer trusts blindly, who could act like an "executor of will".

Then if a project is reported as orphan, and someone wants to take it over as a new maintainer to keep it going, administrators of pypa could contact that person to ask for confirmation that the original maintainer is unable to transfer owership himself, and would give permission to transfer ownership on behalf of the original maintainer.

Other processes/ideas?

I just raised the question as I had to deal with a pypi project that's no longer maintained by its author, and get to wonder about how I would want to see my FLOSS projects (which is somehow my "digital legacy") dealt with.

I don't know how similar projects deal with that (e.g. I know that linux distributions like debian has a way to deal with orphan packages, but pypi mostly contains code directly from the author, unlike debian where author ≠ maintainer).
But I have no clue how npm, gem etc. deal with that. if they deal with it at all.

[di]

We probably also need a real policy/process to release a package name that is being "squatted", i.e. has been registered, but hasn't made any releases. For example, what we did in #1487 seems to have worked, but isn't really a formalized process.

But I have no clue how npm, gem etc. deal with that. if they deal with it at all.

Here's how NPM manages package name disputes: https://docs.npmjs.com/misc/disputes

CPAN has a formal process: http://www.cpan.org/misc/cpan-faq.html#How_adopt_module

RubyGems has an "adoption center" that seems to be defunct: https://groups.google.com/forum/#!msg/rubygems-org/niS5ZO9DNgk/5Fhg9Q3QR7YJ

[FRidh]

Relevant is the draft of PEP 541
https://www.python.org/dev/peps/pep-0541/

[guyzmo]

BTW, as a related to this topic, I had a simple idea: it's a common usage pattern that a developer looks up the directory to find a library for his project, and finds several that might match the criteria. Maybe could warehouse provide a "score" that would help decision in terms of activity, responsiveness of the project.

When I have to decide, what I currently do is to lookup all projects, then click on the github link, check for the last commit, if there are issues/PRs when were they last attended by the developer(s), and finally choose the one that looks most active. Maybe I could share that feedback within warehouse using a 👍/👎 scheme.

[pradyunsg]

@guyzmo s/wharehouse/warehouse/ :)

Maybe I could share that feedback within wharehouse using a 👍/👎 scheme.

I believe this has been discussed previously and rejected. IIRC, there won't have voting on Warehouse since it is difficult to moderate the same and at the same time it would disadvantage new packages intended to compete with existing established ones.

could wharehouse provide a "score" that would help decision in terms of activity, responsiveness of the project.

👍 This is worth discussing imo.

Could you check there's is not an issue for something similar and then open a new issue for discussing this idea?

[guyzmo]

Could you check there's is not an issue for something similar and then open a new issue for discussing this idea?

yup there is: cf #991

[guyzmo]

though it's more about a rating, so basically 👍/👎 than really a score that shows how active a project is.

[brainwane]

I suggest we keep this issue to the issue of abandoned, unmaintained, and orphaned projects, and then cover more general and nuanced project activity statistics in #991.

It looks like PEP 541 is on its way to acceptance. I think we can resolve this issue in the following steps:

• accept the PEP (this is on the shoulders of the Packaging Working Group)
• Warehouse developers & Packaging WG decide on logistical stuff (what support queue we point users to for PEP 541 requests, User support ticket system #3231/functionality to rename a project #1919 dependencies)
• Warehouse developers coordinate with the Packaging WG to create the extension to the PyPI Terms of Use and link to it in FAQ and PyPI footer, per PEP requirement
• announce on distutils-sig

[brainwane]

https://mail.python.org/pipermail/distutils-sig/2018-March/032089.html

PEP 541 accepted! @di shall we move forward on the TODOs above? (Am on mobile)

[di]

Yep! Let's figure out our process.

I propose we either figure out #3231 or setup pypa/support-requests

Here's the step-by-step process for abandoned projects that I think we should add to our help/policy page somewhere:

1. Identify the project which is invalid/abandoned
2. Open a support request at $LOCATION
3. In the request, demonstrate the criteria for invalid/abandoned projects
4. In the case of an abandoned project, PyPI admins will start the
   reachability process (6 weeks of attempted contact)
5. PyPI admins resolve the request

[dstufft]

One question we'll need to answer is if these should be public or private requests.

[guyzmo]

about that, I guess it can be both :

• use the user's account contact mail first,
• then submit an issue to the upstream repository (if it has ticket support, and that task can be automated)

[ghost]

What about deceased maintainers? Is it possible to transfer the maintainership in these cases if a death notice is served?

cc @aaronkaplan

[di]

@wagner-certat Yes, I think that would fall under the category of an "Abandoned Project".

[aaronkaplan]

On 23 Apr 2018, at 16:59, Dustin Ingram ***@***.***> wrote: @wagner-certat Yes, I think that would fall under the category of an "Abandoned Project".

Thanks Dustin for the answer. What requirements would you have (should we send a certificate of death or so)? To whom? Best, a.

[di]

@wagner-certat We haven't determined the means by which PEP 541 requests will be created yet, see #3231.

Is this a hypothetical issue, or are you attempting to acquire an actual project for which the owner is deceased?

[aaronkaplan]

On 23 Apr 2018, at 17:13, Dustin Ingram ***@***.***> wrote: @wagner-certat We haven't determined the means by which PEP 541 requests will be created yet, see #3231. Is this a hypothetical issue, or are you attempting to acquire an actual project for which the owner is deceased?

The latter. It's real unfortunately. I am one of the co-authors of mihi's https://github.com/FFM/pycryptopan project. I have full write access to the github repo. However, mihi died some years ago and he was the single person responsible for uploading it to pypi (https://pypi.org/project/pycryptopan/). As a matter of virtual courtesy, I'd like to make sure that the code gets improved and actually made available for the world - on pypi.org - after all it's a pretty useful small code project which can be used to anonymise a lot in times of GDPR. So, yes, I would like to be able to upload new code to https://pypi.org/project/pycryptopan/ But for that account, only Mihi has access. I am also in contact with his left behind relatives who could help me with formalities in case you require that. Best, Aaron Kaplan.

[di]

@aaronkaplan Thanks for the clarification. I'd suggest that you make a separate issue to capture this request. We're currently still defining the process for PEP 541, and once we do we have a large backlog to work through as well, so please have patience.

[aaronkaplan]

On 23 Apr 2018, at 17:36, Dustin Ingram ***@***.***> wrote: @aaronkaplan Thanks for the clarification. I'd suggest that you make a separate issue to capture this request. We're currently still defining the process for PEP 541, and once we do we have a large backlog to work through as well, so please have patience.

ok. can of course make a separate issue. What time frame are we looking at? Months? Weeks? Days? Best, a.

[aaronkaplan]

okay, separate ticket #3792 created. Please advise on further steps.

[LalamN]

In a worst case,if the github platform is abandoned and shutdown permanately without selling.what happens to our projects and repositories does they have any backups, if not how they can be retrieved?

[di]

Calling this closed. The answer is defined in PEP 541.

[brainwane]

It looks like PEP 541 is on its way to acceptance. I think we can resolve this issue in the following steps:

* [x]  accept the PEP (this is on the shoulders of the [Packaging Working Group](https://wiki.python.org/psf/PackagingWG))

* [ ]  Warehouse developers & Packaging WG decide on logistical stuff (what support queue we point users to for PEP 541 requests, #3231/#1919 dependencies)

* [ ]  Warehouse developers coordinate with the Packaging WG to create the extension to the PyPI Terms of Use and link to it in FAQ and PyPI footer, per PEP [requirement](https://github.com/python/peps/blame/master/pep-0541.txt#L84)

* [ ]  announce on distutils-sig

@di what about these remaining TODOs, though?

[di]

Sorry, missed those.

[DriesSchaumont]

Hi! Is #3231 blocking this issue? If so, could I propose that a temporary process for PEP541 is formalized, while #3231 is being resolved? This way PEP541 requests can still move forward. I noticed that the current best-practice is to open an issue at https://github.com/pypa/pypi-support, but waiting for #3231 might cause larger backlogs than desirable.

Thanks in advance!
Dries

[toonarmycaptain]

May I suggest some sort of addition to this process, where the names of python2 only projects be made available to new projects on PyPI? I'm looking at a package whose last commits were in 2013, the package never supported Python3 (import yields a relative import error in Python3).

Obviously these names might be offered to the original maintainers with the caveat that the projects get updated, but, failing this, they should be made available?