Contribute public docs without creating drift
- Identify the user problem first: tutorial, how-to, reference, explanation, or support-routing change.
- Edit the route that owns that problem instead of adding a duplicate answer in a nearby page.
- Keep public and internal documentation boundaries explicit; do not move private runbook material onto the public Mintlify surface.
- Validate the page locally with Mintlify link checks and the repo-owned docs governance checks.
- Open or update the merge request with the governing issue and exact verification evidence.
Pick the correct docs surface first
| If the contribution is about… | Edit this surface | Do not use this surface when… |
|---|---|---|
| public product, API, governance, or institutional docs | docs/** public routes | the content is internal workflow or controller doctrine |
| docs navigation, redirects, or Mintlify platform behavior | docs/docs.json, redirects, and Mintlify-owned platform files | you only need to change prose on one route |
| internal workflow doctrine or repo-only runbooks | repo workflow docs outside the public route tree | the audience is external docs readers |
Keep the Diataxis contract intact
- Use tutorials for guided first-success lessons.
- Use how-to guides for one concrete task.
- Use reference pages for exact facts, enums, formulas, or tables.
- Use explanation pages for system rationale and design tradeoffs.
- Use support and audience routes as routers, not as substitute product pages.
Minimal validation loop
- Run
mint broken-links. - Run
uv run --directory rust-packages/ddx-python/devtools --extra dev python -m admin_cli docs taxonomy-check --mode strict --scope all. - Run
uv run --directory rust-packages/ddx-python/devtools --extra dev python -m admin_cli docs governance-check --mode strict --scope all. - If the change alters packet-governed issue work, run the packet verifier or
planning packet-checkthat owns the issue.
Common contribution mistakes to avoid
| Mistake | Better move |
|---|---|
| adding the same answer in multiple pages | strengthen the owning route and link to it |
| mixing task steps into reference or explanation pages | move the procedure into a how-to guide |
| inventing unpublished enterprise, operator, or legal content | keep the page boundary-honest and route readers to public escalation paths |
| editing only prose when the real issue is nav or redirect ownership | update docs.json or redirects in the same change |
Merge request checklist
- State which route owns the concept now.
- Include the exact validation commands you ran.
- Mention any redirect, nav, or hosted-parity implications.
- If the change closes a hierarchy or packet gap, say which one.
Boundary rules
- This page is for the public
docs/**surface, not for internal workflow doctrine or private operator runbooks. - Use Use DerivaDEX Docs with AI Tools for public AI-access mechanics, not for maintainer contribution workflow.
- Use Support Channels if the public docs and current repo state disagree and you cannot resolve the conflict from published sources.