Contributor workflow from proposal to merge

WHAT THIS TESTS The interviewer wants the canonical contribution sequence and evidence that you front-load alignment so engineers do not waste days building something that gets rejected on scope or API.

A GOOD ANSWER COVERS Start with a proposal or lightweight RFC that states the use case and confirms the need is shared, not local. Align early with the core team and design on the component API, variants, states, naming, and tokens before writing significant code. Implement on a branch following CONTRIBUTING guidelines, including unit tests, accessibility, visual regression snapshots, and Storybook documentation with usage examples. Open a pull request; CI runs the automated gates and CODEOWNERS routes it to core reviewers and design for sign-off. Iterate on feedback, get approvals, then merge. A release follows, typically a minor version bump since it adds functionality, and the docs site updates.

COMMON WRONG ANSWERS Opening a big PR with a finished component and no prior proposal, risking rejection. Skipping documentation or accessibility. Merging without design sign-off so the component drifts from the visual language. Treating contribution as identical to a normal feature PR with no extra rigor.

LIKELY FOLLOW-UPS What belongs in the proposal? Who has final say on the API? How does this differ from contributing a bug fix?

ONE CONCRETE EXAMPLE An engineer wants a Tag component. They file a short proposal, confirm three teams need it, agree the API and variants with design, then branch and build with tests and Storybook stories. The PR passes axe and visual checks, a core reviewer and a designer approve, it merges, and ships as version 2.3.0.