iBoss/bolt-diy
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Revert "Major UI improvements"

Browse Source 
This reverts commit 6e52114172.
This commit is contained in:
Stijnus
2025-01-28 10:28:45 +01:00
parent 6e52114172
commit 0db9ce2717
45 changed files with 3317 additions and 4287 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
PROJECT.md
View File

@@ -31,7 +31,7 @@ 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.
By linking features with epics, we can keep them together and document *why* we invest work into a particular thing.
## Features (mid-term)
@@ -41,13 +41,13 @@ 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_.
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.
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 🤓