Contribute to the docs

Everything you need to contribute to the documentation starts here. Pick the path that matches what you're trying to do — each one routes you to the canonical guide for that task, so there's only ever one place to look.

Not sure which path?​

• Editing words on a page that already exists → Write or improve a doc page.
• A repo's code isn't represented in the docs at all yet → Onboard a new source repo.
• You want your functions, types, or endpoints to appear in the generated reference → Add inline doc tags to your code.

Templates & standards​

Starter templates, required sections, and the gold-standard examples for both AI-assisted and human authoring live alongside the doc-standards:

• Doc-standards & gold-standard examples — required fields, voice/tone, and worked examples: CLAUDE.md doc-standards
• Inline tag standards, by language — TypeScript (TSDoc), Go (Godoc), OpenAPI

Navigation & footer standards​

The top-level navigation tabs are how readers find their way, so we keep them deliberately small and organized around what you're trying to do, not around our teams, products, or file formats. Before you touch the navbar or footer, know these standards:

• Five tabs, organized by reader intent. The top-level tabs are Get Started, Guides, Concepts, Reference, and Platform. We target five and never exceed six. New content almost always belongs inside one of these — in a sidebar — not as a new tab.
• No catch-all labels. Names like Documentation, Misc, Other, More, or Resources are not allowed as a tab or a sidebar category — they hide what a reader is actually looking for. (Docs and Resources are fine as footer column titles only.)
• One name per thing, one home per thing. Use the same label for a concept everywhere it appears, and give each page exactly one home in the sidebar. Link to it from elsewhere rather than creating a second copy.
• A footer link must earn its place. It has to resolve, point at the canonical page (not a duplicate), and use the correct domain and support email for the brand. A footer column needs at least three lasting links that share one purpose.
• Accessible and on-brand on every site. Navigation must be keyboard-operable and meet WCAG 2.2 AA contrast in both light and dark themes, and brand color comes from the shared tokens — never a hardcoded hex value.

Adding a new tab or changing these rules is a deliberate decision. The full, checkable rules (and what needs updating in the same PR) live in NAV_FOOTER_GOVERNANCE.md.

Page & article standards​

Every page has a shape. We keep it predictable because search, the on-page table of contents, the machine surface, and how readers find their way all depend on it. Before you write or edit a page, know these standards:

• One page does one job. We follow the four Diátaxis modes: a tutorial (a hold-your-hand lesson), a how-to (a recipe for one goal), a reference (dry, complete description), or an explanation (background and concepts). A page is exactly one of these — if it teaches and instructs and explains all at once, split it.
• Start from a template. Each mode has a skeleton with the required frontmatter and section order in /page-templates. Copy the one that matches your page's mode.
• Fill in the frontmatter contract. Every page needs title, description (one honest sentence, 160 characters max, no marketing adjectives), sidebar_label, kind (quickstart / guide / concept / reference), tags, and route.
• Add a subtitle — the one line under the H1. It is recommended, not required, and it is spelled lower-case: subTitle looks right and renders nothing. Leave the # heading out of the page body when you use it — the H1 comes from title, and a body # deletes the subtitle rather than sitting above it.
• Use admonitions for what they mean. :::tip is an optional accelerator, :::note an aside, and :::warning / :::caution / :::danger are for consequences. A required step belongs in a Prerequisites or Steps section, never hidden in a tip.
• No emoji in headings, titles, or sidebar labels, no pseudo-headings, and exactly one H1 per page. A pseudo-heading is a label pretending to be a heading: a bold paragraph before a list, or a bullet whose whole content is bold. Both are invisible to the table of contents, to search, and to a screen reader — use a real ##/###, or fold the label into what it introduces.

The full, checkable rules live in PAGE_ARTICLE_GOVERNANCE.md, mirrored by the machine-checkable config/content-standards.json. Run yarn validate:content to check the pages you changed before opening a PR.

Package version standards​

Package versions shown anywhere in the docs come from one source of truth, not from anything you type into a page. Before you touch a version, know these standards:

• Versions live in one file. They come from config/package-versions.json, not from page frontmatter. To bump a version, edit that file — never add a reactVersion/coreVersion (or any *Version) field back to a page.
• Pages don't carry a version badge. SDK pages used to show a core v14.0 pill under the breadcrumb; it was removed because it answered a question readers weren't asking, on every page, above the title.
• Cross-package compatibility goes in one place. Which core a given SDK needs belongs on the compatibility page.
• We show major.minor. Patch versions live in the changelog, not on the page.
• Accessible and on-brand on every site. Version surfaces meet WCAG 2.2 AA contrast in both themes and take their color from the shared tokens.

The full, checkable rules (and what needs updating in the same PR) live in PACKAGE_VERSIONING_GOVERNANCE.md.