Skip to content

Commit 85d864f

Browse files
Digitl-AlchemystDigitl-Alchemyst
authored
Merge pull request stackblitz-labs#809 from stackblitz-labs/807-transparency-about-development
docs: document how we work
2 parents fad4197 + 05eca7c commit 85d864f

File tree

6 files changed

+119
-4
lines changed

6 files changed

+119
-4
lines changed

‎.github/ISSUE_TEMPLATE/bug_report.yml

+2-2
Original file line numberDiff line numberDiff line change
@@ -6,8 +6,8 @@ body:
66
value: |
77
Thank you for reporting an issue :pray:.
88
9-
This issue tracker is for bugs and issues found with [Bolt.new](https://bolt.new).
10-
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.
9+
This issue tracker is for bugs and issues found with [Bolt.diy](https://bolt.diy).
10+
If you experience issues related to WebContainer, please file an issue in the official [StackBlitz WebContainer repo](https://github.com/stackblitz/webcontainer-core).
1111
1212
The more information you fill in, the better we can help you.
1313
- type: textarea

‎.github/ISSUE_TEMPLATE/epic.md

+23
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
---
2+
name: Epic
3+
about: Epics define long-term vision and capabilities of the software. They will never be finished but serve as umbrella for features.
4+
title: ''
5+
labels:
6+
- epic
7+
assignees: ''
8+
---
9+
10+
# Strategic Impact
11+
12+
<!-- Why does this area matter? How is it integrated into the product or the development process? What would happen if we ignore it? -->
13+
14+
# Target Audience
15+
16+
<!-- Who benefits most from improvements in this area?
17+
18+
Usual values: Software Developers using the IDE | Contributors -->
19+
20+
# Capabilities
21+
22+
<!-- 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.
23+
Once features are actually being planned / described in detail, they can be linked here. -->

‎.github/ISSUE_TEMPLATE/feature.md

+28
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
---
2+
name: Feature
3+
about: A pretty vague description of how a capability of our software can be added or improved.
4+
title: ''
5+
labels:
6+
- feature
7+
assignees: ''
8+
---
9+
10+
# Motivation
11+
12+
<!-- What capability should be either established or improved? How is life of the target audience better after it's been done? -->
13+
14+
# Scope
15+
16+
<!-- This is kind-of the definition-of-done for a feature.
17+
Try to keep the scope as small as possible and prefer creating multiple, small features which each solve a single problem / make something better
18+
-->
19+
20+
# Options
21+
22+
<!-- If you already have an idea how this can be implemented, please describe it here.
23+
This allows potential other contributors to join forces and provide meaningful feedback prio to even starting work on it.
24+
-->
25+
26+
# Related
27+
28+
<!-- Link to the epic or other issues or PRs which are related to this feature. -->

‎PROJECT.md

+57
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
# Project management of bolt.diy
2+
3+
First off: this sounds funny, we know. "Project management" comes from a world of enterprise stuff and this project is
4+
far from being enterprisy- it's still anarchy all over the place 😉
5+
6+
But we need to organize ourselves somehow, right?
7+
8+
> 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).
9+
10+
Here's how we structure long-term vision, mid-term capabilities of the software and short term improvements.
11+
12+
## Strategic epics (long-term)
13+
14+
Strategic epics define areas in which the product evolves. Usually, these epics don’t overlap. They shall allow the core
15+
team to define what they believe is most important and should be worked on with the highest priority.
16+
17+
You can find the [epics as issues](https://github.com/stackblitz-labs/bolt.diy/labels/epic) which are probably never
18+
going to be closed.
19+
20+
What's the benefit / purpose of epics?
21+
22+
1. Prioritization
23+
24+
E. g. we could say “managing files is currently more important that quality”. Then, we could thing about which features
25+
would bring “managing files” forward. It may be different features, such as “upload local files”, “import from a repo”
26+
or also undo/redo/commit.
27+
28+
In a more-or-less regular meeting dedicated for that, the core team discusses which epics matter most, sketch features
29+
and then check who can work on them. After the meeting, they update the roadmap (at least for the next development turn)
30+
and this way communicate where the focus currently is.
31+
32+
2. Grouping of features
33+
34+
By linking features with epics, we can keep them together and document *why* we invest work into a particular thing.
35+
36+
## Features (mid-term)
37+
38+
We all know probably a dozen of methodologies following which features are being described (User story, business
39+
function, you name it).
40+
41+
However, we intentionally describe features in a more vague manner. Why? Everybody loves crisp, well-defined
42+
acceptance-criteria, no? Well, every product owner loves it. because he knows what he’ll get once it’s done.
43+
44+
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.
45+
46+
The feature therefore tries to describe *what* should be improved but not in detail *how*.
47+
48+
## PRs as materialized features (short-term)
49+
50+
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.
51+
52+
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 🤓
53+
54+
## PRs as change log
55+
56+
Once a PR is merged, a squashed commit contains the whole PR description which allows for a good change log.
57+
All authors of commits in the PR are mentioned in the squashed commit message and become contributors 🙌

‎README.md

+7
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,13 @@ bolt.diy was originally started by [Cole Medin](https://www.youtube.com/@ColeMed
2727

2828
[Join the bolt.diy community here, in the oTTomator Think Tank!](https://thinktank.ottomator.ai)
2929

30+
## Project management
31+
32+
Bolt.diy is a community effort! Still, the core team of contributors aims at organizing the project in way that allows
33+
you to understand where the current areas of focus are.
34+
35+
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
36+
project, please check the [project management guide](./PROJECT.md) to get started easily.
3037

3138
## Requested Additions
3239

‎app/lib/hooks/useEditChatDescription.ts

+2-2
Original file line numberDiff line numberDiff line change
@@ -3,10 +3,10 @@ import { useCallback, useEffect, useState } from 'react';
33
import { toast } from 'react-toastify';
44
import {
55
chatId as chatIdStore,
6-
description as descriptionStore,
76
db,
8-
updateChatDescription,
7+
description as descriptionStore,
98
getMessages,
9+
updateChatDescription,
1010
} from '~/lib/persistence';
1111

1212
interface EditChatDescriptionOptions {

0 commit comments

Comments
 (0)