# 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):**<span style="white-space:pre-wrap;"> 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.</span>
- **Discord or forum:**<span style="white-space:pre-wrap;"> Primary community space for announcements, help, and coordination.</span>
- **Wiki or docs:**<span style="white-space:pre-wrap;"> Written reference for setup guides, network standards, and node documentation.</span>
- **Network map:**<span style="white-space:pre-wrap;"> Visual representation of active nodes.</span>

## Decisions that need explicit consensus

Some decisions affect everyone and need community buy-in, not just coordinator fiat:

- **Changing the default preset or frequency:**<span style="white-space:pre-wrap;"> Migrating an existing network to a new preset requires coordinating every node simultaneously - a major disruptive event. Don't do this casually.</span>
- **Adding a private or encrypted channel:**<span style="white-space:pre-wrap;"> 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.</span>
- **Hosting policies:**<span style="white-space:pre-wrap;"> What standards do infrastructure nodes need to meet? Who can call themselves part of the network?</span>

## Managing contributions from outsiders

As the network grows, people will want to add nodes. This is good - but uncoordinated growth causes problems:

- **Wrong settings:**<span style="white-space:pre-wrap;"> New operators who configure incorrectly fragment the network - nodes must share matching settings (region, modem preset, channel) to communicate at all</span>
- **Poorly placed nodes:**<span style="white-space:pre-wrap;"> 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.</span>
- **Abandoned nodes:**<span style="white-space:pre-wrap;"> Nodes that go offline and are never maintained degrade the perceived reliability</span>

**Solution:**<span style="white-space:pre-wrap;"> 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.</span>

## 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.