Community Governance and Decision-Making
Most successful community mesh networks are lightly governed but clearly structured. Too little structure leads to chaos; too much bureaucracy kills volunteer participation. Here's what works.
Minimal viable governance
The CascadiaMesh, NoDakMesh, and RegionMesh communities all operate with variations on the same basic structure:
- Network coordinator(s): 1–3 people who make final decisions on network settings, new repeater standards, and community direction. Usually the founders or most active contributors.
- Discord or forum: Primary community space for announcements, help, and coordination.
- Wiki or docs: Written reference for setup guides, network standards, and node documentation.
- Network map: Visual representation of active nodes.
Decisions that need explicit consensus
Some decisions affect everyone and need community buy-in, not just coordinator fiat:
- Changing the default preset or frequency: Migrating an existing network to a new preset requires coordinating every node simultaneously — a major disruptive event. Don't do this casually.
- Adding a private or encrypted channel: If community nodes are being used to bridge a private channel, other participants should know.
- Hosting policies: What standards do infrastructure nodes need to meet? Who can call themselves part of the network?
Managing contributions from outsiders
As the network grows, people will want to add nodes. This is good — but uncoordinated growth causes problems:
- Wrong settings: New operators who configure incorrectly fragment the network
- Poorly placed nodes: A ground-level node in a bad location adds noise to the network without contributing coverage
- Abandoned nodes: Nodes that go offline and are never maintained degrade the perceived reliability
Solution: Create a brief onboarding checklist for new node operators. It doesn't need to be formal — a Discord message template works. Cover: preset/channel settings, naming convention, role configuration, how to get on the network map, and who to ask for help.
Handling network conflicts
Occasional conflicts arise: two operators disagree on the right preset, a node is causing interference, someone deploys with wrong settings. Keep these principles in mind:
- The coordinator's job is to be a technical arbiter, not a bureaucrat. Make technically correct decisions and explain the reasoning.
- Document the standards. "The network uses X because Y" is much easier to enforce than "the coordinator said so."
- Be welcoming to newcomers who made honest mistakes. Getting the settings wrong is easy. Help them fix it rather than shaming them.