Skip to content

Define workflow for deleting a project and deleting a version #1408

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gregmuellegger opened this issue Jul 6, 2015 · 12 comments
Closed

Define workflow for deleting a project and deleting a version #1408

gregmuellegger opened this issue Jul 6, 2015 · 12 comments
Labels
Improvement Minor improvement to code Needed: design decision A core team decision is required
Milestone

Comments

@gregmuellegger
Copy link
Contributor

We see more and more tickets about issues that arise around deleting projects and not beeing able to delete versions.

This ticket shall be the base for discussion around this feature.

There are two related parts on this ticket:

Deleting a project

Currently when a project is deleted, the builds for the project's versions are still kept around and publicly accessible. We need to define what shall happen once a user deletes a project and communicate that to the user via docs and via the user interface while deleting a project.

Following use cases might be valid:

  • [P1] The project merged with a different project or just got out of date and no longer maintained
  • [P2] The docs are moving to a different hosting platform

Deleting a version

Currently there is no way to delete the builds of a version.

Following use cases might be valid:

  • [V1] The version was part of a wrong push/invalid version number and should be deleted since the publication was an accident.
  • [V2] The version is no longer supported, but since it's still listed in google the project's users are still using the version even when it's outdated.

See the Deleting projects and versions milestone for related tickets.

@gregmuellegger
Copy link
Contributor Author

We currently don't want to break links and that's one reason why already built docs are not deleted even when the project goes away. However IMO the project's owner should be in full control of what happens to his docs. So there should always be the option to remove the HTML files from the server somehow.

However deleting documentation should be the last resort and we should offer the user other method of achieving their use cases.

For versions, we could allow the deletion of a version but provide the user with two options:

  • Mark the version as deleted and create a redirect to a different version specified by the user during deletion (solves use case V2).
  • Delete the version and the related builds but show someone who tries to access the docs of the deleted version a message "These docs have been deleted, please go to for the current documentation" (solves use case V1).

@gregmuellegger gregmuellegger added the Needed: design decision A core team decision is required label Jul 6, 2015
@gregmuellegger
Copy link
Contributor Author

In #1264 a user tried to delete a project and recreated it in order to fix an issue with a build. That did not work as the builds were not deleted. That IMO is counter intuitive.

@sergiocorreia
Copy link

@gregmuellegger have you arrived at a decision?

I find it incredibly infuriating that I can't delete projects. I moved the docs for reghdfe.readthedocs.org to my own website and I still see people going to the old version which is deprecated, even though I deleted the project entirely.

Either deleting or allowing redirection are better choices than having obsolete documentation. What would it take for this to work? DMCA?

@gregmuellegger
Copy link
Contributor Author

No, we should get approval for one way or the other from @agjohnson or @ericholscher on this first.

@ericholscher
Copy link
Member

I definitely think we should stop hosting deleted docs, but I'd love to save them to S3 or something along those lines, so the links aren't broken forever, and we could link to the archives on the 404 page. I think this is the best solution, and wouldn't be overly hard to build.

@gregmuellegger
Copy link
Contributor Author

Would you zip them in an archive and host this on S3? If we put the raw HTML files there then search engines will still pick up old obsolete documentation.

@ericholscher
Copy link
Member

Just host them normally with a robots.txt disallowing indexing. We could
also keep them hosted on our side at an archive domain, with robots.txt off
as well, though we already have issues with docs taking up too much disk
space, so I'd prefer to offload them somewhere else.

I guess we could just delete them, but that makes me sad, and breaks the
internet.

On Thu, Sep 17, 2015 at 10:19 AM, Gregor Müllegger <[email protected]

wrote:

Would you zip them in an archive and host this on S3? If we put the raw
HTML files there then search engines will still pick up old obsolete
documentation.


Reply to this email directly or view it on GitHub
#1408 (comment)
.

Eric Holscher
Maker of the internet residing in Portland, Oregon
http://ericholscher.com

@sergiocorreia
Copy link

@ericholscher can you do a redirect instead?

e.g. I moved a project from rtfd to my website to put it together with everything else, but now if you google you are at a loss about what link to follow..

@ericholscher
Copy link
Member

The hard part about redirects is that we serve all the HTML directly from nginx, without talking to Python. This is an effort to keep the page loads fast, and keep the docs serving even when our application servers or databases have issues. We do run Python code on 404's, which is where our traditional redirect logic comes in..

So we could delete the files, and do redirects in the 404 handling code. This would require us to keep a Project object in the database, but it would be in a "deleted" or "disabled" state, and have the redirect information on that. This seems like the best option, where a "disabled" project could be given either a redirect to a new site, or an archive listing of the previous content.

@mcohoon
Copy link

mcohoon commented Apr 18, 2016

As part of this issue you closed Issue 292, but I haven't seen a discussion here about user account management.

  • Include instructions on signup that username will be made public and not to use PII.
    • I'd prefer a random string as a profile ID and then optional display name that can be edited after the fact see stackoverflow.
  • Offer ability to delete your own account.

@gordonje
Copy link

gordonje commented May 17, 2016

Just wanted to add my vote for allowing users to set re-directs from one set of docs to another. We have a component of a project that has its own set of docs, but want to merge these with a more extensive and complete set of docs for the project.

In the absence of any automatic re-directing, what are folks doing? Just adding a url to the index page and saying "Go here"?

@humitos
Copy link
Member

humitos commented Sep 4, 2018

I'm closing this issue because nowadays it's possible to delete a Project and that action will remove all the HTML versions of it also. Besides, a Version can be marked as inactive and its docs are not served.

I consider this issue already done.

In case we want to keep going to the discussion of "archiving deleted projects on S3 or similar" we can open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Improvement Minor improvement to code Needed: design decision A core team decision is required
Projects
None yet
Development

No branches or pull requests

7 participants