A policy for abandoned project names #3343

benji-york · 2017-12-01T19:45:28Z

This document was inspired by @jimfulton's work on #3314 which was spurred by issue #3287.

The document is essentially a reformulation of Python's PEP-0541 which deals with abandoned PyPI projects (as suggested by @ericholscher).

ericholscher

LOVE THIS. Thanks so much for doing the work here! I think this is a great policy, and something I'm super excited to have documented.

ericholscher · 2017-12-01T20:12:15Z

docs/abandoned-projects.rst

@@ -0,0 +1,111 @@
+Abstract


This should have a descriptive header for our TOC's (eg. "Policy for Abandoned Projects")

I've fixed the header and made a few other tweaks to make it work in the context of a larger document.

jimfulton · 2017-12-02T00:14:32Z

docs/abandoned-projects.rst

+A project is considered *abandoned* when ALL of the following are met:
+
+* owner is unreachable (see Reachability above);
+* no releases within the past twelve months; and


Is the request to change "releases" to "builds"? If so, that's fine with me. I don't actually understand RTD, so I'm working mostly as a Chinese room.

Yes. But as mentioned elsewhere, I don't think time matters in this context.

I think, as @jimfulton says, this point could be tricky since "12 months old documentation" could be still vaild.

jimfulton · 2017-12-02T00:15:36Z

docs/abandoned-projects.rst

+  existing owner;
+* the candidate is able to demonstrate that the project suggested to reuse the
+  name already exists and meets notability requirements;
+* the candidate is able to demonstrate why a fork under a different name is not


This seems a little draconian.

It seems so to me too, but the request was for a policy based on PEP-0541 and this mirrors it exactly.

I especially dislike the bit about the candidate has to try to contact the project owner again after the system maintainers have already tried and failed (as part of designating the project as abandoned).

Mmm.. yes, and this is conplicated ot demostrate in an objective way.

For example, as @ericholscher suggested before python-manuel as a name... but then, why/how do you demostrate that is not a valid name for your project? In this particular case, I think it's bad idea to deny just the manuel name to a project called manuel when the one occupying the name is abandoned. But that's also subjective... I think.

jimfulton · 2017-12-02T00:17:01Z

docs/abandoned-projects.rst

+A project is considered *abandoned* when ALL of the following are met:
+
+* owner is unreachable (see Reachability above);
+* no releases within the past twelve months; and


Perhaps there should be a mention of projects that have never had a successful build.

That sounds good. What do people think about changing the above to "no successful builds ever or no successful builds within the last twelve months; and"?

FWIW, I don't really like the idea of considering a project, especially a documentation project to be inactive simply because there haven't been new builds. Stable projects can go years without needing to update documentation.

Had manuel.readthedocs.io not 404ed, I would never have considered trying to get the name.

no successful builds within the last twelve months

This doesn't apply for me. Since, there are projects (books, for example) that are built just once and that's it. So, after 2 years, there wasn't an update of the book, but it's still valid.

Perhaps there should be a mention of projects that have never had a successful build.

I'm totally 👍 with something like this.

IMO, a project with successful builds shouldn't be considered inactive.

jimfulton · 2017-12-02T00:19:28Z

IDK how many projects have never built or point to non-public repos, but It seems that projects like the one in #3287 should be a no-brainer.

I wonder if it should be possible to create a RTD project from a private repo should even be allowed.

agjohnson · 2017-12-02T00:38:19Z

There's no way for use to disallow private projects, as when we clone from a URL we have no information about this. We already limit this to public projects if you us a connected GitHub/Bitbucket account.

jimfulton · 2017-12-02T00:41:32Z

No you don't. :) http://readthedocs.org/projects/manuel/ uses a private bitbucket repo.

Oh, but this probably wasn't a "connected bitbucket account".

jimfulton · 2017-12-02T00:42:59Z

Should you allow creation of projects from repos you can't clone?

agjohnson · 2017-12-02T02:39:48Z

Unfortunately, there's no way to tell if a project is private in this case until the project has been set up and we actually try (and fail) to clone. Altering the project state/availability at that point would be a negative user experience, so not a change we'll likely make. I think problems of abandoned projects like this is probably best served with policy around reclaiming namespace.

I don't know if there is a good way to free up our namespace without requiring more of the core teams attention -- something in short supply.

benji-york · 2017-12-02T14:05:47Z

docs/abandoned-projects.rst

+* no activity from the owner on the project's home page (or no home page
+  found).
+
+All other projects are considered *active*.


Is the question "Aren't there a lot of other ways a project could qualify as inactive?" If so, yes, but as far as a policy goes, it would seem that being strictly binary is the easiest thing for people to understand.

jimfulton · 2017-12-02T20:09:01Z

Perhaps a clone should be attempted during setup. Then again, IDK how common a problem this is. (It might be interesting to query how many projects have never had a successful build.) If the situation I ran into is rare, then apologies for beating this dead horse to a pulp.

jimfulton · 2017-12-03T19:27:54Z

Can someone with access to RTD's database please find out how many and what percentage of projects have never had a successful build?

