Contributing a new component variant

WHAT THIS TESTS: This evaluates whether you understand that a design system is a governed shared product, so contributions follow a process, not just a code change.

A GOOD ANSWER COVERS: Begin before coding by reading the contribution guidelines and raising the proposal with the system's maintainers and designers, often via an issue or RFC, to confirm the variant is genuinely reusable rather than a one-off, and to agree on naming and the API shape. Once aligned, implement the variant following the existing component's prop and API conventions and using design tokens rather than hard-coded values, so it stays consistent and themeable. Add or update the Storybook stories covering the new variant's states, write or update documentation and prop tables, ensure accessibility is preserved, and add tests including visual regression. Then open a pull request referencing the discussion, request review from the maintainers, address feedback, and let it merge and release through the system's normal versioning. Communicate the addition in the changelog so consumers discover it.

COMMON WRONG ANSWERS: Jumping straight to a PR or, worse, forking the component locally without involving maintainers, producing a one-off that fragments the system. Hard-coding values instead of tokens. Skipping stories, docs, accessibility, or tests. Ignoring naming and API consistency with sibling variants.

LIKELY FOLLOW-UPS: How do you decide whether something belongs in the shared system versus a consumer's local code. What does a good RFC or proposal contain. How does review and release versioning handle the new variant.

ONE CONCRETE EXAMPLE: To add a danger variant to Button, open an issue proposing it, agree the prop value and token mapping with design, implement it via the existing variant prop using semantic color tokens, add a danger story and docs, include tests, then open a PR for maintainer review and release it as a minor version.