Colin Runciman <[EMAIL PROTECTED]> wrote:

> I also agree with Simon that simply making this a moderated list is
> not the solution.  Perhaps splitting is best.  How about
>
> haskell-info
> haskell-talk
>
> where info carries *brief* announcements, requests for information
> and responses to such requests, and talk carries anything and
> everything else appropriate to a Haskell list.

Of the suggestions so far, this is the one I like best. Another writer had
suggested "haskell-announce", but I prefer Colin's idea of "haskell-info",
combining announcements with some q&a but no extended discussions. Any
threads lasting beyond a few messages could move to haskell-talk. For those
of us who want everything, there are two possibilities that come to my mind
offhand:

(1) All haskell-info traffic could be automatically copied by the list
server to haskell-talk, effectively making haskell-info just the "low
bandwidth" version of haskell-talk; or

(2) Readers could subscribe to both lists, and optionally use mail filters
to merge them into one folder locally.

I'm slightly inclined towards (1) just because I don't see why anyone
subscribed to haskell-talk wouldn't also want to read the haskell-info
messages, and it would be nice to not need to remember to update two
subscriptions when changing email addresses or unsubscribing.

All this seems somewhat less than ideal, though. I think the real problem is
that most mail clients don't have killfiles the way newsreaders do (unless
your newsreader is also your mail client, perhaps). I would like to be aware
of all topics in all the Haskell lists, but not have to bother with a given
thread once I've decided it doesn't interest me. In a newsreader, I can kill
just the threads I don't like, and not even see subsequent followups. Even
in fairly busy newsgroups, this is an effective tool for controlling
perceived traffic levels. Mail clients, unfortunately, generally don't
support such a capability. So unless moving everything to comp.lang.haskell
is a viable option, I think splitting the list into haskell-info and
haskell-talk is the best option.

Craig





Reply via email to