Contribute docs with clear evidence and review paths.

This guide explains how community members and approved source contributors can report gaps, propose changes, prepare local validation, and keep Stornamics docs reviews routed to the right owner.

How To Start

Report a public docs gap

Include the page route, product area, expected reader goal, current behavior, and whether the gap affects a claim, example, limit, or support workflow.

Propose a focused change

Keep the change scoped to one content type or route family, preserve maturity labels, and include validation notes that reviewers can reproduce.

Route reviewer-sensitive work

Call out product behavior, support expectations, privacy handling, legal language, examples, or launch claims before requesting review.

Local Setup Expectations

Approved source contributors should use the repository README as the setup source of truth. A docs change is ready for review when the local evidence below matches the files and routes touched.

Local contribution evidence
Step	Expected evidence
Install and run locally	`npm install`, `npm run develop`, and a local docs site at `http://localhost:8002`.
Run docs quality checks	`npm run validate:docs-metadata`, `npm run validate:links`, and `npm run validate:claim-lint`.
Validate examples when touched	`npm run validate:examples`, `npm run validate:snippets`, plus smoke-test evidence or reviewer-run rationale.
Run browser automation before review	`DOCS_SITE_BASE_URL=http://localhost:8002 dotnet test` against the docs Playwright xUnit suite.

Content Types And Reviewers

Contribution content routing
Content type	Use for	Primary reviewers
Typo, link, or formatting fix	Small corrections that do not change product behavior, maturity, limits, examples, or navigation.	Page owner or docs lead.
Guide, concept, roadmap, or community page	Explanatory content, decision support, contribution workflows, and launch-foundation docs planning.	Docs lead, product SMEs when product behavior is described.
Quickstart, tutorial, snippet, or example	Runnable steps, copyable commands, expected output, SDK snippets, and cleanup guidance.	Product SME and docs QA reviewer.
Reference, compatibility, limits, or evidence	API routes, configuration, compatibility rows, unsupported behavior, evidence indexes, and last-reviewed claims.	Product SME, docs QA reviewer, docs lead for limits.
Operations, support, privacy, or sensitive claim	Runbooks, diagnostics, escalation, support bundles, data handling, and claim-risk language.	Operations, support, privacy, security, legal, or product reviewers as triggered by the change.

Review Flow

1. Report or propose

Contributor

Name the product, page route, content type, expected reader goal, and whether the change affects a claim, example, limit, or support flow.

2. Triage

Docs owner

Assign product, maturity, owner, reviewer roles, and whether issue-template, style-guide, or governance follow-up is needed.

3. Author

Contributor or docs author

Keep the change focused, preserve maturity labels, include evidence, and run the local checks that match the content type.

4. Review

Required reviewers

Confirm wording, evidence, examples, screenshots, and claim boundaries before the docs change is accepted.

5. Close the loop

Docs owner

Update backlog evidence, roadmap status, or follow-up items when the work changes public contribution expectations.

Expected Conduct

Be specific and kind

Describe the docs problem, the reader goal, and the evidence without turning review into blame.

Protect private information

Remove credentials, customer identifiers, payload bodies, private topology, and unpublished implementation details before sharing examples.

Preserve product boundaries

Do not promote alpha, preview, future, or verification-required behavior beyond its owning page and reviewer signoff.

Respect reviewer scope

Keep one contribution focused enough that product, QA, support, privacy, or legal reviewers can make a clear decision.