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

• Network coordinator(s): 3 - 5 people who make final decisions on network settings, new repeater standards, and community direction. Usually the founders or most active contributors. These informal "coordinator" roles describe operational decision-making; if the mesh is run by a 501(c)(3) nonprofit, the board of directors still retains the formal legal and fiduciary responsibility regardless of the coordinator structure.
• 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. This is not only a courtesy issue - confirm your regulatory basis first. Encrypted channels are permitted under Part 15 (ISM, 915 MHz), but are prohibited for stations operating under amateur radio (Part 97), so an encrypted channel is incompatible with callsign-identified ham operation.
• 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 - nodes must share matching settings (region, modem preset, channel) to communicate at all
• Poorly placed nodes: A ground-level node in a bad location can add airtime congestion without contributing coverage. This applies to relaying nodes (any Meshtastic node) and badly-placed repeaters, not to non-relaying MeshCore companion nodes.
• 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.