Governance model for specialized contributions

WHAT THIS TESTS The interviewer wants a governance model that scales contributions of varying specialization while protecting the core. They are listening for decision rights, a need-validation gate, and tiering so niche components do not pollute core.

A GOOD ANSWER COVERS Define the governance model first: who decides what enters core (typically a core-team-curated, federated model with a small review board). Intake starts with an RFC stating the use case, prior art, and how many teams need it, which validates shared need versus niche. Then route by tier. If broadly useful, accept into core. If specialized but reusable, place it in a community or contrib tier or a lab/experimental package with lighter guarantees. If truly local, keep it in the team's repo with guidance. For accepted contributions, follow the standard workflow: branch, implement with tests, accessibility, visual snapshots, and docs, open a PR gated by CI and routed via CODEOWNERS to core reviewers plus design sign-off. On approval, merge and release with the appropriate SemVer bump, publishing release notes. Define ongoing ownership and SLA so contributed components are maintained, not orphaned.

COMMON WRONG ANSWERS Forcing every contribution through the same core path, bloating the library with niche components or rejecting useful work outright. No need-validation gate. No clarity on who maintains the component after merge, leaving orphans.

LIKELY FOLLOW-UPS Who maintains a contributed component long-term? When does a contrib-tier component graduate to core? How do you prevent the review board from becoming a bottleneck?

ONE CONCRETE EXAMPLE A team contributes a specialized Gantt chart. The RFC shows only two teams need it, so it lands in the experimental contrib package with lighter guarantees and shared maintenance. After it stabilizes and a third team adopts it, the review board graduates it into core, and it ships as a minor release with full support.