For decades mailing lists and IRC were the only tools available to open source projects. And they built cities on top of them. Apache HTTPd, Linux, and MySQL were all built on mailing lists. Emails flying back and forth between groups of people who had never met and were only connected by their interest in helping out on a specific project.
Now there are many more tools in your toolbox. You have Twitter, Facebook, blogs, wikis, and many more, but the lessons learned with mailing list management are still important. A well maintained mailing list isn’t just a place to chat, but a record of the project. It shows you why you made decisions the decisions you made and what direction you should go in the future.
Twitter is useful, but it can feel like opening the floodgates. Wikis help your team organize, but without constant maintenance they get overgrown with weeds. Start using more than one system and the cross-talk gets overwhelming.
The only way to make these systems work together is to consolidate information. Adding new information is easy; even a small team can create an overwhelming amount of information in a very short time. If the knowledge in these systems isn’t managed, then it will become redundant, overly complex, and useless.
Create metadata. Every time you create a wiki page, blog post, or any other shared document it needs metadata that describes what’s in the document. This can be a short email subject, a descriptive introductory paragraph, or a formal document abstract. Forcing yourself to stick within the boundaries of your stated topic will also make a big improvement to your writing.
Organize in larger groups before smaller ones. When organizing the data of your team you should start with a few large categories. For each system you have to decide what it should be used for. You can drive this discussion within your team. Once you have to decided on the larger categories you can further categorize within each of them.
Create naming conventions. Your team has to decide on naming conventions to govern mailing list subjects, wiki page names, and bug descriptions. You have to push them to standardize. It doesn’t matter what naming convention you choose as long as you stick with it.
When you write something, sign your name. Make it really clear what you write. Put your name on your documents in a prominent location. If someone else helped you, put both of your names.
Don’t create redundant information. Before you add any new information you should make sure it isn’t there already. Linking to existing information will enhance that information, but copying it will create redundancies which make the system more difficult to manage.
Continually refine. Following all of these guidelines will help a lot, but your systems will still become disorganized over time. You need to constantly reexamine your categories and documents and make changes to further improve the system.
Work with the tools, not against them
Every information storage solution has specific benefits and issues. Don’t put design documents in your forums or try to communicate with your customers in your wiki. You can’t use one system to solve all of your communication needs.
A wiki stores information differently than a bug tracking system or a mailing list archive. For every piece of information you share you need to choose the correct venue. Pick a method of communication that matches your content. Don’t post a bug report on your wiki just because it is likely to get read.
The consolidation of information is a vital practice for any team. It will make the team more efficient and will make it much easier to introduce new team members. It is also an important step in removing impediments to communication. Maintaining a low cost of communication is critical to succeeding as a teleworking team.