Our roadmap typically looks out 12-18 months, and we establish topics we want to work on.
We develop our roadmap based on the findings we made over the course of the last year, and what we heard from the users and collaborators in issues, in face-to-face discussions, and other media.
When we execute on our roadmap, we keep learning and our assessment of some topics listed changes. As a result, we may add or drop topics as we go. After around 12 months we come together to develop the next roadmap.
We describe some initiatives as "investigations" or "explorations" which means our goal in the next few months is to better understand the problem and potential solutions before scheduling actual feature work. Once an investigation is done, we will update our plans, either deferring the initiative or committing to it.
Before we go into the details, let's start with our values that guide the development of Nebari.
- We strive for a smooth and productive experience for end-users - this places user experience at the core of everything we build.
- Performance trumps functionality.
- The documentation must be as transparent & accessible as possible.
- We build on open source software. In addition, any changes we make to open source software will be made in public and/or contributed upstream, so our users continue to have access to them regardless of where their infrastructure is.
- We must not directly depend on proprietary cloud vendor specific products or APIs. This ensures that users can port their infrastructure to any cloud provider of their choice, or run it on their own hardware with purely open source software.
(Definitions of MUST, MUST NOT, SHOULD, MAY, are defined in RFC 2119)
We use the same legends across our project boards to keep planning and messages consistent
| Mark | Description |
|---|---|
| 🗃 | work not started -usually within the backlog |
| 📬 | scoped and due to work on |
| 🏗 | ongoing work |
| ✅ | work completed |
| ⛔️ | blocked item |
| 🔮 | stretch goal |