Roadmap

[marcpope]

This is an un-official roadmap of features I'm actively planning/working on:

Reworking color palette for both dark mode and light modes.
The dark/light mode color scheme is all over the place. Not a lot of attention to detail has been put into design as much as funcitonality. As BBS gets more stable, we'll be looking at refining the interface and improving design.

Branding re-work
The branding for the app will be more integrated into the public website, wiki and other locations as I get time. A more immediate focus is working to let users re-brand the interface better, improve responsive design elements and more.

OS Level Snapshots
One of my big goals is for BBS to do more enterprise level features like snap-shot of an entire partition and backing it up. This is a major feature that will require a lot of planning. There would be an .ISO that would also emergency boot and restore of partitions by connecting to the server. Also need to look into the feasability that it could support 2FA, SSO features, which might be more challenging.

Hosted Platform
Over the past 3 months, I've been building out an auto-provisioning platform where we will host and support BBS for you. It will offer enterprise-level hosting, highly robust backup storage levels and SLAs on support and hot-fixes.

[c0dr1ver]

Hi @marcpope

Could we please coordinate changes to main a bit more carefully? (PR #225 is a good example)

The PR keeps becoming conflicted because main is being updated in the same UI/style areas that the PR is changing. For example:

• src/Views/schedules/week.php

  • PR Redesign backup schedules page #225 replaces the old schedule chart/header styling and uses card-head-gradient plus the new .schedule-mini-card styling.
  • Recent main updates changed the old .sched-accent-header dark-mode block in the same file, which creates a delete/modify conflict.

• public/css/style.css

  • Recent changes to shared card/header dark-mode styles overlap with the schedule redesign direction.

• src/Views/dashboard/index.php

  • Dashboard style updates are part of the same visual system that the schedule page redesign is trying to align with.

The issue is not that main should never change, of course. The problem is that repeated updates to the same area while a UI PR is in review force the PR author to resolve the same conflicts over and over, then retest desktop/mobile, Docker/bare metal behavior again. That makes the work slower and increases the risk of accidental regressions.

If we want this to be collaborative product work rather than “vibe coding”, it would help to either:

1. pause overlapping changes to main until any PR is merged/rejected, or
2. coordinate the exact style changes in the PR branch, or
3. merge the shared style changes first, then let the schedule redesign rebase once against a stable base.

I’m happy to adapt the PR to the latest design direction, but we need a stable integration point for the same files/code paths.

[marcpope]

I asked that you wait until some major UI changes are complete. And complaining about Vibe coding is insulting. I'm not sitting back on the couch watching AI code this, I have 8 years into this product. Sure, every programmer uses AI now. But I am a full-stack dev with 30 years of applications experience. I am moving at a fast pace. I have 10 other commercial projects I am working on plus a full time job. So have a little grace, please.

[c0dr1ver]

Dear Marc

I didn’t intend to offend you or question your experience.

That said, pushing small changes directly to main that end up breaking a 500-line pull request - which has already gone through multiple stages of testing - feels a bit disproportionate from my perspective. And judging by the commit history, this seems to happen from time to time.

Moreover, some of the recent changes introduced UI issues that could likely have been avoided if the branch I previously submitted hadn’t been declined.

I truly respect your experience and I’m grateful for the product you’ve built. My goal here was simply to contribute and help improve things. I just haven’t come across a workflow where a minor design tweak ends up invalidating a large, already-reviewed PR.

[MegaV0lt]

For the OS Level Snapshots i suggest to consider to exclude configurable files or directories

Currently i use fsarchiver for my partition backups: https://www.fsarchiver.org/quickstart/
fsarchiver also supports compression and encryption

Maybe a Plugin for fsarchiver would also do the job?