-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Docs: New how-to sublevels (Diátaxis) #10131
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
Conversation
…and create better index pages
I had hoped that I didn't need to write too much new content here. But a lot of the current how-to guides don't have very straight-forward introduction paragraphs. Some don't even have any :) |
…levels and add a few missing introduction paragraphs to some guides
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, I didn't do a full copy edit of all the listings pages, but I do think there's likely ways we can be smarter here, rather than copy/pasting the same strings 2-3 places just to remove a couple words. I'd like to find ways to repeat ourselves less, while also providing a good UX to users.
Over the years, | ||
we have become familiar with a number of methods that work well and which we consider **best practice**. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Over the years, | |
we have become familiar with a number of methods that work well and which we consider **best practice**. | |
These guides share best practices that we've learned for managing documentation. | |
If you need ideas for how to get started in various areas of documentation, | |
this is a great place. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you update the suggestion? I can't quite make out what the intention was with the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not hugely important, just trying to clarify what the content is a bit more. But it's not my best writing, for sure.
@@ -0,0 +1,82 @@ | |||
How-to guides: content, themes and SEO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a weird title, and seems unrelated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean than "content, themes and SEO" is a bad category?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather represent each of these nouns than the alternatives:
- Represent important nouns that the reader will recognize.
- Hide everything in an umbrella term like "content" or "writing documentation", I don't really like that.. it's ambiguous.
- Split up into separate sub-levels. Not to add more sub-levels at this stage IMO.
But if there's better wording for this, that'd be great!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just don't understand how these 3 things are related, and why only these things? It's a different style than all the other headings, so we should make it similar.
Perhaps:
How-to guides: content, themes and SEO | |
How-to guides: Improving user experience |
Or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sub-levels were written more with an emphasis on "nouns" :) But yeah, I get that the current version has short-comings
I just don't understand how these 3 things are related, and why only these things?
I think that "Improving user experience" does get close to an understanding of how these things are related.
The real issue is probably that we have a good technical understanding of what we mean by content vs. build and configuration. But we can't know if the reader knows where a "theme" fits in!
Currently the menu looks like this:
We could make a menu label that is like: "Content: Themes, SEO and more..." ?
It's also a bit scoped around "Using your documentation tool on Read the Docs" or "Using Sphinx, MkDocs and other tools".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've noted to get back to this!
docs/user/guides/setup/index.rst
Outdated
⏩️ :doc:`Connect your Read the Docs account to your Git provider </guides/connecting-git-account>` | ||
Steps to connect an account on |git_providers_or| with your Read the Docs account | ||
|
||
⏩️ :doc:`Connect your Git repository automatically </connected-accounts>` | ||
Connecting your Read the Docs account to one of the supported Git providers, |git_providers_or|. | ||
|
||
⏩️ :doc:`Connect your Git repository manually </guides/git-integrations>` | ||
Setting up and connecting your Git repository manually, supports most Git providers with webhooks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's really not clear to me how these 3 pages differ, as a reader?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the same as before. At least now, there's a sentence accompanying each guide :) I think we should solve it separately in this case.
I don't think we can improve much without restructuring the guides? I could imagine that merging the first 2 guides would be beneficial, since "Connect your Read the Docs account to your Git provider" is a precondition for "Connect your Git repository automatically".
Having 2 guides: "Doing things automatically" vs. "Doing things manually" will be less work for the reader to digest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just think users want to do the thing, right? The manual & automatic approaches should presumably be in the same place? I just feel like we broke up our guides in a way that makes them much harder for users to use, and we need to undo that if we're finding it confusing, since users will be even more confused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe these titles would work better... gonna leave them as a future task...
- "Connecting an automatically imported Git repository"
- "Connecting a manually imported Git repository"
Co-authored-by: Eric Holscher <[email protected]>
@ericholscher thanks for the great review, I went through the input and updated everything. It's ready for another review, I haven't found anything further actionable. Redirects are ready for removed pages 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks close to me. I really want to fix the issue where we keep repeating subsets of titles and page intros, but we don't need to solve that now. I do think it's important for longer term maintenance, as those will almost certainly get out of sync, but again, not a blocker here.
then consider rewriting it or turning it into an internal comment afterwards). | ||
* Title convention: Use words indicating explanation in the title. | ||
Like **Understanding <subject>**, **Dive into <subject>**, **Introduction to <subject>** etc. | ||
* Introduce the scope in the first paragraph: **“This article introduces ...”**. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯
Does it seem good to open a separate issue on researching what to do? Would be nice to hear from others, so I'm thinking we could open it in this very repo. a) If there's an existing way to do it: We do it! |
Co-authored-by: Eric Holscher <[email protected]>
Yea, 👍 on opening a follow-up issue. |
…dthedocs.org into diataxis/howto-sublevels
Refs: #9747
Reflections to consider for review
CC: @ericholscher
I wrote an introduction for the very first sub-level and for "best practice", but for all of the other sub-leves, I didn't see that an introduction paragraph contributed anything... it was better without one. Feature reference is the same.
📚 Documentation previews 📚
docs
): https://docs--10131.org.readthedocs.build/en/10131/dev
): https://dev--10131.org.readthedocs.build/en/10131/