github-primer

GitHub Primer — operations

Research snapshot: 2026-07-30. Scope: Primer’s public product documentation and the public Primer React and Primitives repositories. Some contribution pathways are GitHub-staff-specific; those limits are noted.

1. Governance

• GitHub’s Design Infrastructure and Design Engineering teams maintain Primer. Primer’s public contribution overview routes implementation changes to the relevant repository and says major product-system contributions are presently oriented around GitHub teams. (About Primer, contribute, Primer React repository)
• Design-system maintainers, accessibility specialists, product designers, and design engineers are named as early review partners. New components are expected to be developed with feature teams using them, rather than solely by a detached central team. (Design contribution, adding new components)
• Repository CODEOWNERS and required review provide code-level ownership. New Primer React component proposals use a dedicated issue template and are invited from internal GitHub teams. (Primer React CODEOWNERS, Primer React repository)

2. Component lifecycle

• Primer publishes two related status views. Product documentation labels components Experimental, Ready, or Deprecated. Experimental means proof-of-concept or work in progress; Ready means mature and intended for long-term use; Deprecated identifies an alternative and warns consumers. (Component status)
• The new-component operational guide also describes implementation maturity moving through Alpha → Beta → Stable after a feature-owned component is upstreamed. Alpha may be used in production but can still receive breaking changes; review becomes stricter as it matures, and use by multiple teams supports the case for central maintenance. (Adding new components)
• Before upstreaming, the component progresses through explicit readiness stages: it exists and is discoverable; reaches design quality; gains documentation; meets accessibility expectations; and is ready for Primer ownership. The guide requires a name, description, Storybook examples, baseline accessibility, reviewed design quality, usage guidance, automated accessibility testing, and internal accessibility checkpoints. (Adding new components)
• A breaking change to a Ready component requires a major version and a migration path. Deprecation preserves a documented alternative and consumer warning. (Component status)

3. Contribution process

• Primer’s preferred on-ramp for a substantial new component is to build it in a product/feature context, make it discoverable, gather real use and evidence, then request review for upstreaming. Maintainers can also initiate the process when they see a component used by multiple teams. (Adding new components)
• Design contributors audit similar patterns and use cases, share early with maintainers and accessibility partners, and check foundations, primitives, Octicons, responsive behavior, implementation feasibility, inclusive design, and documentation. (Design contribution)
• Code changes use issues and pull requests in the relevant implementation repository, with contributor instructions for local setup, tests, coverage, and review. The public repository welcomes fixes from inside and outside GitHub, while new component proposals are specifically invited from internal GitHub teams. (Primer React contributing guide, Primer React repository)
• Documentation PRs must meet writing and publishing checks, including accessible examples, links, alt text, and removal of private information; new or materially updated documentation requires Design Infrastructure approval. (Documentation contribution)

4. Versioning and release cadence

• Primer React and Primer Primitives publish independently versioned packages and GitHub releases. Primer React’s repository uses Changesets and release entries classify changes as major, minor, or patch; release notes link changes to pull requests and contributors. (Primer React repository, Primer React releases, Primer Primitives repository)
• Product status rules connect breaking changes in Ready components to a major release and a migration path. Migration guides document larger consumer transitions and deprecated APIs. (Component status, migration guides)
• Release history is frequent, but the cited public sources do not promise one fixed calendar cadence across Primer’s React, CSS, Primitives, ViewComponents, and other implementations. (Primer organization, Primer React releases)

5. Documentation structure/templates

• Product component pages commonly provide Overview, Guidelines, and Accessibility sections plus implementation links and readiness badges for React, Figma, Storybook, source, and usage. Examples, props/API details, and related components are attached where relevant. (Token component)
• Contribution guidance requires production-quality, accessible examples and a publishing checklist covering spelling, links, alternative text, and confidentiality. (Documentation contribution)
• The new-component stages require both Storybook discoverability and product-facing guidance before upstreaming and stable maturity. (Adding new components)

6. Naming and token conventions

• Primer’s token taxonomy separates base, functional, and component/pattern tokens. Its naming convention composes prefix, namespace, pattern, variant, required property, optional variant, and scale; CSS joins terms with hyphens, JavaScript uses dot paths, and naming blocks use camel case. (Token names)
• Primer Primitives distributes color, typography, spacing, motion, and theme values. Token validation permits camelCase or kebab-case terms and enforces names through linting; functional themes include dark, colorblind, high-contrast, and other modes. (Primer Primitives, Primitives overview)

7. Accessibility criteria and enforcement

• Accessibility is an explicit upstreaming gate: new components require baseline keyboard and screen-reader behavior, automated axe testing, and internal accessibility checkpoints or reviews before Primer ownership. (Adding new components)
• Component accessibility pages distinguish behavior built into the component from integration obligations that consumers must test. Guidance covers semantics, keyboard behavior, contrast, zoom/reflow, and component or integration tests. (Page header accessibility)
• Design and documentation contribution checklists require inclusive design and accessible production-quality examples, placing accessibility in design review, implementation, and documentation. (Design contribution, documentation contribution)

8. Audit/review cycle

• Primer does not publish one universal periodic inventory-audit interval. Its public controls are continuous: component use in product supplies maturity evidence; maintainers review upstream candidates; CODEOWNERS and pull-request tests protect implementation; status labels and migration guides expose experimental and deprecated work. (Adding new components, Component status, Primer React CODEOWNERS)
• Multi-team use can trigger a maintainer-led upstream review. Deprecated documentation is retained for reference and names the supported alternative or migration route. (Adding new components, Component status, migration guides)