Skip to content

Policy for outdated, non-official docs #9130

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
3 tasks
ericholscher opened this issue Apr 21, 2022 · 4 comments · Fixed by #9731
Closed
3 tasks

Policy for outdated, non-official docs #9130

ericholscher opened this issue Apr 21, 2022 · 4 comments · Fixed by #9731
Assignees
Labels
Accepted Accepted issue on our roadmap Needed: design decision A core team decision is required

Comments

@ericholscher
Copy link
Member

ericholscher commented Apr 21, 2022

The goal here is to have a way to remove forks of common projects in search results. We had some private conversations about this in our old, private roadmap board. Copying here:

Tasks

  • Author guidelines for dealing with forked projects (as part of our abandoned project policy?)
  • Add way to disable search indexing (robots.txt) for forks or outdated project docs on request of the project maintainer .
  • Add way to validate ownership or "official"ness of docs on RTD? Not 100% sure if this is really valuable, since it would have to be visible on doc pages to be meaningful, and hard for us to integrate.

Initial thinking

A couple questions:

  • How do we validate "official" docs vs. unofficial?
  • How do we educate users on what is official, and what that means?

Twitter's verification is a textbook example of how hard "verification" is. Are we just saying "The repo in this project is linking to this site" in some kind of automated fashion? If so, educating users is still going to be the hardest step.

I think it's worth doing in some fashion, but it's definitely not a magic bullet, but it's a good incremental step forward.


I would say that we need a bit more than a verification badge alone, though it still might be part of a solution or our at least our UI.

The larger UX issue is surfacing these projects for indexing at Google, as this is the primary place these projects are found. Alone, a verification badge probably doesn't address this issue -- users will still land on the offending docs and we can't guarantee the reader user is familiar with Read the Docs or our verification system.

The most immediate problem seems to be that we don't have a way to stop forked projects from being indexed, and subsequently shown in search results. Right now, the best I can do is tell the user that we'll follow our abandoned project police and usually wait 6 weeks to remove the project. It would be much easier to visually confirm the project is a fork and flag it in the admin as a forked project, and this would be less destructive than deleting or changing maintainers.

The benefit behind hiding this feature from users is that we don't need to invest time in educating about verified projects, and we can be selective about what projects get our attention. We probably mostly only help large/popular projects with this work.

Perhaps in the future there would be a separate project to identify these forked projects in an automated or semi-automated way. However, we'd need to look at data first, and see what forked projects are doing.

@ericholscher ericholscher self-assigned this Apr 21, 2022
@humitos humitos added Needed: design decision A core team decision is required Accepted Accepted issue on our roadmap labels Apr 25, 2022
@agjohnson
Copy link
Contributor

Is it okay to put this on the backlog or push this one out to revisit? It seems useful still, but I guess we also only hit this infrequently -- though to be fair when we do hit this issue, it's with a high profile project.

We could kick this back to a discussion if we have unanswered questions here still too.

@ericholscher
Copy link
Member Author

ericholscher commented Aug 31, 2022

I think this is still worth doing, but I've been unable to get to it. If someone else wants to draft a version, that would be a good next step, but I'm fine moving it to the backlog for now, given my inability to do it 🙃

I went ahead and pushed it back a few sprints, since I do still want to get it done.

ericholscher added a commit that referenced this issue Nov 15, 2022
I'm not 100% in love with this content structure,
but I think it's important to get this out.

Closes #9130
@humitos
Copy link
Member

humitos commented Nov 15, 2022

Twitter's verification is a textbook example of how hard "verification" is. Are we just saying "The repo in this project is linking to this site" in some kind of automated fashion? If so, educating users is still going to be the hardest step.

Mastodon has a method to verify you are the owner of the links you use in your profile:

Screenshot_2022-11-15_12-36-12

I'm not sure if this process applies to verify a project itself, but it may bring some other ideas for this.

@agjohnson
Copy link
Contributor

This pattern, or some similar schema/metadata, could be a good proactive solution for high profile projects on Read the Docs. We still need a decision tree in our policy of course, as we can't expect many projects to follow this type of pattern -- especially projects not on Read the Docs or following Read the Docs. But this at least gives an explicit mechanism for sites to tell us what is official and what is not.

@ericholscher ericholscher moved this from Planned to Needs review in 📍Roadmap Nov 23, 2022
benjaoming added a commit that referenced this issue Nov 24, 2022
* Add an initial policy for delisting unmaintained projects

I'm not 100% in love with this content structure,
but I think it's important to get this out.

Closes #9130

* Move legalise to the bottom

* A bit more clarify

* Add to TOC

* Apply the most immediately uncomplicated suggestions from code review

Co-authored-by: Manuel Kaufmann <[email protected]>
Co-authored-by: Anthony <[email protected]>

* Expand section on what "unmaintained" means

* Add more cross-references for defined terms

* sembr

* Adding linebreaks

* Remove "candidate" and make it a bit more clear that someone needs to submit a report

* Add a template for emails

* Move definitions to "specification" as @humitos suggested

* Move use cases to "Examples" under rationale

* Adds robots.txt boilerplate

* Add a step that the source project is notified by RTD core team

* resolve warning - include in TOC

* Add a comment in robots.txt template

* Update docs/user/unofficial-projects.rst

* Adds a link in robots.txt to where the policy will presumably live

* Apply suggestions from @agjohnson code review

Co-authored-by: Anthony <[email protected]>

* Update docs/user/unofficial-projects.rst

Co-authored-by: Eric Holscher <[email protected]>

* Remove procedure to notify upstream maintainers

* Change Specification to Definitions

* Move High-level Overview to Rationale

* Add a definition of source project

* Delisting with notification. Step added to take no further action if unreachable. Step added that actions may be taken if reachable

* Talk mostly of "owner" in plural, there might be several people maintaining a documentation project

* Remove SOME stuff, we aren't going to seriously validate that

* Remove examples section, it doesn't fill much purpose now

* Apply suggestions from @humitos and @erichholscher

Co-authored-by: Manuel Kaufmann <[email protected]>
Co-authored-by: Eric Holscher <[email protected]>

* reference Terms of Service doc

* Move delisting section

* Remove step outlining what happens if "unreachable" since nothing happens

* Remove definition of "Unreachable" since it's not in use

* Remove definition of Source Project

* Update docs/user/unofficial-projects.rst

Co-authored-by: Eric Holscher <[email protected]>

* Add cross-references to Project Policies

* Apply suggestions from code review

Co-authored-by: Manuel Kaufmann <[email protected]>

* Update docs/user/abandoned-projects.rst

Co-authored-by: Manuel Kaufmann <[email protected]>

* Update docs/user/abandoned-projects.rst

Co-authored-by: Manuel Kaufmann <[email protected]>

* ANY and ALL => **any** or **all**

Co-authored-by: Benjamin Balder Bach <[email protected]>
Co-authored-by: Manuel Kaufmann <[email protected]>
Co-authored-by: Anthony <[email protected]>
Co-authored-by: Benjamin Bach <[email protected]>
Repository owner moved this from Needs review to Done in 📍Roadmap Nov 24, 2022
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 Needed: design decision A core team decision is required
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants