-
Notifications
You must be signed in to change notification settings - Fork 14.3k
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
Overall cleanup for kubeadm setup guide. #8981
Changes from 3 commits
c103dec
8614f2b
2da35b9
4a9ab99
ceec395
c51539b
d65d586
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
--- | ||
title: "Kubeadm" | ||
weight: 10 | ||
--- | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see what you're doing here, and with moving (or removing, for which thank you!) the upgrade-downgrade files. But it looks to me like too much nesting to be useful. The "Kubeadm" subsection hides the fact that its children are about upgrading/downgrading until you expand it. Are you planning to move more kubeadm files into the Kubadm subsection? If so, it might be OK. But I'm still thinking this isn't the greatest UX. How many users are likely to think "upgrade/downgrade" if they see Kubeadm in the TOC? (Yeah, most of them are unlikely to get there by navigating the TOC also. But that's not a good argument for rearranging, either ;) ) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes there will be more content, this was chosen for both clarity and mgmt. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I also think it's a pretty deep TOC structure and I'm not sure this will help with discoverability. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @zacharysarah - This is the single point in question. I don't have that strong of an opinion on the matter other then grouping admin content associated with kubeadm is cleaner. I could happily remove the substructure below this one if that works for others too. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @timothysc I'm fine with deepening the TOC to a third tier. Right now, the second tier (Tasks > Administer a Cluster) is both densely populated and unhelpfully organized. In fairness to my colleagues, I'm not sure that a deeper TOC is the best solution, either--but it beats what we've got right now. I'd rather iterate successively than remain paralyzed. I'd like to see a different name for the proposed section, though. To build on @Bradamant3's suggestion, "Administration with kubeadm" as a section title works better than just "Kubeadm" (line 2). |
This file was deleted.
This file was deleted.
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.
Fine to remove a reviewer, but please don't add me. We use this list to specify tech reviewers, and I don't think I should be in that list ;)