Skip to content
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

Consolidate current API tool documentation #2169

Merged
merged 11 commits into from
Jul 9, 2024

Conversation

stumblefiend
Copy link
Collaborator

@stumblefiend stumblefiend commented Jul 4, 2024

The current API content we have is sparse and extremely spread across many pages when one page on API tools would rank better for SEO, provide more value and better findability for our visitors, and lower our site footprint and content management overhead.

If we can expand the API tooling content in the future, this new, consolidated API page can become the index / topic cluster that future API tooling pages can link to.

I read through https://www.sphinx-doc.org/en/master/usage/referencing.html#ref-role and https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#internal-links but could use extra eyes on the links in this pull request. Actually, please tell me how to test the links myself or point me to the documentation I should use for testing links for the site. I couldn't find any suggestions on testing before creating the PR in either of the contribution guides:


📚 Documentation preview 📚: https://writethedocs-www--2169.org.readthedocs.build/

@plaindocs
Copy link
Contributor

I'll take a look at some of these minor issues, and the links

@plaindocs
Copy link
Contributor

@stumblefiend once you've got a passing build, broken internal links will break it. You'll get the same info running Sphinx locally, but a lot of folks just push things up to GH and fix when the build break. And you can click these links to see more details:

image

@stumblefiend
Copy link
Collaborator Author

stumblefiend commented Jul 4, 2024

Thanks for the clarification and help. Much appreciated! In the future, rather than run the linter and sphinx locally, I'll just fix whatever the build errors complain about. I'm on a Chromebook anyway and my Linux terminal won't even open half the time for me to run these tools locally in the first place 😅

@plaindocs
Copy link
Contributor

plaindocs commented Jul 5, 2024

Sounds good - @ tag me if you run into any trouble.

@stumblefiend
Copy link
Collaborator Author

Who needs to provide final review in order to merge this PR?

@plaindocs
Copy link
Contributor

I can 👍 it later today

@CollierCZ
Copy link
Member

Given that API Blueprint doesn't have active maintainers (reference), do we really want to actively promote it as one of our favorite descriptive languages? I would also note that we shouldn't be referring to Swagger format anymore.

Dredd also seems mostly abandoned (people are considering forking it), so I'm not sure if any of the information on the new page is actually useful now (though I'm sure it was previously).

I appreciate the idea of consolidating and I hate to block positive moves, but increasing the chance of people seeing outdated information might not be a net positive. If we're going to increase the number of people seeing it, it might help to check if it's relevant.

@stumblefiend
Copy link
Collaborator Author

stumblefiend commented Jul 9, 2024

Let's document these valid concerns but continue evaluating this PR.

We weren't in the top 100 search results for much of anything related to API anyway. @CollierCZ your point is one of the reasons why. We can continue to implement this pull request because it is an incremental step towards reconsidering our API content.

I will file a github issue relating to your 100% valid concerns about the state of our API documentation. I definitely think that content validity is a high-priority item to address ASAP. I've noted this in my own backlog of optimizations I'm spearheading as well.

@CollierCZ
Copy link
Member

I don't think that the outdated nature of the content is what is hurting SEO. I also don't think that trying to increase traffic to outdated content is a good strategy for SEO.

As I see it, all of the content on the new page is outdated, meaning it is low in quality, something that hurts SEO in the long run. I don't think that consolidating low-quality content into one page is actually an incremental change for the better.

In my opinion, it'd be best served by removing outdated content and keeping #2171 for putting in relevant content.

@plaindocs
Copy link
Contributor

@CollierCZ I get where you're coming from! Replies over on the relevant issue.

But I also think that merging this PR is lower effort than refactoring the existing content out, and therefore is an improvement.

@stumblefiend
Copy link
Collaborator Author

Thank you all for your thoughts and energy in consideration of this PR.

I'm reminded of the joys of housecleaning...you sweep small things into a pile and then you finally see how badly the house was in need of cleaning after all.

@stumblefiend
Copy link
Collaborator Author

Looks like I can't merge anything since I don't have write access. Can one of you grant me write access since I have a lot of PRs planned?

@CollierCZ
Copy link
Member

I think sweeping up a house is a good metaphor there. And then you don't leave what you've swept up in a pile that you invite everyone to look at, but put it in the 🗑️ . 😉

The lowest effort moving forward (and in my opinion biggest improvement) would be deleting the new page and keeping the rest of the PR (meaning the content would be gone). 🤷

I don't think I can grant write access. I'm just a member of the org.

@plaindocs plaindocs merged commit a5c1c23 into writethedocs:main Jul 9, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants