Skip to content

Surface "abandoned" state on projects in UI #3382

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
ericholscher opened this issue Dec 8, 2017 · 26 comments
Closed

Surface "abandoned" state on projects in UI #3382

ericholscher opened this issue Dec 8, 2017 · 26 comments
Labels
Accepted Accepted issue on our roadmap Improvement Minor improvement to code

Comments

@ericholscher
Copy link
Member

ericholscher commented Dec 8, 2017

We now have an inactive project policy: http://docs.readthedocs.io/en/latest/abandoned-projects.html

We should:

  • Integrate a public facing "inactive" indicator into the RTD dashboard for projects that qualify
@stsewd
Copy link
Member

stsewd commented Feb 15, 2018

I think we can develop this as two features.

Marking a doc as inactive/abandoned

With this a project that meets the policy requirements for abandoned projects gets marked as inactive/abandoned, this is visible for everyone.

And probably we may want to be able to mark a project as protected (on the django admin panel only), so in a special case this project never gets marked as inactive/abandoned. A special case could be: the author requesting this, for historical reasons, our algorithm is wrong or is a false positive.

Communicating to the users

I have several ideas for this...

We can run a cronjob and send a warning email to the owner of the project if her/his project is marked as abandoned.

A user wants the project name (from the inactive one), she/he fills a form with some details, the owner of the inactive project receives an email with a warning and the request of the other user. The request can be sent no more than once every time and if a user already sent a request and other wants to do the same, she/he needs to wait a time before sending it.

After the owner is warned several times and no action is taken for reactivate the project, the project name gets released. This is done changing the project name to a random one or {user-name}-inactive-{number}?

If the owner wants to release the project name, she/he can change the name (slug) manually or just delete the project and the user who sent the request gets notified.

Conclusion

I think with this solution all the process gets simplified and is automatic. And also the interaction between the users is minimal (almost none).

@bansalnitish
Copy link
Contributor

Hi @stsewd, I would like to work on this! Can you please get me started!

@stsewd
Copy link
Member

stsewd commented Feb 28, 2018

@bansalnitish I think is better to confirm if this is the way the core maintainers want implemented this feature. But you can also help by adding some feedback from my current proposal or maybe adding another.

@ericholscher
Copy link
Member Author

I think we shouldn't automatically email/remove abandoned projects. I also think showing abandoned projects is lower priority. People who want a namespace are highly motivated, and will email us, so we should focus on executing that part first.

I think we should keep it light weight in terms of implementation so this isn't a lot to maintain. Perhaps just an admin-only button that says "email project owner with our abandoned project email" as a start, which sends an email from a template that we have in the repo.

Here is the email I sent last time as a start:

Hi,

We've had a request from one of our users for the project name {name} on Read the Docs. You are the current owner, and we wanted to reach out to you in accordance with our Abandoned Project policy (http://docs.readthedocs.io/en/latest/abandoned-projects.html).

Since this is a fork of the existing owners project, {name}, you must show us the additional work that has been done in order to keep the new project name, that is different than the existing version of the project.

Please reply to this email either allowing or disallowing the transfer of the name on Read the Docs within 6 weeks, otherwise we will take the action of *initiating the transfer to a new owner* by default.

Cheers,
Eric

@ericholscher
Copy link
Member Author

At the end of the 6 week period, I renamed the project to {name}-abandoned, but I'm not 100% sure that's the correct thing to do.

@ericholscher
Copy link
Member Author

I guess the primary thing I want to balance is the amount of work to build this, when it doesn't happen very often, with standardizing the execution. We could even just have a template in the docs, and not automate it within the software, as it has only happened a couple times so far.

@stsewd
Copy link
Member

stsewd commented Feb 28, 2018

@ericholscher so suggesting a template for sending an email to [email protected] would be fine. I like the idea of keeping it simple for now.

@bansalnitish
Copy link
Contributor

bansalnitish commented Feb 28, 2018

I am trying something simple for the start as suggested by @ericholscher and @stsewd.
I will submit a PR soon for the same and then we can discuss and make it better!

@ericholscher
Copy link
Member Author

Yea, another simple addition would be to have a query that specified "abandoned", and have a small message on the project page. I'm all for keeping things simple to start.

@agjohnson
Copy link
Contributor

agjohnson commented Mar 8, 2018

I agree on keeping it simple if this is a feature we need, but I don't agree this is a feature we need though.

I do have a few problems with our plan so far:

  • The biggest problem with our plan so far is we haven't saved any steps. Would-be abandoned projects will start in an active state. The UI to email us or the owner will only be shown to users once the project is marked as abandoned though. This still requires a user to reach out to and admin and start the process of confirming the project is abandoned. It's only after 6 weeks that we can finally change the status to abandoned. At that point, however, the original user would claim the namespace. There's no need for an additional email at this point, and the UI for contacting the owner will never show
  • We aren't going to be proactive about marking projects as abandoned, so adding UI forms probably doesn't make sense
  • I think adding user -> user contact is adding too much complexity for what will be a very infrequently used feature

