Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: document how we work #809

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions PROJECT.md
Original file line number Diff line number Diff line change
@@ -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.
7 changes: 7 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -12,6 +12,13 @@ bolt.diy was originally started by [Cole Medin](https://www.youtube.com/@ColeMed

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 - Feel Free to Contribute!

2 changes: 1 addition & 1 deletion app/commit.json
Original file line number Diff line number Diff line change
@@ -1 +1 @@
{ "commit": "e064803955604198c6aac7b257efd0ad8503cb73", "version": "0.0.3" }
{ "commit": "704aee4390f420ce8032a1a0e2e76fb98b9ad566" }
5 changes: 3 additions & 2 deletions app/lib/hooks/useEditChatDescription.ts
Original file line number Diff line number Diff line change
@@ -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 {
@@ -92,6 +92,7 @@ export function useEditChatDescription({
}

const lengthValid = trimmedDesc.length > 0 && trimmedDesc.length <= 100;

// Allow letters, numbers, spaces, and common punctuation but exclude characters that could cause issues
const characterValid = /^[a-zA-Z0-9\s\-_.,!?()[\]{}'"]+$/.test(trimmedDesc);