Sustainable operating model

Problem

The dashboard factory workstream operates on tribal knowledge — there is no documented operating model covering who triages template issues, how release cadence decisions are made, or how support requests from users of published templates are routed. As the original contributors rotate to other work, this undocumented process will break down. Without a sustainable operating model, template production and maintenance will stall whenever key individuals are unavailable.

Context

• A launch can succeed briefly even with fuzzy ownership, but repeatable production, review, and publishing of quickstarts and example dashboards will drift quickly without a clear model for maintenance, triage, and decision-making.
• This task is about defining who owns backlog hygiene, review standards, incidents, documentation, and the cadence for future improvements.
• Expected touchpoints include examples/, review/publishing docs, production-line scripts, and dashboard content fixtures, runbooks, planning docs, and team processes that currently rely too heavily on shared memory.

Possible Solutions

• A - Let the current contributors coordinate informally: low overhead, but it becomes brittle as scope and contributors grow.
• B - Recommended: define a lightweight operating model with named owners and cadences: make maintenance, incident response, prioritization, and release decisions explicit.
• C - Centralize all ownership in one person or team indefinitely: clearer in the short term, but usually unsustainable and a bottleneck.

Plan

1. Map the recurring operational decisions around repeatable production, review, and publishing of quickstarts and example dashboards and identify where ownership, handoff, or cadence is currently unclear.
2. Document the operating model: owners, review loops, incident or support handling, documentation upkeep, and backlog-management expectations.
3. Align the model with the actual command/docs/test surfaces that people use day to day so it is operational rather than aspirational.
4. Publish the model in the relevant planning/runbook surfaces and refine it after one real cycle of use.

Implementation Progress

Review Feedback

• [ ] Review cleared