[third attempt to avoid being blocked with: "Message has a suspicious header":-(]
it's not obvious to me that both of those needs should be served by a single list. I believe it's important that the mailing lists served by haskell.org should have clear non-overlapping topics.
For those cases where it isn't clear yet whether a spin-off mailing list would survive, for partially overlapping topics, and for those cases where a good idea didn't work out (haskell@), perhaps Mailman's topic filters are an option? Quick summary: http://mail.python.org/pipermail/mailman-users/2007-August/058042.html List Member Manual http://www.gnu.org/software/mailman/mailman-member/node29.html The idea being that beginners and overloaded advanced list members are in the same boat - they want to see the stuff relevant to them, not the whole flood of messages. For the latter, we currently have haskell@ (discussion starters and announcements), which doesn't quite work as intended, as haskell-cafe@ is the list to use if you want to see responses. So discussions start on haskell-cafe@ anyway, and announcements get copied to both lists.. There have been suggestions to rename haskell@ to haskell-announce@, but whether that would help? If topic filters were used instead, we could recommend: - current haskell@-only users: subscribe to haskell-cafe, topic [ANN] only; will keep your volume low - beginners: subscribe to haskell-cafe, topics [ANN] and [beginner] (is there a way to make that the default topic selection for new subscribers?); will protect you from confusing advanced discussions, until you feel ready for or curious about them - current haskell-cafe@ and haskell@ users: you can drop your subscription for haskell@ - current haskell-cafe@ users: just keep reading everything, or use the topics system to filter out some topics; might also get some haskell-cafe@-dropouts back?-) The [beginner] topic regex would have to cover newbie, etc, but I guess it could grow with time. If a topic really takes off, there'd be clear evidence for a new list, but seasonal topics, like [databases], [web], [arts], etc, could simply remain in the main list, reducing the need to garbage collect old unused lists. That is all assuming that this stuff works as advertized, and that managing topics isn't more work for our list admins than managing lists!-) Claus