WIP: Add information about development process

stackblitz-labs · Jan 7, 2025 · f20fff1 · f20fff1
1 parent 7004c89
commit f20fff1
Show file tree

Hide file tree

Showing 2 changed files with 59 additions and 0 deletions.
diff --git a/PROJECT.md b/PROJECT.md
@@ -0,0 +1,52 @@
+# Project management of bolt.diy
+
+First off: this sounds funny, we know. "Project management" comes from a world of enterprise stuff and this project is
+far from being enterprisy ;)
+
+But we need to organize ourselves somehow, right?
+
+So here's how we structure long-term vision, mid-term capabilities of the software and short term improvements.
+
+## Strategic epics (long-term)
+
+Strategic epics define areas in which the product evolves. Usually, these epics don’t overlap. They shall allow the core
+team to define what they believe is most important and should be worked on with the highest priority.
+
+You can find the [epics as issues](https://github.com/stackblitz-labs/bolt.diy/labels/epic) which are probably never
+going to be closed.
+
+What's the benefit / purpose of epics?
+
+1. Prioritization
+
+E. g. we could say “managing files is currently more important that quality”. Then, we could thing about which features
+would bring “managing files” forward. It may be different features, such as “upload local files”, “import from a repo”
+or also undo/redo/commit.
+
+In a more-or-less regular meeting dedicated for that, the core team discusses which epics matter most, sketch features
+and then check who can work on them. After the meeting, they update the roadmap (at least for the next development turn)
+and this way communicate where the focus currently is.
+
+2. Grouping of features
+
+By linking features with epics, we can keep them together and document *why* we invest work into a particular thing.
+
+## Features (mid-term)
+
+We all know probably a dozen of methodologies following which features are being described (User story, business
+function, you name it).
+
+However, we intentionally describe features in a more vague manner. Why? Everybody loves crisp, well-defined
+acceptance-criteria, no? Well, every product owner loves it. because he knows what he’ll get once it’s done.
+
+But: **here is no owner of this product**. Therefore, we grant *maximum flexibility to the developer contributing a
+feature* – so that he can bring in his ideas and have most fun implementing it.
+
+The feature therefore tries to describe *what* should be improved but not in detail *how*.
+
+## PRs as materialized features (short-term)
+
+Once a developer starts working on a feature, he/she can open a draft-PR asap to discuss / describe / share, how he/she
+is going to tackle the problem.
+
+Once it’s merged, a squashed commit contains the whole PR description which allows for a good change log.
diff --git a/README.md b/README.md
@@ -27,6 +27,13 @@ bolt.diy was originally started by [Cole Medin](https://www.youtube.com/@ColeMed
 
 [Join the bolt.diy community here, in the oTTomator Think Tank!](https://thinktank.ottomator.ai)
 
+## Project management
+
+Bolt.diy is a community effort! Still, the core team of contributors aims at organizing the project in way that allows
+you to understand where the current areas of focus are.
+
+If you want to know what we are working on, what we are planning to work on, or if you want to contribute to the
+project, please check the [project management guide](./PROJECT.md) to get started easily.
 
 ## Requested Additions