Turning chat into a knowledge base
The same question is asked in a community chat room every few weeks, and each time someone patiently answers it again. Meanwhile, a decision made in a late-night conversation is forgotten by the next meeting. The remedy is a knowledge base fed by the chat: a set of pages that captures what has been learned and decided. This article describes how volunteer networks build and maintain one.
Why chat needs a base
Chat is excellent for exchange and poor for memory. Searching old messages is slow, context is scattered across threads, and newcomers cannot read months of history. A knowledge base separates the durable part of a conversation from the ephemeral part. It also spreads knowledge beyond the few people who happened to be online.
What to harvest
- Answers to recurring questions. When a question has been asked twice, write the answer once as a page.
- Decisions. What was decided, by whom, when, and why. A one-line decision log is better than nothing.
- How-tos. Steps for recurring tasks: joining, setting up tools, preparing a meeting, publishing an update.
- Contacts and roles. Who looks after what, kept current.
- Useful links. Documents, articles and resources shared in passing.
How to harvest
A rotating "gardener"
Wiki communities have long described the work of tidying pages as "gardening": merging duplicates, fixing links, summarising discussions. Assign it explicitly, on a rotation, so that it is not left to the most conscientious member. A weekly half-hour is often enough for a small network.
Mark messages for later
Agree on a simple convention in the chat, such as a tag, an emoji reaction or a keyword like "FAQ", to flag messages worth keeping. The gardener collects flagged messages and turns them into pages.
Rewrite, do not paste
Pasting raw chat into a wiki produces pages nobody reads. Rewrite the content as a clear answer, credit the people who contributed it, and link back to the original conversation if logs are public.
Close the loop
When the question comes up again, answer with a link to the page. Over time, members learn to look there first.
Structure of the base
Simple structures last longest. A start page with a handful of sections (about the network, getting started, how we work, projects, decisions, frequently asked questions) is enough for most groups. Each page should say when it was last checked. Ward Cunningham's original wiki, launched in 1995, showed how far a flat collection of interlinked pages can go when everyone is allowed to edit, but it also showed that pages decay without regular care.
Tools
Any wiki will do, from a hosted service to a single-file wiki that can be carried offline (see a wiki on a flash drive). Some chat platforms offer bots that copy tagged messages into a document or a ticket; they save time but do not replace the rewriting step. Machine summarisation can produce a first draft of a long thread; a person should check it, since automated summaries can omit dissent or invent consensus.
Privacy and consent
Chat is informal, and people say things they would not want published. Before moving content from a chat into a public base, remove personal details and ask contributors whether they mind being quoted. Make clear which spaces are logged and which are not. In networks that work with people at risk, keep sensitive operational information out of the public base entirely.
Keeping the base alive
- Review the most visited pages every few months.
- Delete or archive what is obsolete; outdated instructions are worse than none.
- Invite newcomers to note what they could not find. Their questions show where the gaps are.
- Celebrate gardening: thank the people who do it, publicly.
Related reading: chat rooms for volunteer networks and archiving a community's conversations.
A worked example
Imagine a network of volunteer tutors who meet in a chat room. Over a month, the same three questions come up: how to join a session, which materials suit beginners, and what to do when a student stops attending. On Friday the week's gardener scans the messages flagged with a bookmark reaction. She finds two good answers to the first question, one from a coordinator and one from a new tutor who described the steps from a newcomer's point of view. She combines them into a "Joining a session" page, lists the steps in order, adds the date and thanks both contributors by first name. The second question has no settled answer: members disagree. Instead of picking a side, she writes a short page setting out the two approaches and the reasons given for each, and links it in the chat with a note inviting comments. The third question touches on students' personal circumstances, so she writes general guidance only and leaves out every detail from the original conversation.
The next time someone asks how to join, a regular replies with the link. Within a few months the room is quieter on routine matters and livelier on the questions that really need discussion. That shift, more than the number of pages, is the sign that a knowledge base is working.
Signs the base is failing
- People keep asking questions that the base supposedly answers: the pages are hard to find, or out of date.
- Only one person edits: the work will stop when that person leaves.
- Pages contradict each other: nobody has merged duplicates.
Sources
- Bo Leuf and Ward Cunningham, The Wiki Way: Quick Collaboration on the Web, Addison-Wesley, 2001.
- WikiWikiWeb, pages on "WikiGardening" and "WikiMaintenance": wiki.c2.com.
- Etienne Wenger, Richard McDermott and William M. Snyder, Cultivating Communities of Practice, Harvard Business School Press, 2002.
- Robert E. Kraut and Paul Resnick, Building Successful Online Communities, MIT Press, 2012.