Sustainable operating model

Problem

The profiler has been developed by a small team with implicit processes for support, bug triage, and release decisions. As the v1.0 launch brings external users, this ad-hoc operating model will not scale: there is no documented on-call rotation for profiler issues, no defined SLA for user-reported semantic type bugs, no release cadence or changelog process, and no escalation path when a profiler defect blocks an analyst's workflow. Without a sustainable operating model that covers support intake, triage ownership, release gating, and communication, the team will oscillate between reactive firefighting and neglect, and the inspector experience will feel unsupported to users.

Context

• A launch can succeed briefly even with fuzzy ownership, but warehouse profiling, semantic inference, and analyst-facing inspect/context artifacts 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/inspect/, schema-context consumers, inspect docs, and core tests, 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 warehouse profiling, semantic inference, and analyst-facing inspect/context artifacts 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