Contributing to PacketPilot Docs

Thank you for helping improve the PacketPilot documentation.

File Structure

All docs live in the docs/ directory of the packetpilot-landing repository.

docs/
├── README.md                     ← top-level index
├── architecture-overview.md
├── troubleshooting.md
├── quickstart.md
├── contributing-docs.md         ← this file
├── config/
│   ├── overview.md
│   ├── installation.md
│   ├── licensing-and-trial.md
│   ├── console-workflows.md
│   ├── ssh-workflows.md
│   └── troubleshooting.md
├── analyze/
│   ├── overview.md
│   ├── installation.md
│   ├── using-the-web-ui.md
│   ├── licensing.md
│   ├── workflows.md
│   └── troubleshooting.md
└── lab/
    ├── lab-guide.md
    └── examples.md

Style Guidelines

Voice and Tone

Audience: Network engineers comfortable with CLI, Docker, and Windows
Tone: Practical, instructional, concise — not marketing copy
Sentence style: Short, direct sentences. No filler ("In order to", "It is important to note that")
Commands: Use code blocks with the exact command or output
Example values: Use clearly-labeled example values (e.g. 192.168.1.1, SW-LAB-01)

Formatting

Headings: Use ## for top-level sections, ### for subsections. No heading levels deeper than ###.
Code blocks: Always specify the language for syntax highlighting:
- bash for shell commands
- yaml for Docker/Compose files
- json for JSON
- powershell for Windows commands
Tables: Use tables for comparisons, reference data, and step-by-step inputs/outputs
Warnings/Notes: Use bold labels:

Warning: Text here
Note: Text here

Content Rules

Be honest about current product state. Do not document features that don't exist yet. If something is planned, label it as such.
No broken links. All internal links must be relative and functional. External links must be correct.
No placeholder content. Every file must have real, usable content. Don't leave [TBD] or [coming soon] sections.
Keep it accurate to the code. If the product changes, the docs must be updated to match. PRs that change product behavior should update the relevant docs in the same PR.

Making Changes

Typos and Small Fixes

Submit a PR with the fix directly. Small changes don't need an issue first.

Bigger Changes

For larger changes (adding a new section, restructuring content), open an issue first to discuss the approach. This saves everyone time.

Doc PR Checklist

Before submitting a doc PR:

[ ] All internal links work (relative paths)
[ ] No TODO, [TBD], or placeholder content
[ ] Code blocks have correct language tags
[ ] New files are added to the appropriate docs/README.md section index
[ ] Spelling checked (at minimum, read it back)

Where to Make Changes

Product Changes

If you're changing the actual product behavior (e.g., changing how licensing works, adding a new onboarding flow), update the docs in the same PR as the product code. Docs are part of the deliverable.

Landing Page Copy

Landing page marketing copy lives in src/app/page.tsx and related components — not in docs/. The docs/ folder is for user-facing operational documentation, not marketing pages.

Getting Help

If you're unsure about something, open an issue or contact support@db-electronics.no.

CONTRIBUTING-DOCS