# Community Operations
# 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.
# Emergency Preparedness Integration
A well-established community mesh is a natural complement to emergency preparedness programs. Many mesh networks find their most compelling use case in disaster response and preparedness exercises.
**Important:** A community LoRa mesh is a best-effort, low-bandwidth, supplemental tool. It is NOT a replacement for established emergency communications (public-safety radio, amateur radio nets, 911). Delivery is not guaranteed, and the mesh works only where its own powered nodes remain within RF range. Do not build life-safety plans that depend on it as the primary or sole channel.
## Why mesh is valuable for emergency preparedness
- **Independent of cellular/internet infrastructure:** A mesh does not rely on cell towers or the internet, so it can keep working when those are down - but only for nodes that still have power and remain within RF range of a working repeater. It depends entirely on its own infrastructure (repeater siting, battery/solar reserves, RF propagation) and is best-effort and low-bandwidth, not guaranteed delivery. Treat it as a supplement to, not a replacement for, established emergency communications.
- **No subscription:** Critical communications infrastructure shouldn't depend on a vendor's servers being up
- **Group awareness:** Position sharing can give a rough shared picture of team locations, but updates are best-effort and may be delayed, stale, or dropped under congestion or marginal RF. On a public channel, positions are visible to anyone in range. Use it as supplemental awareness, not authoritative tracking; consider a private channel for team operations.
- **Optional store-and-forward:** By default, mesh messages are not stored - a recipient who is offline when a message is sent generally does not receive it later. Store-and-forward re-delivery is optional: Meshtastic requires a dedicated PSRAM-equipped Store & Forward server node (usually on a private channel), and MeshCore provides it via Room Servers. Plan for missed messages and scheduled re-check-ins, not automatic re-delivery.
- **Low training burden:** Text messaging is a skill everyone has
## Building relationships with ARES/RACES and CERT
Amateur Radio Emergency Service (ARES) and Community Emergency Response Teams (CERT) are already organized around exactly the use case mesh networks address. Approaching these groups early builds the human infrastructure alongside the technical infrastructure.
Practical steps:
1. Attend a local ARES or CERT meeting and introduce the mesh network
2. Offer to demo the network at a training exercise
3. Provide devices to ARES section and club leadership at no cost (community investment)
4. Run a mesh-integrated tabletop exercise with emergency management
## Emergency preparedness network design
A preparedness-focused mesh should prioritize:
### Resilient power
Aim for infrastructure nodes that can ride through a multi-day outage - a common target is 72+ hours of reserve - but treat this as a sizing goal, not an automatic property of any solar node. Size the battery for worst-case (winter/overcast) solar yield, account for cold-weather battery cutoffs, and verify real runtime by test. A repeater that fails when the grid goes down is worthless for disaster response. Review your power systems annually before storm season.
### Known coverage gaps
Document where coverage fails. Know which valleys, neighborhoods, or facilities are in shadow from your current repeater network. Plan secondary coverage nodes for those areas before a disaster, not during one.
### Designated net control
Identify which node serves as net control during an emergency (typically the best-connected infrastructure node or a dedicated gateway with internet uplink). Pre-establish procedures: how will net check-ins work? What's the reporting format?
### Paper backup procedures
Mesh configuration should be documented on paper and stored physically at net control locations. If the operators who know the settings are unavailable, someone else must be able to deploy a node correctly. Include the actual reproducible fields: Region, Modem Preset, LoRa frequency slot, channel name, PSK/key, role settings, and the network map. Region and Modem Preset must match across all nodes for them to communicate.
## Running a mesh-integrated exercise
A simple first exercise to demonstrate value:
1. **Scenario:** Simulated grid-down event; cell towers overloaded or offline
2. **Participants:** 5 - 10 people, each at a different location across the coverage area
3. **Exercise:** Each participant checks in with their GPS position and a status report; net control acknowledges and tracks all positions
4. **Evaluation:** Which nodes didn't check in? What coverage gaps were revealed? What configuration issues appeared?
After the exercise, write up the after-action report and share it with emergency management. This demonstrates real operational value and opens doors for formal integration.
## Connecting to existing emergency communication systems
As noted at the top of this page, mesh radio is not a replacement for existing emergency communication infrastructure - it's a supplemental addition. Key integration points (note the amateur-radio licensing requirements below):
- **APRS:** A gateway node running APRS bridge software (e.g. aprstastic) can relay position data to the APRS network, making mesh positions visible on aprs.fi to operators with no mesh hardware. Transmitting onto the APRS RF network (e.g. 144.390 MHz) requires a licensed amateur operator and proper station identification (a valid callsign); only a licensed ham may operate an RF APRS gateway. Unlicensed APRS RF gating is not permitted.
- **WINLINK:** Winlink is an amateur-radio email system; sending or receiving over RF requires a licensed amateur operator, and there is no standard supported mesh-to-Winlink bridge - any link is a custom, manually operated arrangement. Consult your regional ARES coordinator and a licensed Winlink operator before attempting this.
- **ICS-213 forms:** Many emergency management teams use ICS forms for structured reporting; a simple template-based approach for mesh messages can align with this