From f20fff1443962b4b571b1b47562016f782011e08 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oliver=20J=C3=A4gle?= Date: Wed, 18 Dec 2024 00:42:34 +0100 Subject: [PATCH] WIP: Add information about development process --- PROJECT.md | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 7 +++++++ 2 files changed, 59 insertions(+) create mode 100644 PROJECT.md diff --git a/PROJECT.md b/PROJECT.md new file mode 100644 index 00000000..bacf6581 --- /dev/null +++ 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 index f99948b8..08659b69 100644 --- 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