humitos

I would say there is nothing blocking this PR to be merged, but there are a couple of things that maybe worth to keep talking.

Anyway, it's an amazing starting point and we could improve it later.

humitos · 2017-12-03T19:26:28Z

docs/abandoned-projects.rst

+A project is considered *abandoned* when ALL of the following are met:
+
+* owner is unreachable (see Reachability above);
+* no releases within the past twelve months; and


I think, as @jimfulton says, this point could be tricky since "12 months old documentation" could be still vaild.

humitos · 2017-12-03T19:27:02Z

docs/abandoned-projects.rst

+A project is considered *abandoned* when ALL of the following are met:
+
+* owner is unreachable (see Reachability above);
+* no releases within the past twelve months; and


Perhaps there should be a mention of projects that have never had a successful build.

I'm totally 👍 with something like this.

humitos · 2017-12-03T19:30:36Z

docs/abandoned-projects.rst

+  name already exists and meets notability requirements;
+* the candidate is able to demonstrate why a fork under a different name is not
+  an acceptable workaround;
+* access statistics for the existing project indicate the project is not being


how are we going to consider this? by pageviews?

I think this is easier in pypi since they have the downloads in the last X, publicly visible.

humitos · 2017-12-03T19:33:55Z

docs/abandoned-projects.rst

+  existing owner;
+* the candidate is able to demonstrate that the project suggested to reuse the
+  name already exists and meets notability requirements;
+* the candidate is able to demonstrate why a fork under a different name is not


Mmm.. yes, and this is conplicated ot demostrate in an objective way.

For example, as @ericholscher suggested before python-manuel as a name... but then, why/how do you demostrate that is not a valid name for your project? In this particular case, I think it's bad idea to deny just the manuel name to a project called manuel when the one occupying the name is abandoned. But that's also subjective... I think.

jimfulton · 2017-12-03T19:53:51Z

FWIW, while I think it's admirable to want to reuse PEP-0541, I don't really think it applies very well. I don't think a project without new builds should be considered inactive. Also, IMO, project names are far more important for RTD than they are for PyPI. In PyPI's case, it's mostly packaging scripts that are using project names. For RTD it's humans. It's a feature, IMO, that I can usually guess that a project named foo's docs can be found at foo.readthedocs.io.

My original proposal, #3314, only got RTD volunteers involved if a project didn't have viewable docs, IOW no successful builds, and was inactive. This is much narrower scope than that used here. I think the scope in this proposal is unnecessarily broad. I think this proposal, as currently written fails to recognize a key issue: whether the project has any builds. IMO, a project with no builds should be considered invalid (after allowing for time for fixing builds).

ericholscher · 2017-12-03T22:33:09Z

I feel like we're in proper bike shedding territory here. It seems like there is one case we're worried about being missed:

Projects with no builds and invalid HTML

We can easily fix that.

Is there a specific thing we're worried about in terms of false positives? Projects that haven't been built in >12 months, but which people are viewing, or the owner is active in responding, are already exempted from this policy.

I think the best path forward here is:

Fix the above specific oversight
Merge this PR 🎆
Integrate a public facing "inactive" indicator into the RTD dashboard for projects that qualify
- Include a contact form in that dialog that will email the person asking them to give up the name. This will only be shown to logged in users, and will send an email to the project owner, with the username and email of the person requesting it.

ericholscher · 2017-12-08T14:57:31Z

Hmm, I merged this on the CLI so I could update some small bits, but it didn't mark the PR as closed. Closing this, but it really has been merged.

I have opened #3382 to track making this policy easier for users.

add first draft

b9e1b0a

RichardLitt added the PR: ready for review label Dec 1, 2017

ericholscher approved these changes Dec 1, 2017

View reviewed changes

ericholscher requested review from humitos and agjohnson December 1, 2017 20:14

tweak document so that it works as a section of a larger document

ab5782e

jimfulton reviewed Dec 2, 2017

View reviewed changes

benji-york commented Dec 2, 2017

View reviewed changes

humitos approved these changes Dec 3, 2017

View reviewed changes

humitos mentioned this pull request Dec 5, 2017

Draft policy for claiming existing project names. #3314

Closed

ericholscher closed this Dec 8, 2017

Uh oh!

A policy for abandoned project names #3343

A policy for abandoned project names #3343

Uh oh!

Conversation

benji-york commented Dec 1, 2017

Uh oh!

ericholscher left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jimfulton commented Dec 2, 2017

Uh oh!

agjohnson commented Dec 2, 2017

Uh oh!

jimfulton commented Dec 2, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jimfulton commented Dec 2, 2017

Uh oh!

agjohnson commented Dec 2, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jimfulton commented Dec 2, 2017

Uh oh!

jimfulton commented Dec 3, 2017

Uh oh!

humitos left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jimfulton commented Dec 3, 2017

Uh oh!

ericholscher commented Dec 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ericholscher commented Dec 8, 2017

Uh oh!

Uh oh!

jimfulton commented Dec 2, 2017 •

edited

Loading

ericholscher commented Dec 3, 2017 •

edited

Loading