Closed c-pius closed 2 days ago
The Control Plane Quick Start
document should be dropped, I've checked it and it is just a narrowed-down version of the developer docu that we have.
Our user documentation should rather focus on what Module Teams can do to leverage additional KLM functionalities, but we are moving towards separation of that topic. We've already deprecated the CustomStateCheck feature so CustomResourcePolicy is the only one left. We can consider adding something for "unmanaging" the modules.
We decided to leave only one of the tutorials. I consider it complete with the PR splitting the docs
into user
and contributor
. Still, I would like to work more on the /docs/user
folder docu and some unifications in the /docs/contributor
but it is a different story and requires a separate issue. I'm closing this one having the follow-ups in mind.
Description
With https://github.com/kyma-project/lifecycle-manager/blob/main/docs/developer-tutorials/local-test-setup.md we have a very comprehensive document on how to:
At the same time we have https://github.com/kyma-project/lifecycle-manager/blob/main/docs/user-tutorials/01-10-control-plane-quick-start.md where I am not sure what the real purpose is, considering the document above. The context section states more or less the same outline, but the actual content is not as extensive and even a bit confusing at some points.
We need to think about aligning both documents. But first we should clarify what our expected audience is. What distinguishes a KLM "user" from a "developer". What kind of documentation do we need for either of those?
Reasons
We want a transparent and convenient-to-navigate documentation for KLM
Assignees
@kyma-project/technical-writers
Acceptance Criteria