In Northwind’s first year of opening contributions, we received 112 pull requests and merged 41. Most of the rest died waiting: for an API review that had no schedule, for a designer who was on another project, for a decision nobody felt allowed to make. Teams learned the lesson fast. By month nine, contributions had almost stopped, and three teams had started their own component folders again. A contribution model isn’t a document; it’s a promise about how quickly and fairly the core team will respond.
\nThe fix was to stop treating every contribution the same. Northwind now has three tiers, each with its own path:
\n| Tier | \nExamples | \nPath | \nFirst response | \n
|---|---|---|---|
| Fix | \nBug, docs error, missing story | \nPull request, one core reviewer | \n2 business days | \n
| Enhancement | \nNew variant, new prop, new token | \nShort proposal issue, then pull request | \n1 week | \n
| New component | \nDate picker, data table | \nRFC, API review, then build with a core pair | \n2 weeks for a decision | \n
A fix needs no permission. An enhancement needs a short written case: what problem, which teams, and the proposed API snippet, because props are public API forever. A new component needs a request for comments (RFC), a document that lays out the problem, evidence from at least two teams, the API sketch, the state matrix and the accessibility plan. The RFC gets discussed at the weekly API review, and someone leaves with a decision.
\nCODEOWNERS makes the routing automatic: the core team owns the token files and the public API exports, so any change to them requests a core review, while docs pages can be approved by any experienced contributor.
Most requests end at the first question. About half of Northwind’s “new component” requests turn out to be an existing component that the docs didn’t make findable, which becomes a docs fix.
\nThe second question is where teams get nervous, because “build it locally” sounds like rejection. It isn’t. A one-team component built from system tokens and components looks native and costs the system nothing to maintain. Northwind keeps a list of these local components, with owners, and checks it every quarter. When a second team needs something on the list, the original becomes the starting point for an RFC. Three of our current components, including the date picker, started this way.
\n\nGovernance is how decisions get made when people disagree. Northwind’s version fits on one page:
\nSpeed matters as much as fairness. A clear “no” in two weeks is better for a product team than a “maybe” for two months, because they can plan around a no.
\n\nIn the exercise, you put a new component’s path into the system in order. Next, you scale the theming architecture to a second brand.
\n","toc":[{"id":"sec-1","text":"Three tiers of contribution","level":2},{"id":"sec-2","text":"Triage: where does a request belong?","level":2},{"id":"sec-3","text":"Governance without a bureaucracy","level":2}],"takeaways":["Match the process to the size of the contribution; a typo fix and a new component should not go through the same gate.","A new component enters the system when several teams need it, not when one team built it first.","Building something locally is a legitimate outcome of triage, and the system should make that easy rather than shameful.","Governance works when decisions are fast, written down and argued from the principles, not from seniority."],"further":[{"title":"Contributing guidelines for a repository (GitHub Docs)","url":"https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors"},{"title":"About code owners (GitHub Docs)","url":"https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners"},{"title":"Contribute to the U.S. Web Design System","url":"https://designsystem.digital.gov/about/contribute/"}],"quiz":[{"q":"A team fixes a typo in the Tabs documentation and opens a pull request. The contribution guide requires an RFC and an API review for every change. What’s the likely outcome over time?
","options":[{"text":"Higher quality, because every change is reviewed thoroughly.","why":"Heavy review on trivial changes doesn’t add quality; it mostly adds delay."},{"text":"Teams stop contributing small fixes and work around problems locally instead.","why":"Correct. When the cost of contributing exceeds the cost of a local workaround, people choose the workaround."},{"text":"The core team gets more time for important work.","why":"The core team spends that time running the heavyweight process instead."},{"text":"Nothing changes; teams accept process as part of the job.","why":"People respond to friction; process cost always shows up in behavior."}],"answer":1},{"q":"The billing team asks the system to add an InvoiceTimeline component. No other team has a similar need. What does Northwind’s triage recommend?
","options":[{"text":"Add it to the system, since a contribution is free capacity.","why":"Every component in the system is a long-term maintenance cost paid by the core team, even if someone else wrote it."},{"text":"Reject it and tell the team to wait until another team needs it.","why":"The billing team needs it now; waiting helps nobody."},{"text":"Ask the core team to build it as a priority.","why":"Spending core capacity on a one-team component takes it away from shared needs."},{"text":"Build it locally from system tokens and components, and revisit if other teams need something similar.","why":"Correct. The team gets unblocked, the result still looks native, and the system learns whether the need is shared."}],"answer":3},{"q":"Two senior designers disagree about whether Select should allow free-text entry. Which governance approach resolves it best?
","options":[{"text":"Bring it to the weekly API review, argue from the principles and usage evidence, record the decision and its reasons.","why":"Correct. Decisions made openly and written down can be revisited with new evidence instead of re-argued from scratch."},{"text":"Let the more senior designer decide.","why":"Seniority settles the argument today and teaches everyone that evidence doesn’t matter."},{"text":"Ship both behaviors behind a boolean prop.","why":"Avoiding the decision moves it into every product team and adds a prop that interacts with every other one."}],"answer":0}],"exercise":{"kind":"order","items":["search","evidence","rfc","review","build","release"],"title":"Bring a date picker into the system","prompt":"The dispatch team built a good date range picker locally. Now the billing and reporting teams want one too. Put the steps that take it into Northwind UI in order, following the contribution model from the lesson.
\n","hints":["Triage starts by checking whether the need is already covered.","The RFC needs evidence before anyone reviews it, and review comes before building the system version."],"explanation":"Triage first confirms that no existing component covers the need, then gathers evidence that several teams share it, which is what moves a component from local to system. The RFC turns that evidence into an API sketch, state matrix and accessibility plan, and the open API review produces a recorded decision. Only then does the dispatch team build the system version with a core pair, and it ships like any other change: stories, docs, a changeset and contributor credit in the release notes.
\n","checkLabels":{},"itemText":{"search":"Confirm that no existing component, or better docs for one, already covers range selection","evidence":"Collect the use cases from the dispatch, billing and reporting teams","rfc":"Write an RFC with the API sketch, state matrix and accessibility plan","review":"Discuss it at the weekly API review and record the decision and its reasons","build":"Rebuild the picker in the system repository with a core designer and engineer pairing","release":"Ship it with stories, docs and a changeset, crediting the dispatch team in the release notes"}},"words":649,"readMinutes":3}