We want to have a more polished Readme inviting users to interact with the Stackable Universe!
To figure out what a good readme looks like for all operators, we will spike it in the secret-operator and in the kafka-operator.
The point is to experiment, and see what content we want, to later make sure we can template a similar layout for all operators.
Inspiration of good READMEs which we could try to imitate: ChrunchyData/postgres-operator, datahub-project/datahub
It could make sense to spike multiple README versions and get feedback.
Ideas (not requirements)
- connect to user intentions when they visit the readme
- find out what the tool is
- no-nonsense information for technical users, what does it do
- It reads a CR and creates XYZ
- is the tool well maintained and reliable?
- make it professional and a bit flashy (the company logo is a good signal)
- it should be visual, not a wall of text
- maybe a gif of an install?
- maybe a diagram?
- show that the operator is part of a larger platform and integrates well with the other operators (i.e. kafka needs a zookeeper and the SDP includes a zookeeper operator)
- this is not for you if ...
- Quickstart
- which flavors of k8s do we support (k3s, managed k8s, Openshift (soon))
- Contributing
- link to blog posts if it makes sense
- (companies that use the product)
Required Content (by topic, not necessarily by title)
The new README version should contain information/sections about:
- Introduction
- Quickstart (stackablectl)
- Technical no-nonsense how does it work
- About the Stackable Data Platform
- List of other operators
- Contributing
- Further Reading
Acceptance Criteria
We want to have a more polished Readme inviting users to interact with the Stackable Universe!
To figure out what a good readme looks like for all operators, we will spike it in the secret-operator and in the kafka-operator.
The point is to experiment, and see what content we want, to later make sure we can template a similar layout for all operators.
Inspiration of good READMEs which we could try to imitate: ChrunchyData/postgres-operator, datahub-project/datahub
It could make sense to spike multiple README versions and get feedback.
Ideas (not requirements)
Required Content (by topic, not necessarily by title)
The new README version should contain information/sections about:
Acceptance Criteria