Closed
Description
Documentation is necessary in order to properly release a project, announce it to the world, and drive adoption. Good documentation is also very helpful for users and maintainers to understand design intent, which can sometimes help explain to users why they see certain behaviors or to maintainers, provide context around questions in code.
As part of a v1.0 release, we need to have documentation that covers the following:
- Collect all 1.0.0 draft docs into a presentable hierarchy #1305
- Docs: General/Product #1122
- Docs: Quickstart Guide #1123
- Reference
- Docs: Overall architecture documentation #1124
- Docs: Catalogd API reference #1125 (should be done after Catalogd API review epic is completed)
- Docs: Operator-Controller API reference #1126 (should be done after the Operator-Controller API review epic is completed)
- Docs: OLM v1 limitations #984
- Docs: Choosing what catalog ClusterExtensions come from #1132
- Howto
- Docs: Pin to a specific version #1127
- Docs: Accept automatic upgrades within a specific z-stream #1128
- Docs: Accept automatic upgrades within a specific channel #1129
- Docs: Derive minimal service account needed to install a bundle #1130
- Docs: Accepts automatic updates within a version range #1217
- Docs: Downgrade a ClusterExtension #1229
Current documentation is posted up at https://operator-framework.github.io/operator-controller/
New docs should be placed in docs/drafts
Metadata
Metadata
Assignees
Type
Projects
Status
Implementing