Purpose

This document defines how contributions flow into Sequoia. It exists so anyone who wants to propose, build, or update part of the system knows what to expect, what good looks like, and who is involved at each step.

Sequoia is maintained by a small core team: one design systems designer and one design systems engineer, with an architect providing code oversight across projects. We give the team autonomy to decide what to build based on the needs of our consumers, who are the designers and engineers building Driveway and our enterprise app products. As those products grow, we want other designers and engineers to contribute to Sequoia when the work calls for it. This model makes that contribution clear and repeatable.

Contribution Types

Sequoia accepts eight types of contribution. Each one moves through the same review flow, but the scope and effort differ.

1. New component. A component that does not yet exist in the system. Requires architectural decisions, design spec, code, documentation, and accessibility coverage.
2. Component enhancement or variant. An existing component needs a new prop, state, or visual variant to support a use case. Requires design and code review.
3. Bug fix or defect. A component is broken or does not match its spec. Requires verification that the fix does not break other uses.
4. Documentation or guidance update. A do and don't guide, clarified language in Storybook or Notion, or added accessibility notes. Often contributor-owned with light review.
5. Token or style adjustment. A change to spacing, color, typography, or elevation at the system level. High impact, since it cascades everywhere. Requires careful review.
6. UI or feature icons addition. Expanding the icon set or adding illustrations. The pattern is well known, which makes this the most straightforward type.
7. Pattern or layout template. A reusable layout or composition pattern built from existing Sequoia components.
8. Product-specific implementation guidance. Guidance for using Sequoia components in a specific product context. This lives outside core Sequoia but references the system. A vehicle card built for Driveway from Sequoia primitives is one example. It documents an approach so others building similar components, without forcing product-specific work into the core library.

Acceptance Eligibility

Before a contribution moves into review, confirm it meets the criteria below. These define whether the work belongs in Sequoia at all. They are not a barrier. They keep the system cohesive and prevent redundancy.

Reusability. The need shows up more than once, generally two to three times or more, across teams or products. A pattern used a single time in one place usually belongs in that product, not in core.

Generalizability. The work solves a general problem that more than one team can reuse, rather than a need specific to one product or flow. Product-specific work is documented as implementation guidance instead.

Not already solvable. The need cannot be met by an existing component, a variant, or composition of existing components.

Right altitude. The work is a true system-level component, not something better owned by a single product. A component composed of Sequoia parts but specific to one product, like a vehicle card, sits on the line and generally belongs to that product.