-
Notifications
You must be signed in to change notification settings - Fork 18
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
Added proposal for handbook. #12
Conversation
NOTE: Proposal process will be proposed in another PR |
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.
Love it!
One thing that could be mentioned imho is our user documentation (i.e https://docs.openshift.com/container-platform/4.7/monitoring/understanding-the-monitoring-stack.html). I think we should either explicitly mention it as a non-goal (since I suppose we have processes for that) or mention it as a future item.
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 an awesome initiative @bwplotka, thank you for looking into that 🙂
I have a couple of questions that you might be able to ask in regards to that initiative:
- How I see one part of the project is as a central place that leverages upstream documentation or any other learning resources and supplements it. One thing that might be hard to understand today is the actual boundary between what should be contributed in the handbook and what should be contributed upstream. Do you think it would be meaningful to document that?
- What's the process for upstream enhancements? Should we start drafts in this repository before submitting them to the upstream communities?
|
||
### Flow of Adding/Consuming Documentation to Handbook | ||
|
||
![flow](../../assets/handbook-proposal.png) |
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 handbook was designed to be used in two ways: | ||
|
||
* Through our website `https://rhobs-handbook.netlify.app/`. | ||
* Directly from GitHub UI by navigating to [`content`](https://github.com/rhobs/handbook/tree/main/content) directory. |
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.
What about Github 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.
Do you mean instead of hugo + netlify? We have some amazing pre-processors which makes GitHub UI and website working smoothly (you write docs like for GH UI) (: GH pages would lack of that.
Also we have rdy tooling as other website use it, so we can maintain one way of generating website.
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.
We have some amazing pre-processors which makes GitHub UI and website working smoothly
Interesting, could you send me some links?
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.
❤️ LGTM
I would vote "upstream first" as docs have this nasty tendency of being stale and not updated or propagated. We can always use links and reference issues/PRs/other pages, no? |
## Non-Goals | ||
|
||
* Support other formats than `Markdown,` e.g. Asciidoc | ||
* Precise design proposal process (it will come in a separate proposal). |
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 we align it with Kubernetes Enhancement Proposal process? This way we would have a sort of test bed for writing KEPs and OEPs :)
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.
Yes, that's the plan, just wanted to keep website and proposals idea separate (although the process will be similar)
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.
Just to mention the tooling behind KEPs is https://github.com/kubernetes-sigs/mdtoc, and they use the following scripts to verify/update the format of each KEP:
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.
oh, super useful, will use in next proposal
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.
hm... although it "only" generates TOC, does not verify any format,but cool idea.
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 really like that we are aspiring to follow GitLab's examples of open-first documentation ❤️
A shiny new website alone is not going to solve problems we experience when working with documentation.
Let's try it out 💪
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.
Thanks, everyone for the quick review!
One thing that could be mentioned imho is our user documentation (i.e https://docs.openshift.com/container-platform/4.7/monitoring/understanding-the-monitoring-stack.html). I think we should either explicitly mention it as a non-goal (since I suppose we have processes for that) or mention it as a future item.
Yes good point @jan--f
How I see one part of the project is as a central place that leverages upstream documentation or any other learning resources and supplements it. One thing that might be hard to understand today is the actual boundary between what should be contributed in the handbook and what should be contributed upstream. Do you think it would be meaningful to document that?
I added the handbook-proposal.png with the algorithm to decide. Are there any other rules we can add to make sure it's clearer? (:
What's the process for upstream enhancements? Should we start drafts in this repository before submitting them to the upstream communities?
would vote "upstream first" as docs have this nasty tendency of being stale and not updated or propagated. We can always use links and reference issues/PRs/other pages, no?
Design doc to be added soon in next PR, but the plan is similar to this proposal really. (similar to KEP)
This handbook was designed to be used in two ways: | ||
|
||
* Through our website `https://rhobs-handbook.netlify.app/`. | ||
* Directly from GitHub UI by navigating to [`content`](https://github.com/rhobs/handbook/tree/main/content) directory. |
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.
Do you mean instead of hugo + netlify? We have some amazing pre-processors which makes GitHub UI and website working smoothly (you write docs like for GH UI) (: GH pages would lack of that.
Also we have rdy tooling as other website use it, so we can maintain one way of generating website.
## Non-Goals | ||
|
||
* Support other formats than `Markdown,` e.g. Asciidoc | ||
* Precise design proposal process (it will come in a separate proposal). |
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.
Yes, that's the plan, just wanted to keep website and proposals idea separate (although the process will be similar)
Thanks I think I addressed all comments, PTAL |
Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
👋🏽 I changed:
|
If no objection, will merge in couple of hours/Monday. Anyone want to take a look still? |
/approve |
LGTM |
Co-authored-by: Andrew Pickering <andy.nihon@gmail.com>
* Added proposal for handbook. Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com> * Addressed feedback, moved naming to Monitoring Group. Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com> * Update content/Proposals/Accepted/202106-handbook.md Co-authored-by: Andrew Pickering <andy.nihon@gmail.com> Co-authored-by: Andrew Pickering <andy.nihon@gmail.com>
Please review 🤗
Also Preview: https://deploy-preview-12--rhobs-handbook.netlify.app/proposals/accepted/202106-handbook.md/
Signed-off-by: Bartlomiej Plotka bwplotka@gmail.com