Skip to content
dockmesh

Contributing

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

Ways to help

Section titled “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 — i18n pipeline is open; see 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

Section titled “Code contributions”

Dev environment

Section titled “Dev environment”
Terminal window
# Clone
git clone https://github.com/BlinkMSP/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

Section titled “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

Section titled “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

Section titled “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

Section titled “What we’ll merge quickly”
  • Bug fixes with tests
  • Security patches
  • Doc improvements
  • Translation contributions
  • Performance improvements with benchmarks

Documentation

Section titled “Documentation”

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

Terminal window
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

Section titled “Translations”

dockmesh UI is English-only today. Translation infrastructure (via i18next) is planned. When available:

  • Translate strings in web/src/lib/i18n/en.json → xx.json for your locale
  • Submit via PR

For now, track issue #42 for translation readiness.

Getting help with contributing

Section titled “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

Section titled “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

Section titled “Code of Conduct”

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

See also

Section titled “See also”