Contributing

dockmesh is maintained in spare time by a small group of developers. Contributions are welcome — and crucial.

Ways to help

You don’t need to write Go or Svelte to contribute:

• Report bugs — with a clear reproduction, on GitHub Issues
• Answer questions — on GitHub Discussions
• Improve docs — typos, unclear sections, missing guides on the docs repo
• Write tutorials — deploy guides for apps not yet covered
• Translate the UI — translation infrastructure not in place yet; see Translations below
• Triage issues — confirm bugs, ask for clarification, label
• Design dashboards — Grafana / Prometheus dashboards welcome in the community gallery
• Financial support — via GitHub Sponsors

Code contributions

Dev environment

# Clone
git clone https://github.com/Dockmesh/dockmesh
cd dockmesh

# Go backend
go build ./cmd/dockmesh

# Svelte frontend
cd web
npm install
npm run dev

Run both with make dev at the repo root — starts backend on :8080 with live reload and the Svelte dev server on :5173 proxying API calls.

Coding standards

• Go: golangci-lint run must pass. Error handling: always explicit, never silent _ =.
• Svelte: Svelte 5 with runes ($state, $derived, $effect). Tailwind v4 CSS-first.
• Tests: new features need tests. Go: go test ./.... Frontend: Playwright E2E for UI flows.
• Commits: imperative mood (“Add foo”), focused on the why in the body. No AI attribution trailers.

PR process

1. Fork the repo
2. Create a branch: feat/my-feature or fix/bug-description
3. Keep PRs small — one logical change each
4. Reference the issue: Fixes #123
5. Add tests
6. Run make test and make lint locally
7. Open PR with a clear title + what-and-why description
8. Respond to review feedback
9. Squash-merged after approval

What we likely won’t merge

• Large architectural changes without prior discussion (open an Issue first)
• New features that significantly expand scope (e.g. “add Kubernetes support”)
• Changes that break backward compatibility without a clear upgrade path
• Dependencies with ambiguous licensing

What we’ll merge quickly

• Bug fixes with tests
• Security patches
• Doc improvements
• Translation contributions
• Performance improvements with benchmarks

Documentation

The docs live in dockmesh.dev repo alongside the marketing site. They’re Markdown files — easy to edit.

git clone https://github.com/BlinkMSP/dockmesh.dev
cd dockmesh.dev
npm install
npm run dev  # localhost:4321

Edit files under src/content/docs/docs/. Open a PR.

Each doc page should answer: “What do I need to know to actually do this?” Favor concrete examples over exhaustive reference.

Translations

dockmesh UI is English-only today and no translation pipeline is wired up — strings live as inline text inside the Svelte components, there is no extracted message catalog yet.

If you’re interested in adding i18n, open a GitHub Discussion before starting work. The scope (string extraction approach, locale switcher placement, fallback behaviour, runtime vs build-time loading) needs alignment before any code lands so the first PR doesn’t get stuck in review.

Getting help with contributing

• Unsure if your idea fits? Open a Discussion first (not an Issue).
• Stuck on a PR? Ping in the Discussion thread you opened.
• Want to claim an issue? Comment on it, we’ll assign it.

Recognition

Contributors are credited in:

• The changelog entries for their work
• The dockmesh CONTRIBUTORS.md file (automatic via Git history)
• Optionally: the Hall of Fame in SECURITY.md for security researchers

Code of Conduct

All contributors and community members are expected to follow our Code of Conduct. Be kind, be constructive, be patient.

See also

• Roadmap — what’s being worked on
• Release Process — how releases are cut