What follows is an untested programmatic method for reducing the flame percentage of any given mailing list. I call it tree-trimming. Since I don’t know Python, I am unlikely to hack this method into Mailman, and since Majordomo is old and grey I’m unlikely to hack it into Majordomo. But one never knows.
Basic Assertions/Observations
- A piece of email sent to a mailing list can be filtered in any way we find useful. We can block it entirely, we can send it on to the list, we can send it to a subsection of the list, or we can send it to a different list.
- Email is threaded; the In-Reply-To: header usually tells us what a given piece of email is responding to. Not always, but usually.
Those are easy. Here’s the controversial one. This will not be true for all mailing lists.
- Email threads that are made up of a small number of people talking to one another are, after a certain point, usually not interesting to the entire mailing list.
List Setup
I’ll postulate a list called, oh, example-list. There are two actual mailing lists associated with the example-list: example-list and example-list-full. You can subscribe to either one of them.
Thread Tracking
- The mailing list software tracks threads. It must store, for each thread:
- The thread’s age (which we’ll call A).
- The number of active participants in the thread (which we’ll call N).
- The email addresses of the active participants in the thread.
There ought to be a method for associating a thread with an email even if it doesn’t have a In-Reply-To: header, since some mail readers don’t handle this well. You could do it by Subject: line, in which case time needs to be taken into account. You don’t necessarily want all emails with a common subject to be grouped in the same thread, so after a while emails with the same Subject: should be considered a separate thread. Or maybe not, I dunno.
Probably the thing to do is to look at mail reader algorithms. They would tend to define the best practices for this question.
People replying to digest emails aren’t really a problem, because a thread change as a result of that behavior happens at the beginning of a long tedious flame thread, not during.
List Functionality
For each piece of mail that hits the list, the mailing list software must:
- Compare A to a configurable value (A1) and N to a configurable value (N1).
- If A > A1 and N < N1 OR if the thread is marked as full-only:
- Send the email to example-list-full.
- Send the email to all the active participants in the thread.
- Mark the thread as full-only.
- Otherwise, send the email to example-list.
I.e., if the thread is over a certain age and only (say) 2 people are participating in it, then only those people and anyone subscribed to example-list-full should get the email. Everyone else gets to automatically ignore it.
Improvements
Apply this to subthreads as well. Maybe the main thread is active and happy, but a couple of people are just talking in their own little subthread. We don’t care about them any more. This would require keeping track of the entire tree structure of the thread, but it would be cool.
Observations
You could implement this as a client side filter as well. Probably even in procmail. It’d be easier, since you wouldn’t have to keep track of the active participants. However, I don’t actually have any objection to general solutions, because I have found that most client side solutions to flame wars assume that everyone has good self-control.
You have to make it impossible to pull threads out of full-only, or malicious people will subscribe to the -full version of the list solely for the purpose of dragging threads back to the general list.
I have no idea what the useful value of N1 and A1 are. They probably vary from list to list.