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 1/7] 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 000000000..bacf6581d --- /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 f99948b8e..08659b694 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 From bc3274c77ec0c1f362d7a9fe7e914d3f7f07647c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oliver=20J=C3=A4gle?= Date: Wed, 18 Dec 2024 00:42:56 +0100 Subject: [PATCH 2/7] Satisfy the linter --- app/lib/hooks/useEditChatDescription.ts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/app/lib/hooks/useEditChatDescription.ts b/app/lib/hooks/useEditChatDescription.ts index 25147a020..bb1e8dcc4 100644 --- a/app/lib/hooks/useEditChatDescription.ts +++ b/app/lib/hooks/useEditChatDescription.ts @@ -3,10 +3,10 @@ import { useCallback, useEffect, useState } from 'react'; import { toast } from 'react-toastify'; import { chatId as chatIdStore, - description as descriptionStore, db, - updateChatDescription, + description as descriptionStore, getMessages, + updateChatDescription, } from '~/lib/persistence'; interface EditChatDescriptionOptions { From c78995fee270a7dfbf52f0d407ed244e1c4d5b33 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oliver=20J=C3=A4gle?= Date: Tue, 7 Jan 2025 12:05:16 +0100 Subject: [PATCH 3/7] Clarify PRs in project organization --- PROJECT.md | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/PROJECT.md b/PROJECT.md index bacf6581d..33e697ef6 100644 --- a/PROJECT.md +++ b/PROJECT.md @@ -1,11 +1,13 @@ # 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 ;) +far from being enterprisy- it's still anarchy all over the place 😉 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. +> tl;dr: We've got a project board with epics and features. We use PRs as change log and as materialized features. Find it [here](https://github.com/orgs/stackblitz-labs/projects/4). + +Here's how we structure long-term vision, mid-term capabilities of the software and short term improvements. ## Strategic epics (long-term) @@ -39,14 +41,17 @@ 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. +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 a developer starts working on a feature, a draft-PR *can* be opened asap to share, describe and discuss, how the feature shall be implemented. But: this is not a must. It just helps to get early feedback and get other developers involved. Sometimes, the developer just wants to get started and then open a PR later. + +In a loosely organized project, it may as well happen that multiple PRs are opened for the same feature. This is no real issue: Usually, peoply being passionate about a solution are willing to join forces and get it done together. And if a second developer was just faster getting the same feature realized: Be happy that it's been done, close the PR and look out for the next feature to implement 🤓 + +## PRs as change log -Once it’s merged, a squashed commit contains the whole PR description which allows for a good change log. +Once a PR is merged, a squashed commit contains the whole PR description which allows for a good change log. +All authors of commits in the PR are mentioned in the squashed commit message and become contributors 🙌 From 8d1cc491404485a80adda0cd012c8e1591d9fbd8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oliver=20J=C3=A4gle?= Date: Tue, 7 Jan 2025 12:06:11 +0100 Subject: [PATCH 4/7] Add epic template --- .github/ISSUE_TEMPLATE/epic.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/epic.md diff --git a/.github/ISSUE_TEMPLATE/epic.md b/.github/ISSUE_TEMPLATE/epic.md new file mode 100644 index 000000000..770ad0bf5 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/epic.md @@ -0,0 +1,23 @@ +--- +name: Epic +about: Epics define long-term vision and capabilities of the software. They will never be finished but serve as umbrellas for features. +title: '' +labels: + - epic +assignees: '' +--- + +# Strategic Impact + +<-- Why does this area matter? How is it integrated into the product or the development process? What would happen if we ignore it? --> + +# Target Audience + + + +# Capabilities + + From c6254b79403744a10181404ecfbed73d38232516 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oliver=20J=C3=A4gle?= Date: Tue, 7 Jan 2025 12:08:13 +0100 Subject: [PATCH 5/7] Remove bolt.new references from bug template --- .github/ISSUE_TEMPLATE/bug_report.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml index 37ebae5a8..8b66eb1bc 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.yml +++ b/.github/ISSUE_TEMPLATE/bug_report.yml @@ -6,8 +6,8 @@ body: value: | Thank you for reporting an issue :pray:. - This issue tracker is for bugs and issues found with [Bolt.new](https://bolt.new). - If you experience issues related to WebContainer, please file an issue in our [WebContainer repo](https://github.com/stackblitz/webcontainer-core), or file an issue in our [StackBlitz core repo](https://github.com/stackblitz/core) for issues with StackBlitz. + This issue tracker is for bugs and issues found with [Bolt.diy](https://bolt.diy). + If you experience issues related to WebContainer, please file an issue in the official [StackBlitz WebContainer repo](https://github.com/stackblitz/webcontainer-core). The more information you fill in, the better we can help you. - type: textarea From a0596bbad376383b292836683428f69cdbbe5832 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oliver=20J=C3=A4gle?= Date: Tue, 7 Jan 2025 12:13:37 +0100 Subject: [PATCH 6/7] Fix typos in epic template --- .github/ISSUE_TEMPLATE/epic.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/epic.md b/.github/ISSUE_TEMPLATE/epic.md index 770ad0bf5..2727594f4 100644 --- a/.github/ISSUE_TEMPLATE/epic.md +++ b/.github/ISSUE_TEMPLATE/epic.md @@ -1,6 +1,6 @@ --- name: Epic -about: Epics define long-term vision and capabilities of the software. They will never be finished but serve as umbrellas for features. +about: Epics define long-term vision and capabilities of the software. They will never be finished but serve as umbrella for features. title: '' labels: - epic @@ -9,7 +9,7 @@ assignees: '' # Strategic Impact -<-- Why does this area matter? How is it integrated into the product or the development process? What would happen if we ignore it? --> + # Target Audience From 05eca7cde6739fb7ec0e627ae2bd2a4041c05cd4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oliver=20J=C3=A4gle?= Date: Tue, 7 Jan 2025 13:04:44 +0100 Subject: [PATCH 7/7] Add feature issue template --- .github/ISSUE_TEMPLATE/feature.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/feature.md diff --git a/.github/ISSUE_TEMPLATE/feature.md b/.github/ISSUE_TEMPLATE/feature.md new file mode 100644 index 000000000..8df8c3217 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature.md @@ -0,0 +1,28 @@ +--- +name: Feature +about: A pretty vague description of how a capability of our software can be added or improved. +title: '' +labels: + - feature +assignees: '' +--- + +# Motivation + + + +# Scope + + + +# Options + + + +# Related + +