A case PEP 541 does not seem to cover

Packaging
1

I just filed a PyPI support issue asking to take ownership of a project. But it’s a bit of a weird case, because the project isn’t “abandoned”. In fact, it’s actively maintained.

The root issue is that the original creator of the project, and still the PyPI owner of it, was CPython core developer Michael Foord, who sadly passed away last year. He had handed off maintenance to me (by importing his source tree into a GitHub repo I controlled, and giving me PyPI upload permission), so the project still receives regular updates and releases, and therefore isn’t really “abandoned”, but also is stuck in a state where the only person with full permissions to manage it on PyPI is definitively never coming back.

So I’m not sure if filing a PEP 541 request (I only did so, finally, because I saw discussion on social media that Michael’s personal domain had expired and is now being auctioned, creating a risk of someone trying to take over Michael’s former accounts) was the right thing to do, or if there even is a definitive documented single right thing to do for a case like this.

Does PyPI have a policy to cover this case, and I just missed it? If not, is it something worth working on?

6 Likes
2

I’ve used PEP 541 for a similar case.

I already had upload (“maintainer”) permissions but not admin (“owner”), and the original author wasn’t replying to email or GitHub mentions.

The owner was also unreachable by PyPI folk, so the project was considered abandoned and I was given admin access.

Looking at PEP 541, only 2/3 of the criteria for an abandoned project were met:

owner not reachable (see Reachability above);
no releases within the past twelve months; and
no activity from the owner on the project’s home page (or no home page listed).

So technically the PEP doesn’t fully cover our cases. But practically, it makes sense for an exception here.

3 Likes
3

I agree that if it comes to that, a one-off exception for this case is appropriate.

But… bigger tech organizations have already had to develop policies for what happens to, say, a cloud storage account when the account holder passes away, and maybe we’re at the stage where PyPI should figure that out too. Or maybe I just have this on my mind too much right now, due to some personal stuff over the past little while, coupled with just getting back from PyCon US where I didn’t see Michael there, and then seeing the GitHub issue template asking me what I’d done to contact him and frankly not knowing whether to laugh or cry or both.

5 Likes
4

For comparison, the core team process is here and GitHub’s is here.

1 Like
5

In absence of a defined process, PyPI Admins have had to make these decisions before, and will continue to do so on a case-by-case process.
I think PEP 541 is still adequate here, as it surfaces the transfer request and motivation history in the open.

It may make sense for a “succession planning” style enhancement proposal to emerge, whereby folks can pre-plan whom should take ownership in the original owner is no longer reachable for whatever reason.

PyPI Organizations can aid with this kind of distinction as well already - especially if an Org has multiple people with the Owner role, who can be trusted to make these decisions with more context and familiarity of the relationships between the contributors in the org.

7 Likes
6

I think that the PyPI ‘contract’ should somehow specify that if a sole owner of a project dies, ownership of the project reverts to PyPI admin unless specified otherwise by the owner. And that maintainers should get priority or at least have a say.

3 Likes
7

Michael was a dear friend to many people here. But in other cases, it’s hard to prove that a given PyPI user passed away.
So, as Hugo hinted, I think that what PEP 541 shouldn’t focus on that; instead it needs to cover the case of an active project with an unreachable owner. In this case, one of the maintainers should be promoted.

What about adding this text:

Promoting a maintainer to owner
-------------------------------

In cases where a project doesn't have a reachable owner, but still has active
maintainers, any of the maintainers may request to be promoted to owner.
The promotion is done when ALL of the following are met:

* none of the project's owners is reachable (see Reachability above);
* each of the project's maintainers either:
  - agrees with the promotion, or
  - is not reachable (see Reachability above);
* the candidate is able to demonstrate their own failed attempts to contact
  the existing owner;
* the owner has made no releases within the past twelve months; and
* the maintainers of the Package Index don't have any additional
  reservations.

That said, I agree that asking to demonstrate failed contact attempts can be insensitive. Maybe that point can become:

* the candidate is able to demonstrate their own failed attempts to contact
  the existing owner, or provides proof that contact is futile (for example,
  an obituary);
2 Likes