-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Comments
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. |
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. |
I'm not 100% in love with this content structure, but I think it's important to get this out. Closes #9130
Mastodon has a method to verify you are the owner of the links you use in your profile: I'm not sure if this process applies to verify a project itself, but it may bring some other ideas for this. |
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. |
* 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]>
Uh oh!
There was an error while loading. Please reload this page.
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
Initial thinking
A couple questions:
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.
The text was updated successfully, but these errors were encountered: