Contributor workflow from proposal to merge
Whether you know the end-to-end contributor path.
Proposal or RFC, design and core alignment, branch and build with tests and docs, review, then merge and release.
Opening a PR for a new component with no prior alignment.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
What belongs in the proposal? Who has final say on the API? How does this differ from contributing a bug fix?
A 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.
Interview question
What is the main benefit of a proposal or RFC step before building a new design system component?
- a.It validates shared need and aligns on API before effort is sunk into codeCorrect
- b.It automatically bumps the major version number
- c.It lets the contributor skip code review
- d.It replaces the need for any automated testing later
Why? this is the answer
An RFC front-loads alignment on need and API so engineers do not build something that gets rejected on scope. It does not remove testing or review obligations, which still apply to the implementation PR.
Just read this? Test yourself on what you have been reading.
Read the original → octopus.design
- #design-systems
- #contribution
- #workflow
- #rfc
- #process
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design-systems — each one lists the topics its interview covers.
See open roles