A Case Study in Dysfunction

Mailing lists, as a discussion medium, particularily for online organizing, are dysfunctional and broken. Embedded in their nature is a discouragement of conversation, particularily the rapid back and forth which allows people to find common ground. As each email arrives, it raises the likelihood of earlier emails not being read. This culture has a tendency to produce, through social pressues, discussion that feels more like a duel, where each side is using mega-ton bombs, massive position statements, rather then negoiation and listening. These end when one side falls silent, leaving those left on the field unable to guess if agreement has been reached, or merely exhaustion. There are many possible solutions ranging in scope and feasibility, technological, and social fixes. I think the ad-hoc mailing lists of Roundupare one possible solution. But what follows below are some ideas about a making the tool that most activists use for email reading, some form of webmail, better at facilitating mailing lists. (there ideas came out of talking with Riseup and Threespeed)

Threading

Threading is an obvious feature. Mutt has had it for forever, Usenet had it since before forever, its defacto for Web discussion boards, and even stately Pine recently added threading. So why not webmail? Threading is a great feature, not only doesn’t it make conversations more coherent to follow, giving each message an explicit context, and reduce the associated cost of each arriving message, threads, if done right, can mean that conversations can last much longer then the few days a thought normally sticks around a busy mailing list, before it is pushed inexorably out of the field of whats current. We have not only context, but memory, and history. A wishlist for threading contains very little revolutionary. Messages should be able to be displayed in a threaded manner, threads some be collapsible, and one should be able to delete, or ignore (ie. delete any future message in the thread) an entire thread. Not sure what algorithm Mutt and Pine use for their threading, it might be worth checking out, because, unfortunately simply trusting the In-Reply-To header won’t be reliable out of the box, and threading on subjects, as some mail archivers do, is guarenteed to give you lousy resaults.

List Filtering

Simple filtering could go a long way towards dealing with the email overwhelm associated with mailing list. Either automatically or with a click of a button, my mail client should be able to detect a message as having come from a mailing list and send it to a mail folder, perhaps created on the fly, specific to that mailing list. It will be important to include visual and interface clues to the existance of these mailing list inboxes, perhaps borrowing the familiar visual language of bolding the name of inboxes containing unread messages, followed by the number of unread messages.
ListDetector, a plugin to Mail::Audit, contains recipes for detecting mailing lists, as does procmail-lib, so that shouldn’t be so hard. ### Other features

Mutt contains some interesting mailing list features including a super-charged Reply feature when replying to a mailing list, allowing you to guide response to yourself, the list, or both.

A subtle visual cue that you are replying to a list rather then an individual (how about setting the web pages background to bright red?) would cut down on the number of private messages that find their way to lists cutting down on uneccessary traffic, and reducing the neccessity of list admins to go mucking in their archives deleting old messages containing sensitive info.

Interface widgets for handling the standard interactions with a list like unsubscribe, and switch to digest mode wouldn’t be too hard, especially with lists like Mailman (potentially others?) which include a slew of List-* headers for that express purpose.

And speaking of digests, how about an intelligent interface for interacting with mailing list digests? Something that links internally, maybe even allows to reply to chunks of the digest, but at the vary least refuses to send out emails containing subjects like “Re: digest”