Documentation Standards

Types of Documentation

• User-facing docs

  • Explain features, configuration, and usage.
  • Assume no access to source code.

• Internal docs

  • Capture system behavior, architecture, and decisions for developers.
  • Include rationale and trade-offs.

• Inline docs / comments

  • Explain non-obvious implementation details or constraints.

Style & Tone

• Clear, concise, and concrete.
• Prefer active voice and simple sentences.
• Avoid unexplained acronyms and internal-only jargon.

Structure Guidelines

Feature Docs

• Overview
• Use cases
• Configuration and defaults
• Examples
• Limitations and edge cases
• Troubleshooting

Architecture Docs

• High-level diagram (or description)
• Components and responsibilities
• Data flows and interactions
• Trade-offs and constraints
• Links to related RFCs or ADRs

Maintenance Rules

• Documentation must be updated as part of behavior changes.
• Prefer small, incremental doc updates rather than large rewrites.
• Link docs to relevant issues or tickets where useful.

Formatting

• Use Markdown (.md) for text docs.
• Use consistent heading levels and lists.
• Include code blocks with language tags.