Define ROADMAP#111
Conversation
The roadmap helps to strength the direction of the project and gives an overview of the next upcoming features. This first versions aims to collect ideas and issues raised during the past months of discussions. Signed-off-by: Alice Frosi <afrosi@redhat.com>
|
I created phases, but thinking more about it they are more categories. Phases implies kind of one phase after the other when some of them can be swapped. |
Yeah agree. Perhaps we should just have them be categories then. I struggle whether the roadmap should be timeline-based or category-based. Timeline-based makes sense for a roadmap, but e.g. I wouldn't try to have stuff past a e.g. "phase 3" though. It's just too hard to predict where focus will need to be as requirements from the various places the operator ends up getting used become clearer (e.g. I can imagine #17 taking priority earlier if it calls for it). But maybe that's for the best anyway. I'm not sure we should overcharge the doc either with so many details and issue links. What is super important to me and which should be in there also is surfacing bootc features to the operator. A huge one is soft-reboot, which already works today at the bootc layer. But also e.g. pushing forward bootc-dev/bootc#22. Both those things are highly relevant and desirable for K8s clusters. OK, I started a draft locally with some of this. Interested in your thoughts though on timeline vs category. |
2 participants
The roadmap helps to strength the direction of the project and gives an overview of the next upcoming features. This first versions aims to collect ideas and issues raised during the past months of discussions.
Fixes: #79