Things we do need:

  • An admin function that sends an email notifying the project owner that their project is potentially abandoned. Ask they respond in 6 weeks or their project will be moved
  • An admin function that sets the project as abandoned: it marks Project.is_abandoned, it changes the slug to {project}-abandoned, and it sends an email notifying the user of the change and a link to the new project/doc pages.
  • We're not good at keeping track of when we've contacted users and when the 6 week period is up. I'm not sure we need a feature to track this, it seems unnecessary. It should be part of the process, we can create a trello card and assign it 6mo in the future.
  • Add a UI piece for projects that have been determined to be abandoned. This should be a sidebar item on the project detail page: State: This project is abandoned or something similar

Yea, another simple addition would be to have a query that specified "abandoned", and have a small message on the project page

I dislike the message pattern, we have too many patterns for this floating around.

@bansalnitish
Copy link
Contributor

bansalnitish commented Mar 8, 2018

Hi @agjohnson, the PR which I have issued contains the points:

  • To mark a project as abandoned
  • Admin only option to send mail to project owner
  • Tests for checking that only an admin is allowed to send email

The PR misses the following points:

  • Abandoned project state as a sidebar item on project detail page.
  • Changing the project slug to {project}-abandoned and notifying the user about that.

I want to know whether I should update the PR to match all the missing requirements.

@agjohnson
Copy link
Contributor

@bansalnitish This issue is still in a design decision phase, we'll have some more guidance once we've come to some harder conclusions here.

I looked at the PR you started, but it has a few patterns I think we want to avoid:

  • Automating is_abandonded -- projects that don't build within a year aren't necessarily abandoned, perhaps just unmaintained. We want to act as an archive in this case, not promote transferring the namespace.
  • Surfacing sending email as a user feature. Above I discuss making this an admin feature -- that is, a django site admin feature, not part of the RTD UI

Hold off on making changes for now, as the requirements will likely change. I'll have some more specific feedback after that will hopefully clear up some questions.

@bansalnitish
Copy link
Contributor

Sure @agjohnson, I will wait for the design decision to be made and then make the appropriate changes 🎉

@agjohnson
Copy link
Contributor

I'm going to unblock this. I think the feature we actually need here is:

  • Djano site admin functions for sending an email to project owners that their namespace has been requested
  • Djano site admin function for marking a project as abandoned (Adds -abandoned to slug, marks Project.is_abandoned
  • Project detail sidebar piece that states project is abandoned.

In this feature, we don't want:

  • User to user email
  • Automating abandoned state
  • Email on the project forms

Unfortunately, I think your PR is mostly invalidated with these changes -- and there doesn't seem to be admin functions (django site admin functions that is) for any of this. So I'll close your current PR, but leave the branch around for reference. I'd suggest starting with a new PR for this work.

@agjohnson agjohnson removed the Needed: design decision A core team decision is required label Jun 8, 2018
@agjohnson agjohnson added this to the Site admin features milestone Jun 8, 2018
@dojutsu-user
Copy link
Member

I am working on it.
Will submit a PR soon.

@stale
Copy link

stale bot commented Jan 27, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: stale Issue will be considered inactive soon label Jan 27, 2019
@dojutsu-user
Copy link
Member

It is still valid. There's an open PR for this.

@stale stale bot removed the Status: stale Issue will be considered inactive soon label Jan 27, 2019
@stale
Copy link

stale bot commented Mar 13, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: stale Issue will be considered inactive soon label Mar 13, 2019
@dojutsu-user
Copy link
Member

This is still valid bot.
Can I get a review on the attached PR?

@stale stale bot removed the Status: stale Issue will be considered inactive soon label Mar 13, 2019
@stale
Copy link

stale bot commented Apr 27, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: stale Issue will be considered inactive soon label Apr 27, 2019
@stale stale bot closed this as completed May 4, 2019
@dojutsu-user
Copy link
Member

Still valid bot.

@stsewd stsewd removed the Status: stale Issue will be considered inactive soon label May 6, 2019
@stsewd stsewd reopened this May 6, 2019
@stale
Copy link

stale bot commented Jun 20, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: stale Issue will be considered inactive soon label Jun 20, 2019
@dojutsu-user dojutsu-user removed the Status: stale Issue will be considered inactive soon label Jun 20, 2019
@stale
Copy link

stale bot commented Aug 4, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: stale Issue will be considered inactive soon label Aug 4, 2019
@humitos
Copy link
Member

humitos commented Aug 5, 2019

I'm marking this issue as Accepted since what we need to do is described at #3382 (comment)

@stale stale bot removed the Status: stale Issue will be considered inactive soon label Aug 5, 2019
@humitos humitos added the Accepted Accepted issue on our roadmap label Aug 5, 2019
@dojutsu-user
Copy link
Member

@humitos
There already a PR open -- #4995

@humitos
Copy link
Member

humitos commented Jun 4, 2024

We wrote two different guides about this issue:

We discussed the approach of showing a UI element on projects but we weren't able to pattern that works in an accurate way. I'm going to close this issue since we don't plan to implement a semi-automated way of doing this in the near future. We can come back if we think this is still relevant and we have a way to implement a good pattern.

@humitos humitos closed this as not planned Won't fix, can't repro, duplicate, stale Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Accepted issue on our roadmap Improvement Minor improvement to code
Projects
None yet
Development

No branches or pull requests

6 participants