Contribution and Governance

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.

Three tiers of contribution

The fix was to stop treating every contribution the same. Northwind now has three tiers, each with its own path:

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.

CODEOWNERS 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.

Triage: where does a request belong?

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.

The 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.

Governance without a bureaucracy

Governance is how decisions get made when people disagree. Northwind’s version fits on one page:

• The core team decides on anything that becomes public API, after hearing from the teams affected.
• Decisions happen in the open, at the weekly API review that anyone can attend, or asynchronously in the RFC.
• Arguments cite the principles and evidence, such as usage numbers or research findings, not job titles.
• Every decision is written down in a decision log with its reasons, so it can be revisited when the evidence changes rather than re-argued from memory.

Speed 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.

In the exercise, you put a new component’s path into the system in order. Next, you scale the theming architecture to a second brand.