Govern docs contributions with explicit owners.

Use this model to understand who maintains public docs contribution paths, when reviewers respond, what must be true before a docs change merges, and how contributor credit is handled without exposing internal details.

Governance Summary

Maintainer roles: 6
Review outcomes: 5
Initial response target: 2 business days
Triage target: 5 business days

Maintainer Roles

Community docs maintainer responsibilities
Role	Owns	Decides	Escalates
Docs product lead	Community contribution policy, public roadmap alignment, governance changes, and blocked docs decisions.	Whether a contribution stays in docs scope, needs a new issue, or should be deferred from launch work.	Unowned work, unclear reviewer authority, launch blockers, or contribution-policy disputes.
Docs lead	Editorial quality, style-guide alignment, route structure, issue-template fit, and contributor-ready wording.	Whether wording, navigation, examples, and contribution instructions are ready for docs review.	Product claims, sensitive wording, or changes that exceed the accepted public docs posture.
Product SME	Product behavior, compatibility rows, maturity labels, limitations, examples, and evidence interpretation.	Whether product-specific wording is accurate at the stated maturity level.	Unsupported claims, release timing, behavior mismatches, or missing limits.
Docs QA reviewer	Rendered-route checks, code block evidence, example status, browser coverage, and regression notes.	Whether the touched route validates cleanly enough for merge at the stated risk level.	Broken navigation, failed examples, accessibility regressions, or missing test evidence.
Support reviewer	Customer-safe intake, support handoff wording, redaction expectations, and docs-support boundaries.	Whether a report belongs in docs, support, product triage, or a privacy-sensitive intake.	Customer data, account-specific issues, support promises, or operational escalation language.
Sensitive-claim reviewer	Security, legal, privacy, compliance, support, availability, durability, scale, and performance claim review.	Whether sensitive wording can merge, must be rewritten, or needs a non-docs decision.	Any unapproved sensitive claim or missing reviewer signoff before merge.

Response Expectations

These are public docs contribution targets. They are not product support promises, incident response commitments, or contractual service terms.

Community docs response targets
Event	Target	Owner	Notes
New public docs report	Acknowledge within 2 business days	Docs owner	Acknowledge means the report was received and routed; it is not a support response-time promise or product commitment.
Initial triage	Route within 5 business days	Docs product lead or docs lead	Triage assigns product, content type, reviewer roles, claim risk, and whether more evidence is needed.
Good-first-docs issue	Keep scope reviewed before assignment	Docs lead	Starter work should stay low-risk and public-route based unless a maintainer expands it.
Review round	Return a concrete outcome	Required reviewers	Reviewers accept, accept with limits, request rewrite, defer, or block with evidence.
Stale contribution	Reassign or defer after 10 business days without owner movement	Docs product lead	Stale work should not leave contributors guessing; defer with owner and reason when launch scope changes.

Merge Requirements

Public route and issue context

The change names the public route, reader goal, product, content type, expected outcome, and sensitive-detail redaction status.

Required reviewers

Docs lead, product SME, docs QA, support, security, privacy, or legal reviewers approve when their scope is triggered.

Evidence and validation

The author includes matching validation commands, rendered-route checks, screenshots when visual layout changes, or reviewer-run rationale.

Claim boundaries preserved

Maturity labels, known limits, compatibility rows, evidence pages, and support boundaries stay aligned with the accepted source of truth.

No private public surface

Public pages do not expose private source paths, edit-source links, internal tracker URLs, credentials, customer data, or unpublished implementation details.

Planning evidence updated

Community, roadmap, README, source notes, search, or project-plan evidence changes when the contribution changes public contributor expectations.

Review Outcomes

Accept

The change can merge at the stated maturity with no required follow-up.

Accept with limits

The change can merge only because visible caveats or linked limits keep the risk bounded.

Request rewrite

The direction is right, but the reviewer needs a specific wording or structure change.

Defer

The work is useful, but not required now; record owner, reason, and target window.

Block

The change would mislead readers, expose private details, break core docs flows, or create an unapproved claim.

Contributor Credit

Contributor credit rules
Scenario	Credit path	Boundary
Accepted public docs report	Thank the reporter in the approved response channel when the channel and reporter allow it.	Do not publish customer names, account details, or private operational context.
Accepted source contribution	Credit the contributor by their chosen public display name in release notes or community summaries when they opt in.	Use team or role attribution when personal credit is not approved.
Security, privacy, legal, or support-sensitive report	Use the approved sensitive-reporting or support acknowledgement path.	Do not disclose reviewer identities, report content, customer impact, or mitigation details on public docs pages.
Internal reviewer contribution	Record reviewer role, date, and outcome in the internal or source-side evidence trail.	Public pages may name reviewer roles without exposing internal staffing details.

Escalation Triggers

Contribution escalation routing
Trigger	Route to	Before merge
Product behavior, maturity, compatibility, or limits change	Product SME and docs lead	Reviewer accepts the wording or files a blocker, rewrite, or deferral.
Security, privacy, legal, support, availability, durability, scale, or performance wording	Sensitive-claim reviewer plus the owning product or support reviewer	Sensitive reviewer accepts the exact language or removes the claim from public scope.
Examples, snippets, commands, screenshots, or rendered UX changes	Docs QA reviewer and owning docs lead	Validation evidence or reviewer-run rationale is recorded.
Contributor conduct, credit dispute, or unclear ownership	Docs product lead	The lead records the owner, decision, and any public-safe follow-up.