Dataface Tasks
    Heartbeat snapshot (JSON)

    Sustainable operating model

    IDM4_V1_0_LAUNCH-DFT_CORE-03
    Statusnot_started
    Priorityp1
    Milestonem4-v1-0-launch
    Ownerhead-of-engineering

    Problem

    The project has no documented operating model for how YAML schema versions are managed, when migrations are shipped, how support requests are triaged, or what the release cadence is. As the user base grows post-v1.0, ad-hoc decision-making around versioning and migration support will not scale — leading to inconsistent upgrade experiences, unclear SLAs for bug fixes, and contributor confusion about when and how to make breaking schema changes.

    Context

    • A launch can succeed briefly even with fuzzy ownership, but the YAML contract, compiler/normalizer, execution adapters, and release/versioning 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/, schema/compiled types, docs, and core test suites, 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 the YAML contract, compiler/normalizer, execution adapters, and release/versioning 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