WikiAsMailingList

MeatballWiki | RecentChanges | Random Page | Indices | Categories

MailingLists often cycle through the same problems and solutions over and over again. While the traditional solution is to create a FrequentlyAskedQuestions? (FAQ) file and periodically post it, this is a hack, since the problem is in the essential nature of the list. The list is a temporal and chronological stream, that is unnavigable from a semantic or topic sense. If you miss a discussion, you will have to wait for it to resurface, which is why people bring up the same common problems over and over again. The knowledge in a MailingList is the CommunityLore built up in the list. The only way to access it is by querying people.

This wastes the benefit of the LifeInText aspect of OnlineCommunity. If the discussions were saved, at least one could read them before duplicating them. Half the problem of mailing lists can be alleviated simply by publishing easy to search archives of the list. At least then people can search through the past discussions before asking the same question again. Additionally, search engines can index the archives. However, the probability that someone will find a previously asked question is related to how recently it was last mentioned and how much traffic on the list it generated in numbers of messagees. Moreover, the relationship is inversely exponential, the probability that people will read previous material on the list drops off dramatically. That is, relying on your participants' FirstReadings is not really very good.

So, while mailing lists are good for chronologically ordered discussions, like event planning or chit chat, they aren't very good at retaining and organizing knowledge. (cf. DiscussionBoardVsWiki)

Therefore, use a wiki to retain knowledge on a mailing list. This can be done manually through the same process as a FAQ by simply making the FAQ a wiki. For the most part this works well, but this can be a significant waste of ideas. After all, FAQs often lag behind the ongoing discussion quite greatly. Thus, instead, it would be ideal to automatically archive the mailing list to the wiki. Every e-mail becomes a page. Or even better, every subject line becomes a page, and all e-mails on that subject get appended to a page.

Then readers can refactor the archive as they see fit. As questions get raised, they can be answered very quickly in single responses. Or the archive/wiki can be reorganized as a FAQ or a manual or anything else to help questioners find information quickly within bothering the list. Moreover, over time, answers can be refined and developed into very powerful and detailed answers, rather than giving the same simple answer over and over again.

People used to this will start putting WikiSyntax into their e-mails on the list. If you prefer a LinkPattern like CamelCase for this wiki, they will start putting CamelCase into their e-mails. Then you can refer directly to ideas you have extracted out of the mailing list into their own separate pages.

One doesn't even have to write a mailing list module for a wiki. Rather, a NetworkService? is better. One merely needs to be able to e-mail the wiki, and have the wiki save that e-mail. Then you just add the wiki to an existing mailing list, like a Yahoo! group. This then benefits from all the mailing list features that mature list servers offer, including their own uneditable archives.

Who knows, people may even switch entirely to the wiki rather than use the mailing list.

Examples

CategoryWikiTechnology

I'm investigating the viability of running a wiki for some niche groups, instead of simply setting up a mailing list. I'm tired of mailing lists - they are useful, but they don't move forward like a wiki does. Hence the choice of a wiki.

Problem: any group/community has a need for disseminating time sensitve announcements and the like. One example would be a film maker putting out a casting call notice.

Solution: let them create a page for each such notice.

Problem: lots of little pages that quickly expire in usefulness, thus creating noise.

Solution: create centralised pages for types of notices instead (eg. CastingCalls).

Problem: interesting notices will generate discussion and questions, even after the event, and this churning will cause the centralised page to reappear on RecentChanges, looking like a new notice has been posted. False indication, noise.

Solution: divert discussions on individual notices to a sub page for discussions, or encourage discussion to be diverted to the poster's home page. For exceptional and notable events, a dedicated page would perforce spring up. Use SoftSecurity and CommunitySolution here, not HardSecurity/TechnologySolution.

Wanted:

opinions as to whether this might work
examples of this on other wiki's
a suitable name to break this onto it's own page

I tried more than once to do this on my own wiki, and eventually decided that the best solution was to stick with a mailing list for time-sensitive announcements. E-mail was simply a better tool for some tasks. -- MattBrubeck

WikiAsMailingList

I really like the idea of Wiki and mailing list integration. The above post seems to focus on the idea that the Wiki is primary, but communication reverts back to mailing-list mode for time-sensitive info. This can be a tough sell to Wiki newbies.

An alternate solution would be to have a feature that automatically sends mailing list posts that have WikiNames in the subject line to a special subspace on the wiki. The mailing list archive could not be edited, but they could be mined for text for Wiki pages. Also, any WikiNames in the page would be linkable. -- SteveHowell