Governance

I do. The system is a personal design system; it ships on my personal site and the projects I work on. There is no design system team; there is no design ops function. The maintainer is the same person who writes the code, ships the case studies, and writes the docs.

Decisions are made in public. Every change is an issue; every issue is a discussion. The maintainer has the final call, but the call is always explained, and the explanation is always linked from the changelog.

• Token changes require a written RFC, posted as an issue, open for 7 days.
• Component changes require a written issue, open for 1 day.
• Doc changes require a PR, no issue needed.
• Bug fixes are merged as soon as they're reviewed.

Every quarter, the system is reviewed. The review has three questions:

1. Are the sacred tokens still right?
2. Are there components that haven't shipped? They get cut.
3. Are there pages in the docs that haven't been read? They get cut.

The review is published in the changelog. The system is allowed to shrink. It is not allowed to grow without a 30-day commitment.

Components and tokens can be deprecated. The deprecation is announced in the changelog with a 30-day notice. After 30 days, the component is removed. The deprecation includes a migration path: where the code that used the deprecated component should go instead.