Re: Regarding the splitting up of mailing lists (I guess i should say something, since i seem to be running this :)

[Scott Yellig <syellig@xxxxxxxxxxxxxxxx>]

Man, i leave for a morning, and suddenly theres all this talk about
starting a bunch of specific lists, and moderation! :)

I guess ill start with my views on what should be done, and then talk
about the technical.

Personaly, I dont mind getting a lot of email from the group, since I dont
get much else. I can, however, see why people would want to only subscribe
to an announce list, and not be bothered with all the email with questions
and discussion. As of now all the division that i see as being necessary
is this:

	One for announceing meeting topics, and one for all the general
	Geek Chatter (A good name for the other list, no? 
	geek-chat@klug.armintl.com :)

As a useful side effect of breaking the list
up, we could easily archive the announcement list into something sane, and
post it to our web server.

The possible exception that i see is making a list for current group
projects (for example, right now there seems to be a lot of talk about
what do with our table at the computer shows). Im not sure if we really
need to make a seprate list for each project, as theres not THAT
much traffic generated by discussion about projects in general)

And for the technical, the following is the contents of the smartlist
manual, which should give a good idea what we can and cannot do.

I suppose the only relevant ones would be:

3f. moderation (that is to say, yes we can moderate it if thats what is decided)
3e. Autosending files to new subscribers (we can send out a FAQ when
	people join)
3c.Restricting submissions (we can have an announce only list, where no
	one can submit)

Alright, i think now im going to jump down and talk about the points that
bob brought up specificly

--- begin ---
Contents:
---------       1. Creating and removing mailinglists or archive servers
                2. Remote maintenance of mailinglists
                3. Customisation
                3a.Digest processing
                3b.Restricting subscriptions
                3c.Restricting submissions
                3d.Auto subscription on first submission
                3e.Autosending files to new subscribers
                3f.Moderated lists
                3g.List of lists
                3h.Positively discriminate certain daemons
                3i.Default help text replies
                3j.Unsubscribe assistance
                3k.Exploding other (non-SmartList) lists
                3l.Schematic overview of what goes on behind the scenes
                4. The archive server
                4a.Sending files to the archive server
                4b.Restricting access to the archive server
                5. The format of the dist file
                6. Multigram and the thresholds in rc.init/rc.custom
                7. Choplist & sendmail
                8. FTP addresses & the SmartList mailinglist

--- EOF ---
--
-------------------------------------------------------------------------------
         Finger syellig@deepthought.dyndns.com for PGP public keys.
-------------------------------------------------------------------------------

On Mon, 13 Jul 1998 bob@acm.org wrote:

> A couple of people have pointed out that there is too much traffic on the KLUG 
> mailing list, and it's been a cause for some people dropping off the list. A 
> split in the list has been suggested, and on the whole, it's a good idea. If we 
> can support robust activity on more than one mailing list, it's a good sign
> that people are interested, and that the group is growing in depth, not merely 
> in numbers.  My only note of caution is that we think ahead a little, maintain a
> sense of togetherness, and perhaps try to anticipate what will happen if we try 
> to divide the list even further. Some impressions:
> 
> 1. All members of any KLUG mailing list should get stuff sent out via a
>    "klug-announce" mailing list. If we don't do this, we can quickly lose
>    group-wide communication.
> 
>    Existing software might not support this; we would not want anyone to get
>    multiple copies of the same message. However, I'm not as concerned about
>    the features/limitations of the software as I am about the idea of making
>    sure everyone is informed about group events. Surely we can change the 
>    software to comply with our needs.
I love smartlist, dont change it ! :)
OK.. Im not sure exactly why the current software would not support this.

Theres a couple way that we could make sure the announcements get to
everyone:
	1) have the announce group send its messages to the discussion
	group (as in, a user joins the announce group OR the discussion
	group based on how much mail that want)

	2) have it not send it :P... (everyone joins the announce, and
	only those who wants tons of email join the discussion group)
> 
>    I don't know about moderated groups. They're fine, but they are a commitment
>    for the moderator, depending on traffic load. Moderation works well for some
>    USENET groups, but such groups rarely have threads of discussion, the moder-
>    ator becomes too involved in editing at that point. Two that come to mind are
>    COLA and comp.risks, and neither exist for "discussion".

Im thinking about maybe an announce group where things can be only sent by
me (or the listserv user, or whatever). And then, on messages from this 
announce list set the Reply-To: line to the discussion group, so people
know where to send replies if they want to talk about an annoucement. And
then the people who dont enjoy digging though 20 messages a day talking
about SCSI drivers and penguin banners :), could recieve only the
announcements.

As far as moderation, my only objection is that I wouldnt want to have to
decides who should be heard and who shouldnt. I wouldnt want to have
anyone else decide this, either.

> 2. I see a lot of traffic that I think of as "newbie Q&A". While we're splitting
>    up into groups, we might want to consider a "klug-sartup" mailing list for 
>    these threads. People who want to answer these questions can then do so, but
>    into a group that really wants to see these answers.
> 
>    I don't want to push these issues off into the corner; quite the opposite,
>    if we have a lot of this type of activity, we can channel it better, and
>    build a mailing list that has focus.

IMHO, it WOULD infact push these questions off into the corner, but who
knows.

> 3. I would suspect that as we develop more organization, we'll have mailing 
>    lists that deal with projects as well as necessary organizational stuff.
>    There's no need to clutter up a central mailing list with messages that
>    only a subset of volunteers or project workers will need to see.
Yup.
> 
> 4. On a point related to item 2, it may be useful to develop a local Linux
>    FAQ list. Before you say "OH NO, Not ANOTHER Linux FAQ!", think about it
>    a little bit. Many of the questions asked by people new to Linux are NOW
>    ALREADY ANSWERED on existing Linux FAQ lists, and in USENET, so why do we
>    get these questions at all?  The answer is simple; people who are new to
>    Linux aren't yet geared to handle many of these sources of information,
>    which is its very own kind of learning curve.
> 
>    Imagine the benefit of a well-run mailing list for new Linux users, com-
>    plete with its own FAQ, handled and modified according to the questions
>    we actually see here. This kind of mailing list would serve as a great
>    forum for all kinds of problems, and would serve to help steady people
>    as they become for familiar with Linux.

Hmm.. as long as armintl doesnt mind paying moveing all the bits around,
sure, we can help people all over the world.

> 
> 5. If we split the mailing list up into two (or more) groups, would the people 
>    who have departed come back?
> 
>    I ask this question, hoping that any of those who read this message can
>    contact them, and at least inform them that a split has taken place. We
>    might see if these folks stick around in one of the resulting groups,
>    given that there's less traffic there.
> 
> What is our goal in building more mailing lists? If its to minimize the 
> amount a mail a few people get (so they don't drop out), it doesn't sound
> like the right choice. I've seen the term "spam" used, and so far I have seen no
> spam on this mailing list (spam isn't mail that doesn't turn you on, you know), 
> so that's not an issue. If people want LESS content, they can delete messages 
> without reading them, or drop out. We're not in the business of dumbing down 
> anything, or providing less content.
> 
> HOWEVER, If we're doing this in order to improve our focus in areas of interest,
> it's a good thing, mostly by promoting focus without annoying anyone who's not 
> interested. Let's do this with our eyes open, and to become more effective. We 
> don't have to act on all of these suggestions at once, but we can keep them in 
> mind as we continue to grow and diversify.
Sounds good.