Network Documentation Standards
A community mesh network that isn't documented is one resignation or one hardware failure away from being unrecoverable. Documentation is not overhead - it's the infrastructure that makes the physical infrastructure maintainable.
What to Document
For every permanent repeater, record:
Beyond individual nodes, document:
Using the WikiLibrary
Mesh America WikiLibrary provides a repeater reference template. Fill one out for every permanent node in your network. Keeping this information in a shared wiki rather than a single operator's notes means the network survives personnel changes.
Update the wikilibrary entry whenever hardware changes, firmware is updated, or maintainer contact information changes. Stale documentation is worse than no documentation because it misleads the next person who needs to act on it.
Repeater Naming Conventions
Choose a consistent naming scheme before you deploy your first permanent repeater. Changing it later is painful - nodes appear on maps and in message logs, and inconsistency creates confusion. Common options:
MeshAmerica-WestHills-1 - Human-readable, easy to orient on a mapKD9XYZ-SiteA - Ties the node to a licensed operator, useful for EmComm accountabilityPDX-Repeater-01 - Simple, scales cleanlyPick one scheme and document it. New nodes added by new community members should follow the same convention.
Channel Documentation
Publish your channel name and modem preset publicly - on your Discord, website, or wiki. New participants need this information to join the network.
Do not publish the PSK publicly if your community uses a private channel for security. Share the PSK via QR code to verified participants only. The QR code contains the full channel configuration and is the standard mechanism for onboarding new nodes.
Firmware Version Tracking
Maintain a log of when each node was last updated. Meshtastic firmware is actively developed; nodes running outdated versions may miss bug fixes, compatibility improvements, or security patches.
Schedule a quarterly firmware review: check each node's current version, identify which nodes need updates, and coordinate with site maintainers to get access for updates. A node that hasn't been updated in over a year should be treated as a maintenance priority.
Incident Log
When a node goes offline - whether due to weather, power failure, hardware failure, or vandalism - document:
This institutional knowledge prevents repeat failures. The second time a solar controller fails in a cold snap, the person responding should be able to find a record of what worked last time.
Succession Planning
Community networks outlast individual operators. Plan for turnover: