Who may add a component must be named

What it is

Adding a component to the shared library is not “dropping a file in my repo”. It rewrites a contract many products already depend on. The right to make that write has to sit on a nameable role — an on-call person, a committee, a code-ownership record — not on “whoever currently feels the pain”. That decision point is contribution authority: who is allowed to admit a new primitive. It is about eligibility, not about how high the bar is, and not about how many widgets already sit in the catalog.

When eligibility is vague, everyone writes from local pain. When it is sharp, both a rejection and an acceptance have a signature.

Why it happens

A shared library is read by many and should be written by few. The moment a write lands, upgrade paths, theme switches, and defect fixes for every caller are bound to the new name. If write access defaults to “can push code”, local optima fire automatically: this page needs a date picker, the author knows this page’s fields, the shortest path is to mint another one. When the decision cannot be located, nobody owns “should this name exist”, and afterwards nobody knows whom to ask.

Authority turns “join the system” from a private act into an auditable public one. The authorized party need not type every line, but they must be callable: accept or refuse, with a record. Without that subject, later talk of review, use-count gates, and handover has no one to attach to.

Where it stops holding

On a five-person, single-product team whose catalog still fits on two hands, the squad itself is the authority; a committee is ceremony. On a platform serving many brands and dozens of repos, “anyone who can push may add a primitive” goes false quickly. Open-source programs can vest writes in maintainer votes; vesting them in “the business line that filed the request” hands a public contract to a local budget. Hotfixes may use a side door, but the door needs an expiry and a promotion condition, or the hotfix becomes the permanent author.

Applying it

• Write one sentence: which role accepts new primitives, and how that role rotates. Put it on the first screen of the contribution guide, not in meeting notes.
• Mirror that role in CODEOWNERS or the equivalent, so “who can merge a new component directory” and “who gets pinged” are the same person-shaped thing.
• Make the first field of the request template “you have confirmed eligibility with the acceptor”. Unconfirmed requests do not enter the review queue.
• Check: ask design, engineering, and a product manager, separately, “who can add a DatePicker to the library”. Three answers naming the same reachable person or role means authority is explicit. “Whoever has time”, “ask the system team I guess”, or three different names means it is not.

Related

• Same group: R1.06.2 An ungoverned system decays into a component pile · R1.06.3 High contribution cost drives teams around the system · R1.06.4 Promote only after several real call sites exist · R1.06.5 Review the public API, not the implementation internals · R1.06.6 Maintenance is accepted with the component, not after the merge
• Adjacent: R1.02 Component libraries and variants · R1.18 Adoption and compliance metrics
• Search terms: contribution authority · who may add · design system governance