Skip to main content

​
Contribute to ddx-python without drifting scope

  1. Start from the public DerivaDEX repository and identify the issue or merge request context that owns the change.
  2. Confirm the contribution really belongs in the ddx-python family rather than in the core API docs, the v2 frontend workspace, or governance/DIP material.
  3. Read the package entrypoints and runbook references before editing:
    • rust-packages/ddx-python/devtools/admin_cli/README.md
    • rust-packages/ddx-python/devtools/ARCHITECTURE.md
  4. Make the smallest coherent change in the Python client, examples, or devtools surface.
  5. Run the narrowest validation that proves the edited behavior.
  6. Open or update the merge request with the governing issue link and exact verification evidence.

​
Choose the right ddx-python scope first

If the change is about…Start hereDo not use this path when…
Python client entrypoints or library ergonomicsddx-python Library Referencethe real issue is API contract drift rather than Python packaging or examples
public examples and builder onboardingGetting Started with ddx-pythonyou need a protocol design discussion rather than a client-facing example
devtools or docs-governance workflowsrust-packages/ddx-python/devtools/admin_cli/README.mdyou are changing the public Mintlify docs surface instead of repo tooling

​
Minimal local proof loop

  1. Reproduce the behavior with the smallest relevant command or test.
  2. Run the package-local validation that matches the touched surface.
  3. If the change also touches public docs, run mint broken-links plus the docs governance checks.
  4. Save the exact commands and outcomes for the merge request.

​
Public validation commands to reach for

When you changed…Minimum proof
public docs content under docs/mint broken-links, admin_cli docs taxonomy-check, and admin_cli docs governance-check
admin_cli or docs-governance toolingthe targeted uv run --directory rust-packages/ddx-python/devtools --extra dev ... command that exercises the changed surface
builder examples or client usage notesone working example path plus the narrow docs or package checks that own the edited files

​
Merge request checklist

  1. Link the governing issue.
  2. Keep the diff scoped to one coherent ddx-python or devtools problem.
  3. Include exact verification commands and outcomes.
  4. Call out any docs/API boundary assumptions explicitly if the change depends on them.
  5. If the change reveals API-contract ambiguity, link the relevant public API or packet route instead of silently guessing.

​
Boundary rules

  • Use governance proposal routes when the change is really a design or policy decision rather than a Python contribution.
  • Use For Builders when the problem is integration design, not contribution workflow.
  • Use Developer Ecosystem for the broader public map; this page is only for the ddx-python contribution procedure.

​
Next routes

Last modified on April 13, 2026