Contribution Models
How work gets from a product team into the shared system without either blocking the team or degrading the system.
Definition
A contribution model defines the route by which product teams add to or change the shared system. Without one, teams either wait indefinitely or fork, and both outcomes damage the system.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
A workable path
- 1
Build locally first
The team solves their problem in their own codebase. Nothing is blocked.
- 2
Signal the need
Register it against the system, so the core team can see repeat demand.
- 3
Wait for the third instance
When three teams need it, the shape of the general case is visible.
- 4
Design the general API
The core team and contributors agree the interface, informed by all three implementations.
- 5
Promote and migrate
Move it into the system, migrate the original implementations, and delete the local copies.
What contributors need
- A written definition of done, including accessibility and documentation requirements.
- A review turnaround commitment that is actually met.
- A pairing option, since most product designers and engineers contribute rarely.
- Credit, which is the main non-monetary incentive that sustains contribution.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Practical example
A worked decision where this was the deciding factor.
Related concept
Connected closely enough to change how you apply this.
- Component API DesignDesign system
- Design System AdoptionDesign system
- Design System DocumentationDesign system
- Design System GovernanceDesign system
- Design CritiqueWorkflow