filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (01/06/90)
In article <702@hq.af.mil> Keneth Illgen writes: > Why do we need to have this group moderated? People write that a >moderator would be there to correct errors <maybe> and question what >one might mean in a statement. To me, that doesn't seem like enough to >show the need for a moderator. > Under what circumstances would a moderator of this group not post >an article <with the exception of those articles that would not be related >to movies whatsoever>? If I write an article regarding some aspect of a >movie could I expect it to be returned if the moderator didn't consider >it to be serious enough? Moderation causes prior restraint. It is not so much that the moderator manually filters out flames and pointless postings, but that readers are far less likely to post such articles in the first place when they understand that a moderator will be screening their article before it is posted. Another effect is that if a simple question is posted and 15 people post similar replies, a good moderator should post the first (or best) of these and add a footnote that many other people also responded. I'm not sure how much of a concern that is in rec.arts.*, but it's quite a problem in comp.*. Bela Lubkin * * // filbo@gorn.santa-cruz.ca.us CI$: 73047,1112 (slow) @ * * // belal@sco.com ..ucbvax!ucscc!{gorn!filbo,sco!belal} R Pentomino * \X/ Filbo @ Pyrzqxgl +408-476-4633 and XBBS +408-476-4945
brad@looking.on.ca (Brad Templeton) (01/06/90)
Why not experiment with post-moderation instead of pre-moderation. It's not as complete, but it is a lot faster, and might be right for some groups. By post moderation, I mean a system where a moderator exists who is entitled (and indeed requested) to send cancel messages on messages and threads that are clogging up the group. Flame-wars, name-callings, off topic threads, etc. The disadvantages are many: a) The moderator has to read very frequently, and on a well connected site. (One might arrange for lots of sites to feed to and from them moderator's site, just for that one group) b) No matter how fast the moderator is, some people are going to see the undesired stuff, and some will follow it up. c) The moderator can't take a vaction for any amount of time. d) Some twerps will disagree with the moderator's decisions, and complain and whine. Sure some decisions will be wrong, but the problem is that for every decision, there is somebody who thinks that it is the really wrong one, so you get constant complaint unless you stomp it. e) There are some problems with cancel, aren't there? f) Some twits will deliberately break the References line to follow up a dead thread so that their message makes it out. The advantages: a) The group runs at full speed for lively discussion -- on the right topics. b) The moderator can take a break and the worst that happens is that the group acts unmoderated -- better than having it go away. c) The moderator just makes a cancelling macro and reads through the group hitting 'd' (delete macro) from time to time. Easy task. Macro can even send mail to author. To kill threads I would advocate an automatic program that runs on the moderator's machine (and other major machines, if possible) which searches for articles that followup dead threads (or have the same re: subject) and cancels them as soon as they happen. Anyway, this would work, and it's even less 'authoritarian' than the current moderation scheme. (Not that the current scheme is bad -- it's just right for some groups.) -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
jef@well.UUCP (Jef Poskanzer) (01/06/90)
In the referenced message, brad@looking.on.ca (Brad Templeton) wrote:
} e) There are some problems with cancel, aren't there?
Yes: it doesn't work, prior to C news. I'd say that qualifies as a problem.
---
Jefkjones@talos.uu.net (Kyle Jones) (01/07/90)
> Why not experiment with post-moderation instead of pre-moderation. It's > not as complete, but it is a lot faster, and might be right for some > groups. A form of post-moderation is being experimented with in the alt hierarchy in the form of alt.sources.index. The problem at the moment is that there's no software support for *.index newsgroups, but the idea is still relatively new.