A rigorous process for proposing change
Six stages, each with its own owner, so that every change to WEASEL is deliberate, reviewed, and aligned before it ships.
-
Proposal Draft
The requesting team documents the problem, the proposed solution, and the impact, using the official RFC template. The template is 14 sections long. Most proposals use 4 of them.
-
Design Review
The Design Systems team reviews the proposal for consistency with existing patterns and Principles 01 through 06.
-
Alignment
Representatives from every affected team meet to reach consensus. Typically scheduled two to three weeks out, based on calendar availability.
-
Engineering Feasibility
Engineering assesses implementation cost and flags anything that conflicts with existing technical debt, of which there is Foundational, Documented, and Load-Bearing.
-
Re-alignment
Held only if the attendee list from Stage 3 has changed by more than half, which — given average time-to-approval — it usually has.
-
Approval & Publish
The proposal is approved, merged into the design system, and announced in the next Changelog entry, with credit distributed according to whoever wrote the announcement.
In practice
Most changes to WEASEL do not go through this process. A team needs something sooner than eleven weeks, so a maintainer makes the change directly and mentions it in a DM. This is technically against process. It is also, functionally, the process — which is why the system continues to drift out of sync with the documentation describing it, even though the documentation is, itself, accurate about the six stages that would apply if anyone had time to use them.