Chat rooms for volunteer networks: when real-time talk helps
Most volunteer networks live on slow channels: email lists, forums, wikis. A chat room adds something different, the feeling of people present at the same moment. Used well, it builds trust and speeds up decisions. Used badly, it excludes anyone who is not online at the right hour and buries important information in a stream of messages. This article looks at what live chat is good for and how to run it.
A short history
Internet Relay Chat, written by Jarkko Oikarinen in Finland in 1988, set the pattern: named channels on a network of servers, joined by anyone with a simple client. Its protocol was described in RFC 1459 in 1993. For two decades IRC was the default meeting place of open-source projects, and many still use it. Web-based chat rooms, which needed nothing but a browser, made live talk accessible to non-technical volunteers from the late 1990s. Later came commercial team tools such as Slack (2013) and Discord (2015), and open, federated alternatives such as Matrix (2014). Messaging apps like WhatsApp and Telegram now host countless community groups, especially where mobile phones are the main way online.
What live chat is good for
- Getting to know each other. Informal conversation builds the relationships that make later collaboration easier.
- Quick coordination. Deciding who does what in the next hour, during an event or an emergency.
- Helping newcomers. A question answered in minutes can keep someone who would have given up waiting for an email reply.
- Scheduled meetings. A chat meeting with an agenda and a fixed time can include people who cannot join a voice call because of bandwidth, cost or hearing.
What it is bad for
- Decisions that affect everyone. People in other time zones or with less free time miss them. Final decisions belong on a slower channel, with time for comment.
- Information that must be found later. Chat scrolls away. Anything important should be copied to a wiki page or a mailing list.
- Disagreements. Short messages, fast replies and missing tone make conflicts escalate. Move difficult conversations to longer formats or to a call.
Running a chat room
Welcome people
Pin a short message explaining what the room is for, where to find documentation and how to ask for help. Ask regulars to greet newcomers by name. A silent room is intimidating; a room where only insiders joke is worse.
Mind time zones
Rotate meeting times so the same people are not always asked to join at night. Post the time in UTC and in the main local times. After each meeting, publish a short summary.
Keep it light
Choose tools that work on old phones and slow connections, and that do not require a new account on a commercial platform if members are reluctant. Text-only chat uses very little data.
Set rules and enforce them
A brief code of conduct, a named moderator and a clear way to report problems protect the room. Moderators should act early and privately where possible.
Decide about logs
Some communities keep public logs of every word; others keep nothing. Both are defensible, but members must know which applies. Public logs are useful for transparency and for those who missed the discussion, and they make people more careful about what they say. If logs are kept, say so at the top of the room, and offer a way to remove personal information. See archiving a community's conversations and turning chat into a knowledge base.
Chat in a crisis
During emergencies, chat rooms become operations centres. Volunteer responses after disasters and during political violence, such as Kenya's crisis in 2008 (see our account), showed both the strength of live coordination and its dangers: unverified rumours spread as fast as facts. A crisis room needs a separate channel for confirmed information, a person responsible for checking it, and strict rules about sharing names and locations.
Choosing a platform
| Need | What to look for |
|---|---|
| Low bandwidth | Text-first clients, no mandatory video or heavy web app |
| Control over data | Open protocols, self-hosting or federation, export of history |
| Easy entry | Join from a browser link, no phone number required |
| Accessibility | Screen-reader support, keyboard navigation, readable contrast |
| Longevity | Export formats that will still open in ten years |
A model meeting in chat
Text meetings work best with a little ceremony. A typical format used by many open-source projects runs like this. The chair posts the agenda a day in advance, with links. At the start time, the chair asks people to say hello so that everyone knows who is present. Each item gets a fixed slot; the chair announces it, invites comments, and closes it with a one-line summary beginning "Agreed:" or "Action:", followed by a name. Side conversations are moved to another channel. At the end, the chair asks whether anyone who has not spoken wants to add something, then posts the summary to the mailing list or wiki within a day. People who could not attend have a set period to object before decisions become final.
This structure may feel formal for a small group, but it protects those who type slowly, write in a second language or connect on poor networks, who otherwise struggle to get a word in.
Sources
- J. Oikarinen and D. Reed, Internet Relay Chat Protocol, RFC 1459, IETF, May 1993: rfc-editor.org.
- Matrix.org Foundation, specification and project history: matrix.org.
- Robert E. Kraut and Paul Resnick, Building Successful Online Communities, MIT Press, 2012.
- Karl Fogel, Producing Open Source Software, chapter on communications: producingoss.com.