Communicating with your calendar owners

Status: placeholder. This guide will be written before launch.

Calendar owners on your instance need to hear from you sometimes — the upgrade is happening Saturday morning, the federation policy is changing, the instance is moving to a new server. The mistake admins make is either communicating too little (people find out something changed because something broke) or communicating too much (announcements stop being read). This guide is about pitching it right.

Planned scope

• The channels available to you: instance-wide email (transactional, not promotional), an admin announcement surface if your instance has one, a status page or system calendar, individual mail when the message is targeted
• Which channel fits which message: downtime is email and a status post; policy change is email plus a longer-form public note; an upgrade that you expect to be invisible is an after-the-fact note in the changelog; a security rotation that logs everyone out warrants an advance email and a follow-up
• Writing the announcement: lead with what changes for the reader, then the timing, then the why. The admin-jargon version ("we're rotating session secrets") becomes the user-readable version ("you'll be logged out tomorrow morning")
• The tone calibration: warm, not corporate; honest, not hedged; specific, not "we're committed to communication"
• The post-incident note: what happened, what you did, what you're changing, what you can't fix. Public-radio-style transparency builds the same kind of trust the funding model assumes
• Rate-limiting yourself. An admin who emails the calendar owners once a quarter is read; one who emails monthly isn't