Sustainable operating model

Problem

Chart interaction behavior (tooltips, hover states, click actions, keyboard navigation) and accessibility polish are currently maintained ad hoc — fixes land when someone notices a problem, with no defined ownership, triage cadence, or release process. As the user base grows post-v1.0, interaction and accessibility issues will arrive faster than ad hoc responses can handle. Without a documented operating model that assigns ownership for interaction/accessibility work, defines how incoming issues are triaged, and establishes a release cadence for polish improvements, these concerns will consistently lose priority to feature work and accumulate as user-facing rough edges.

Context

• A launch can succeed briefly even with fuzzy ownership, but visual language, chart defaults, interaction behavior, and differentiated styling 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 dataface/core/render/chart/, chart design docs, examples, and visualization test coverage, 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 visual language, chart defaults, interaction behavior, and differentiated styling 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