Proposal: Process Structure (Milestones, Priority Triage & Release Pipeline)

[iroQuai]

Hi everyone,

As CWNG is developing at record speed, the project is evolving fast. To ensure CWNG remains a rock-solid, reliable "drop-in replacement" for Calibre Web without getting fragmented, I’d like to propose a few lightweight process improvements.

The goal isn't to slow development down or maintain rigid roadmaps with dates, but to introduce a result-driven structure.

Each of the three proposals below can function independently, but their true strength lies in how they reinforce each other: Triage filters daily noise, the :dev branch safeguards stability, and Milestones provide macro direction.

Proposal: Process Structure (Priority Triage, Release Pipeline & Milestones)

1. Explicit Priority Triage

With issues and suggestions coming in fast, establishing a clear priority order ensures stability always comes before speed:

1. Security Risks & Critical Regressions (Highest Priority)
2. Bugfixes & Core Stability
3. Active Milestone Tasks
4. New Feature Requests / Experiments

Note: Clear triage maintains long-term focus and prevents "scope drift", ensuring rapid development stays aligned with core priorities rather than chasing every individual request.

2. Leveraging the :dev Branch for Release Discipline

For CWNG to truly serve as a seamless, reliable "drop-in replacement" for Calibre Web (Automated), everyday users need a rock-solid build they can rely on without unexpected breakages. Since we already have a dev branch/tag, we can use it to separate rapid experimentation from production stability:

• dev / nightly tag: Used for rapid AI commits, quick iterations, and experimental fixes.
• main / latest tag: Only updated after changes in dev have been human-tested and confirmed stable.

Note: The current activity seen on Discord and the issues tab indicates there are more than enough people willing to run the dev branch and help test features to drive this project forward.

3. Sequential Milestones (Macro Direction)

Instead of date-driven roadmaps, we could group effort into clear sequential Milestones. This gives everyone a shared view of the project's macro priorities without adding rigid administrative overhead. Some suggestions on possible milestones:

• Milestone 1: Performance & Core Architecture: Database performance and backend optimization to keep the base rock-solid.
• Milestone 2: UI Modernization & Polish: Finetuning the modern interface and integrating the revamped Settings/Admin panels.
• Milestone 3: Three-Way Syncing: Solidifying full, seamless sync support across KOReader, Kobo, and the Webreader.

Note: GitHub has a built-in Milestones feature for this, though that might be overkill if we want to keep things lightweight—a simple list or project board works just as well.

---

While each point can be adopted individually, adopting them together wraps the incredible speed of AI-assisted development in a strong safety net: everyday users get maximum stability, and contributors know where their effort is needed most.

Curious to hear your thoughts on this setup!

[Thovi98]

Having a difference between dev and production would be a great enhancement! It would be good to be able to update knowing that the changes have been effectively tested. I rely heavily on the Kobo sync feature and the Hardcover annotations sync. Whenever I've to update my instance, I fear to break something now.

pinging @new-usemame as I'm not sure you're looking to discussions.

[iroQuai]

I did ping him on discord, and also im referencing this topic in quite some other conversations with (the AI-version of) @new-usemame. Hope it helps :)

[iroQuai]

I feel the need to resurface this because of this: within a few days i see two possible milestones around multi user setups (#2085 & #1939), both worth investigating, but both quite some work to realise properly and fully. It seems to me there is a solid and serious response from the dev in both threads, but lacking signes of realisation that dev focus, time and skill is always limited (even with the help of AI) and a project can never develop in all directions at the same time.

The proposal above suggest to take this into account, weigh different suggestions and issues against eachother and thus create a better focus and aim on what to use valuable resources on.

I still wonder what is @new-usemame's take on this?

[new-usemame]

@iroQuai @Thovi98 — you were both right to wonder whether anyone was reading this tab, and the honest answer is no. I checked before replying: 13 discussions exist, 12 were opened by users, and I have replied to zero of them. The only thing I ever posted here was the welcome note in May.

That was not a judgement about the tab's value. The triage board that decides what I work on each day is built from the issues list and the pull-requests list. Discussions were never a third source, so nothing here ever reached it — the same blind spot pull requests had until it was found and fixed. I'm closing it at that level rather than by promising to remember, so this stops being a thing you have to ping about.

On the proposal itself:

1. Priority triage. The order you describe is close to the one already in use — anything broken (red CI, a regression) preempts everything; then a person waiting on a reply; then bugs ranked by how many people they unblock (reactions plus distinct commenters); then features. What's missing is not the ordering, it's that it has never been written down anywhere you can see, so it looks arbitrary from outside. That is worth fixing and I'd rather publish the actual rule than invent a nicer one.

2. The dev/latest split. This one already exists, and I think it's under-communicated rather than absent:

• :dev moves on every merge to main (also published as :dev-<n> and an immutable :sha-<commit>).
• :latest only moves when a versioned GitHub Release is published — never from a merge.
• There is a household instance tracking :dev full-time as a canary, on a real library with Kobo and KOReader in the loop, which is where a surprising number of these bugs get caught before a release exists.

@Thovi98 — for your case specifically, the thing that removes the fear today is pinning to a version rather than a floating tag: ghcr.io/new-usemame/calibre-web-nextgen:v4.1.43. Then an update is something you choose, and you can read what changed first. Kobo sync and Hardcover annotation sync are the two paths I treat as highest-blast-radius, so if either breaks in a release, say so and it goes to the front of the queue.

3. Milestones. I'm wary of the bookkeeping, but the underlying point in your second comment is the correct criticism: two large multi-user items (#2085, #1939) each got a serious answer, and a serious answer reads like a commitment when in fact only one thing can be in flight at a time. The gap is that I'm not saying out loud which one is actually being worked and which is parked. That is a communication fix I can make immediately, and it's cheaper than a milestone board.

So: agreed on 1 and 3 as stating what's already true, and 2 largely exists — tell me if the version-pin answer covers the stability worry or whether what you actually want is a slower :latest with a human sign-off gate, because that's a different and bigger change and I'd rather hear it from the people running it than decide it alone.