NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/os/vms/22035

Internet Message Format | 1993-01-27 | 12.1 KB

Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!mailgzrz.TU-Berlin.DE!math.fu-berlin.de!ira.uka.de!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!mccall!mccall!tp
Newsgroups: comp.os.vms
Subject: re: Re: Moderated VAX Info List?
Message-ID: <[e-mail]>
From: [e-mail] (Terry Poot)
Date: Tue, 26 Jan 1993 09:34:10 CST
Reply-To: [e-mail] (Terry Poot)
References: <[e-mail]>
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-Host: mis1
Nntp-Posting-User: tp
Lines: 215


[Sorry for the delay in responding, it's a long message and I waited till I had
the time to answer it properly.]

In article <[e-mail]>, [e-mail] (Jerry Leichter)
writes:
>Years ago (6-8, perhaps - yes, I've been an INFO-VAX denizen for a LONG time),
>calls for a DIGESTED INFO-VAX arose periodically.  They never went anywhere,
>and it's curious that the topic - and the closely related one of moderation -
>remained silent for so long.  My own objection to a digest is that it makes
>it difficult to respond to individual messages.  I like to be able to type
>REPLY, copy to INFOVAX, and edit my reply into the original message - as I'm
>(almost) doing here.

Also makes it hard to read a little at a time. while doing something else in
another window, which is frequently how I read news. With large digests, I print
them out and take them on breaks to read. That certainly makes replying
inconvenient, so I usually don't.

>...
>    I've long expected comp.os.vms/info-vax to die under its own weight,
>    and it seems to be happening.
>
>Here, I agree.
>
>                      I consider the use of a mailing list to
>    be the root cause.
>
>Here, I absolutely DISagree.  The INFO-VAX mailing list has been around for a
>VERY long time.  I don't know exactly how far back it dates, but I think I've
>been a subscriber since roughly 1984.  During most of its life, INFO-VAX has
>had a reasonably good signal-to-noise ratio, and while it's seen periodic
>flame wars, they have in the past died out fairly quickly.  In fact, the
>current flame wars easily exceed anything I've ever seen on this group,
>whether you measure number of postings, length of time, or even degree of
>vitriole.
>
>My own feeling is that the root cause is that it is the NEWSGROUP side that is
>to blame.  Flame wars are common on Usenet, even expected.  That attitude has
>spilled over to the mailing list side.  But there are other factors at work.

Depends, I guess, on how you look at the causality. The problems, IMHO, are
because info-vax is too large. It covers too broad a range of topics, and
therefore has a large volume of users who don't all share the same interests.
The volume almost certainly is attributable to the newsgroup. However, with a
newsgroup, you solve these problems by subdividing into more focused
newsgroups.

For example, on VMSnet, there is not only vmsnet.misc, which is directly
comparable (in topic) to info-vax. You also have vmsnet.sysmgt for system
management and vmsnet.internals (for internals, of course). Internals traffic
doesn't go to vmsnet.sysmgt and vice-versa. This reduces the number of people
and the volume in any one group, and the people in a group tend to have similar
interests and (to some degree) levels of expertise. This reduces the likelihood
of the sorts of flames we've seen here lately, which are caused by mixing
newbies with seasoned (but intolerant) veterans.

However, comp.os.vms can't be split, because the new groups wouldn't be
gatewayed to info-vax. mailing list users would continue to use info-vax, and
the split off groups would very likely fail. _That_ is why I blame the mailing
list, because it prevents the usual strategies for improving this situation. Not
that newsgroups are a magic bullet, but it reduces the propensity for such
things, making them less common.

>Call me elitist for saying so, but the newsgroup side has made it too easy for
>people to jump right it.  Joining a mailing list takes a certain amount of
>effort, and many people with only a tangential interest won't bother.

Many with a direct interest won't bother, because they don't feel that a mailing
list is a useful way to carry on such conferences. I'm certain I'm not alone in
feeling this way.

>Also,
>the volume of mail from this list drives off those who might join anyway.

Of course. Getting that much stuff in your mailbox obscures the important stuff
(mail from your boss), and is harder to sift through than news. Just 2 reasons
mail isn't good for conferencing. And of course, it will drive off as many good
people as "undesireables". Perhaps more. Knowledgeable people are busy people,
and are perhaps less likely to be willing to deal with a mailing list. (Pure
conjecture on my part, I have no data on this.)

>The connection to the newsgroup has made life much less pleasant for those of
>us left on the mailing list side.  Messages from the newsgroup side are often
>delayed for days before we see them; then, they often appear twice.

Those appear to be problems with the gateways. I frequently get responses to
postings within an hour or 2, and I'm on uucp, which introduces an average of 30
minutes of delay before my postings get to the internet. I got the emailed copy
of your article 23 hours before the posted one. Your reply was 2 days after my
article.

It appears there are significant delays in gatewaying the mailing list to the
newsgroup and/or vice-versa, or perhaps with the list reflector itself (though
you seem to imply that the delays don't occur between people on the mailing
list).

Based on the speed of responses I see to my articles, and the times on articles
I respond to, there is no such overall delay on the newsgroup side. The most
current article in comp.os.vms is in general, according to the Date: header, no
more than 2-3 hours old. (Spot check, currently the newest article is 50 minutes
old, second newest is under 2 hours; I only looked at the last 6 articles in the
group, so there may be more recent ones.)

>Most
>messages have no usable return address; this one is an example.  Until the
>great changeover, I could almost always use REPLY to reply directly to the
>poster of an INFO-VAX message; now, it's very rare for me to be able to.

We don't see that problem either. Most addresses are replyable. BTW, another
thing the gateway does wrong is it puts "Distribution: world" in each article.
Not all sites support this distribution (though they probably should). Leaving
out the distribution header is better. The Distribution header can only serve to
restrict articles. For best propagation, they should not be restricted at all.

>(My own personal choice is to send one copy of a reply directly to the poster
>and one to INFO-VAX itself, wherever possible.  I make an exception for people
>who ask for a reply only to them - in that case, I deliberately reply only
>to INFO-VAX.)

I may suggest that as a feature to the author of my news-reader. It is sometimes
annoying though, to get and answer such a message, not realizing it has also
been posted, and see it a few days later on the list. Do you dig out your reply
and post it (if you still have it)? A relatively small annoyance, but if I do
suggest the feature, I'm going to suggest he prepend a message saying the mail
message is a copy of a posted followup.

>               It focuses all the traffic in one place. More
>    tightly focused newsgroups, such as vmsnet.internals and vmsnet.sysmgt
>    have much higher signal-to-noise ratios.
>
>I follow these as well.  They are very low volume groups; I question their
>viability.  I think they survive only because they are linked to the larger
>"info-vax" complex.

You mean in spite of it. They are low volume only because of info-vax. People
still post here because of the large talent pool on the mailing list that can
not receive messages posted to the groups. Even if they cross-post, responses
from the mailing list will only go to comp.os.vms, of course, since the mailing
list can't preserve cross-posts. If the mailing list went away, I'm confident
comp.os.vms would gradually die out as traffic moved to VMSnet.

>In any case, except during high-flame periods, INFO-VAX has never struck me
>as covering too broad an area.  About the only thing one MIGHT split off are
>DECwindows/MOTIF related questions, which often to have a rather different
>flavor from other questions and seem to come from, and draw answers from, a
>slightly different community.  But there aren't enough of them to really be a
>problem. in my judgement.

The internals and TPU groups are good examples of focused groups that cover
their areas better than comp.os.vms does, draw posters not particularly active
on comp.os.vms, and aren't related to each other to speak of. We have some true
tpu experts in vmsnet.tpu who aren't in this group (or hardly at all). The
internals people are more active here than the tpu people, but not as much as in
vmsnet.internals. I think this shows that comp.os.vms is too broad, as those
constituencies left when they had a chance. Even the effects of the mailing list
haven't managed to hold them here.

OBTW, one reason you see a different crowd answering DECwindows questions is
those questions are crossposted to the X groups (comp.windows.x,
comp.windows.x.motif, etc.), and so some of the answers aren't coming from the
comp.os.vms/info-vax communities at all, but from the X community. Of course, if
you reply to such a posting on the mailing list, those people won't see it,
since the mailing list can't support cross-posting.

>A beginners/wizards split has also been proposed many, many times over the
>years - though, again, not recently.  (INFO-VAX went through a period of
>perhaps 3 or 4 years when there is remarkly little "meta-discussion"; it
>just seemed to work.)  I doubt this would work.  The problem, as always, is
>how to keep those who can give good answers to beginner's questions interested
>active in the group.

Agreed.

>My situation is exactly the opposite.  If a moderated mailing list were to
>appear, I would be glad to give it a try.  A newsgroup, of any type, is of
>no interest to me.

Different strokes...

>Let me explain why.  I follow newsgroups from my "day job" at Rutgers.  I
>read INFO-VAX here at LRW (my "night" job, as it were).  My system here does
>not receive news, nor will it until a very different kind of news program
>comes into existence.  Since I would be the only person reading news here,
>it makes no sense at all for news to stick around, waiting to expire, after
>I have read it.  Conversely, when I'm away and DON'T have a chance to read
>news, it should NEVER expire.  The mail model is exactly right for the way I
>use this system; the news model is exactly wrong.

I've got some DCL code that could be modified to do that fairly easily. You'd
simply set the expiration interval infinite, and then run a periodic DCL job
that would delete articles that you've read. I do this with source groups. I
never automatically expire them, because I don't want to miss anything. After
I've read some or all articles in a source group and done whatever I want with
them, I manually run a DCL proc that deletes all the articles I've read, and
leaves those I haven't alone.

The nightly skim job then updates the ANU indexed files to note that the files
are gone. This is works great. The only difference for you would be that you'd
do it on all groups, rather than a select set, and you'd do it in a repeating
batch job rather than manually.

I find this superior to getting the source postings in mail. The reason I do all
this in the first place is so I can let them sit there until I want to deal with
them. I don't want them cluttering up my mailbox. I'd probably file them off to
some folder, never to be seen again (except indirectly in disk usage
summaries!).

I think it might be more profitable for you to focus on the conferencing and
user interaction model that makes the most sense to you. Management can always
be automated, and if the default methods don't suit you, they can be adjusted.
--
Terry Poot <[e-mail]>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
[phone], in KS [phone]           Manhattan, KS 66502, USA