Feedback
Verification RequiredSend docs gaps, product questions, sensitive evidence, and launch signals through the approved path so reviewers can act without exposing private source links, customer data, or unapproved support promises.
Issue-first intake
Use the public-safe issue templates when a page is missing, unclear, stale, hard to find, or stronger than the linked evidence supports.
Share the public route, product, content type, observed problem, expected outcome, evidence, and impact.
Open issue templatesAssigned support channel
Use the support path from your private beta invitation for account-specific behavior, tenant context, pilot blockers, or product-support questions.
Start with the docs route and sanitized evidence, then let support route product or account details through the approved channel.
Open support guidanceRedaction required
Use the support bundle privacy guidance before sharing logs, traces, diagnostics, configuration, screenshots, or troubleshooting output.
Remove credentials, customer identifiers, raw payloads, proprietary logs, and private topology before handoff.
Open redaction guidanceBrowser-local diagnostics
Use page health to review failed searches, missing routes, stale review signals, and low-rated page summaries during launch triage.
Treat page-health data as local reviewer diagnostics, not remote analytics or customer reporting.
Open page healthUse the canonical docs URL or route path where the gap appears. Do not include repository paths, branch names, or local development paths.
Name ObjectDB, Message Broker, Concordia, LogDB, or cross-product, plus whether the page is a quickstart, guide, reference, limit, operation, or roadmap item.
Describe what the reader needed to do or understand, and whether the gap affects a claim, example, limit, support flow, or release note.
Prefer status codes, route names, counters, timestamps, and shape-only examples before logs, payloads, screenshots, or customer-specific values.
This route does not submit or store feedback by itself. It routes readers to approved support, issue-template, redaction, and local diagnostics paths.
Retention, visibility, and acknowledgement follow the approved destination used for the report, such as the issue template process or assigned support channel.
The public docs site does not add third-party analytics tags, analytics cookies, or remote page-feedback telemetry for this intake.
Customer identifiers, credentials, secrets, raw payloads, proprietary logs, private topology, and support bundles stay out of public reports.
| Lane | Owner | Response |
|---|---|---|
| Docs correction | docs product lead | Classify the issue, assign the product or docs owner, and record a fix, accepted limit, deferral, or blocker. |
| Product or account support | support reviewer | Keep product-support questions in the assigned channel and route docs corrections back through the issue-first path. |
| Privacy or sensitive evidence | privacy, security, and support reviewers | Keep sensitive material out of public docs reports until redaction and reviewer approval are complete. |
| Launch-impacting signal | docs triage lead | Use DOCS-091 severity rules to decide whether the report is P0, P1, P2, or P3 and whether release-docs updates are required. |
The destination where you submit the report provides the safe acknowledgement path. Docs triage then uses the post-launch triage plan to assign severity, owner, response expectation, and release-docs follow-up when the signal affects launch readiness.
Inline page rating controls stay hidden until support, privacy, analytics, acknowledgement, retention, triage ownership, and browser automation coverage are approved for that separate control surface.