Part 3 · 1 chapters · ~15 min

Versioning, Adoption and Governance

The process layer: a proposal path with a week's triage, a written review bar, semver with codemods and a system train, the three contribution models and the hybrid most systems land on, adoption and deviation measured by a scanner, and the weekly ritual that is the governance.

7

Governance: how the system changes

the process layer
  1. The proposal: a template (use case, screens, components tried, proposed API, accessibility considerations); triage within a week into accept, contribute, decline with a pattern, or defer with a date. A queue with latency over two weeks is where forks begin (the Platformization course part 7).
  2. The review bar, written: serves more than one screen (a rule of two for components); tokens only; keyboard-complete and named (part 2); every state designed (part 4); stories, tests and documentation; no duplicate of an existing component under another name. The Big-company FE course part 7's bar with the system's additions.
  3. Versioning and release: semver honoured (a broken minor teaches consumers to pin: the Architecture course part 4); a changelog with the migration per breaking change; a codemod for the mechanical cases (the Big-company FE course part 4); a dated deprecation; a system release train so consumers can plan. A breaking change without a codemod outsources the system's work to its consumers.
  4. Contribution models: centralised (coherent, slow, a queue at scale), federated (fast, coherence depends on the bar), hybrid (the team owns tokens, primitives and core components; contributions for the long tail reviewed to the bar and adopted when they prove out). Most systems past a few teams land on hybrid; the contribution guide is governance's most-read document.
  5. Adoption measured, not surveyed: percentage of UI from the system by instance count per surface and team (a scanner over the repo); deviation as className overrides of tokens, local re-implementations, escape-hatch usage and hex values in component CSS; release-to-full-adoption time; proposal age. The most-overridden component has the wrong API.
  6. The weekly ritual: read the dashboard, triage proposals, review contributions, pick the roadmap item the deviations point at. Governance that is not a weekly habit is a document nobody reads; the documents are its minutes.
the exercise
Find the last three times a feature team needed something the system lacked. For each, how long until the system answered, and what did the team do in the meantime? The second answer is your fork rate.
GOVERNANCE: HOW THE SYSTEM CHANGES
proposals, review, versioning, migration, contribution models, and the measures that say it is alive
swipe the figure sideways, or tap expand for full screen
1/6
the proposal
The proposal: a feature team needs a component or a variant the system lacks; they file a proposal (a template: the use case, the screens, the existing components tried, the proposed API, the accessibility considerations); the system team triages within a week (accept into the roadmap, accept as a contribution, decline with a pattern that solves it, or defer with a date). A proposal queue with latency over two weeks is where forks begin (the Platformization course part 7).