Designing a contribution model with quality gates

WHAT THIS TESTS The interviewer wants to see you scale contribution without sacrificing the consistency that justifies the system. They are listening for explicit quality gates, ownership boundaries, and a different path for trivial fixes versus net-new components.

A GOOD ANSWER COVERS Adopt a federated or curated contribution model: product engineers contribute, the core team curates and merges. Document expectations in CONTRIBUTING with a checklist. Use a branch-and-pull-request workflow (fork-based for external repos, trunk-based with short-lived branches internally). Enforce review with CODEOWNERS so the core team must approve changes to the library. Gate every PR with automated checks: lint, type checking, unit tests, visual regression via Chromatic or Playwright snapshots, accessibility audits with axe, and bundle-size limits. Require design sign-off and a documentation update for visible changes. Distinguish lightweight fixes (straight PR) from new components (proposal or RFC first, then implementation). Provide a preview deploy of Storybook on each PR so reviewers see changes live.

COMMON WRONG ANSWERS Giving all engineers merge access with no CODEOWNERS gate, which erodes consistency. Funneling everything through the core team, creating a bottleneck that kills adoption. Relying only on human review with no automated visual or accessibility gates.

LIKELY FOLLOW-UPS How do you stop the core team from becoming a review bottleneck? How do you handle disagreement between a contributor and the core team? What goes in the RFC?

ONE CONCRETE EXAMPLE An engineer fixes a focus-ring bug. They branch, push a PR; CI runs axe, visual snapshots, and unit tests; CODEOWNERS routes it to a core reviewer; the PR preview shows the corrected focus state; once green and approved it merges and ships as a patch release automatically.