Xref: utzoo comp.sys.ibm.pc:13489 news.groups:2953 comp.binaries.ibm.pc:653 Path: utzoo!mnetor!uunet!husc6!rutgers!ho95e!wcs From: wcs@ho95e.ATT.COM (Bill.Stewart.) Newsgroups: comp.sys.ibm.pc,news.groups,comp.binaries.ibm.pc Subject: Re: Moderation... on comp.binaries.ibm.pc Message-ID: <2070@ho95e.ATT.COM> Date: 21 Mar 88 20:38:40 GMT References: <1424@polyslo.UUCP> <149@tscs.UUCP> <2310@bsu-cs.UUCP> <2054@ho95e.ATT.COM> <4484@xanth.cs.odu.edu> Reply-To: wcs@ho95e.UUCP (46323-Bill.Stewart.,2G218,x0705,) Organization: AT&T Bell Labs 46133, Holmdel, NJ Lines: 46 Keywords: Moderation is Evil! It's also unnecessary. There's been a lot of discussion of moderation, archive formats, etc., mostly in favor of it. I contend that comp.binaries.ibm.pc runs well enough without moderation, and that moderation will reduce the amount of useful software posted here, though it will also reduce the amount of junk. What is this newsgroup actually used for? The major purpose for its creation had been to separate general discussion from software postings. This lets people who want software get it without wading through the immense volume of comp.sys.ibm.pc, and people who want general discussion avoid having to skip over uuencoded arc files. As long as the volume is moderate, it's reasonable for comp.binaries.ibm.pc (or some group like it) to carry - binaries and sources - bug reports and fixes, and other discussion *specifically related* to posted software. - brief requests for software - small amounts of meta-discussion, like "how do I read an arc file". - discussions related to running the group, like which arc to use and whether to moderate it. In an unmoderated group, all these things will be together, which makes archiving much easier! Sure there will be more articles, but what you really care about for archiving is megabytes, and the discussion doesn't add much. In article <4484@xanth.cs.odu.edu> jim@xanth.UUCP (Jim Duncan) writes: >I believe a moderator is a good idea. I only wish I had the time to do it. >My heart and hopes go out to the poor soul who takes on this job. That's the point. Even a *great* moderator, like r$, has to work periodically; the backlog of unreleased comp.sources.unix postings is pretty long, and he doesn't include most of the "bugs" discussions, which goes on in other newsgroups. >- A moderator can insulate us to some extent from silly crap, like obvious > Trojan horses, viruses, or screwed-up postings that won't uudecode or > de-arc properly. That's what contributes to much of the delay. Brandon Allberry's comp.sources.misc moderation lets a lot more through, and he's done a good job of keeping turnaround up, but it takes time and effort to do a decent job - how do you do real testing on binaries? Sure, you can reject those without useful ASCII documentation (sorry, but I really dislike postings that leave all description of what they are *inside* the arc.) But without sources you can't do much more than cursory sanity check. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs # So we got out our parsers and debuggers and lexical analyzers and various # implements of destruction and went off to clean up the tty driver...