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.

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 which are probably never going to be closed.

What's the benefit / purpose of epics?

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.

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 🙌

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!