Merge pull request #809 from stackblitz-labs/807-transparency-about-development

docs: document how we work

.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

.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 umbrella 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
+
+<!-- Who benefits most from improvements in this area?
+
+Usual values: Software Developers using the IDE | Contributors -->
+
+# Capabilities
+
+<!-- which existing capabilities or future features can be imagined that belong to this epic? This list serves as illustration to sketch the boundaries of this epic. 
+Once features are actually being planned / described in detail, they can be linked here. -->

.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
+
+<!-- What capability should be either established or improved? How is life of the target audience better after it's been done? -->
+
+# Scope
+
+<!-- This is kind-of the definition-of-done for a feature. 
+Try to keep the scope as small as possible and prefer creating multiple, small features which each solve a single problem / make something better
+-->
+
+# Options
+ 
+<!-- If you already have an idea how this can be implemented, please describe it here. 
+This allows potential other contributors to join forces and provide meaningful feedback prio to even starting work on it.
+-->
+
+# Related
+
+<!-- Link to the epic or other issues or PRs which are related to this feature. -->

PROJECT.md

@@ -0,0 +1,57 @@
+# 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- it's still anarchy all over the place 😉
+
+But we need to organize ourselves somehow, right?
+
+> 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)
+
+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, 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 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 🙌

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
 

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 {