-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Move all VPA docs into ./docs #7548
Conversation
This is to try make the docs decoupled from the code, hoping that this will allow for easier restructuring of the docs, and also lead to improved docs over time.
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.
ok, now that i'm looking at the correct PR, this looks much better lol.
i think this makes sense to me and i'm happy to see the readme updated.
copied from my comment on the other pr
also, i was thinking about how we might want to document the cluster-autoscaler stuff and i think it will be challenging to solve this problem due to the providers. i think it's possible we could migrate the core CA docs, but we would want to have links for the provider specific pieces since those docs are owned by the various providers.
Amazing! |
/approve great work, thanks! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: adrianmoisey, voelzmo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
/kind documentation
This PR is a replacement for #7532 and the discussion that happened after it.
sig-docs discussion
sig-autoscaling discussion
The tl;dr is that this PR is decoupling the docs from the code layout, with the hopes that it allows us to more easily write documentation. Having something that is more easily navigable may help us find the right place to put the documentation.
Note: there are a few bits and pieces that I'm not happy with right now, like the features page. My plan is to get this merged first, and follow up with more PRs to tidy up.
After this PR has been merged, my hope is that some more documentation is written (based on new features, or to clarify common support issues that we get).
Then sometime in the future, we can decide if it makes sense to go with a standalone website, or move to k/website.