From [email protected] Thu Feb 24 17:54:04 1994 Path: uunet!bounce-back From: [email protected] (Ian Jackson) Newsgroups: news.announce.newgroups,news.groups,comp.os.linux.announce,comp.os.linux.admin,comp.os.linux.development,comp.os.linux.help,comp.os.linux.misc Subject: RFD: comp.os.linux.* moderation by program Followup-To: news.groups Date: 24 Feb 1994 15:55:52 -0500 Organization: Linux Unlimited Lines: 98 Sender: [email protected] Approved: [email protected], [email protected] Message-ID:NNTP-Posting-Host: rodan.uu.net Keywords: moderation Xref: uunet news.announce.newgroups:4675 news.groups:96495 comp.os.linux.announce:1869 comp.os.linux.admin:4980 comp.os.linux.development:6478 comp.os.linux.help:23401 comp.os.linux.misc:10463 THE PROBLEM =========== There is a serious problem with volume in the comp.os.linux hierarchy; comp.os.linux help is running at around 200 articles per day. Many if not most of these articles FAQs and/or questions answered in the documentation; they often do not contain good Subject lines which enable one to select which articles to read from the thread display, and when you do read them they usually do not contain enough information to diagnose the problem. Many questions are inappropriately posted to col.misc and col.development. There is a daily posting in comp.os.linux.misc and comp.os.linux.help, however most posters appear only to read the group after they have made their first posting. Usually a poster will only make one such inappropriate posting, before coming across the daily posting, but by that time it is too late - the sheer number of new users is drowning us in a sea of (mostly) drivel. THE PROPOSAL ============ I therefore propose the moderation of comp.os.linux.misc, comp.os.linux.development, comp.os.linux.admin and comp.os.linux.help. However, in place of a conventional moderator there would be a program, which would decide whether a posting was approved. The exact details of the program's functionality are matters for discussion, but here are some ideas: * Most postings would be posted immediately - thus, the delay incurred would be negligible. * The first posting from any poster could be rejected and returned with a copy of some (short!) posting guidelines. Perhaps people could request the guidelines in advance to gain "pre-approval". * The daemon could enforce some kind of order in the Keywords line, by ensuring that poster tag their posting with one or more recognised keywords. This will make effective use of a killfile possible. * The daemon could have an auxiliary address which would act as a mail server for Linux documentation, or could point people at some other mail server. * If this proves to be insufficient (for example, in cases of severe abuse or massive flamewars) one could perhaps arrange some kind of scheme whereby postings on a particular topic (read: Subject line or References:) could be blocked at the request of the readership. * Crossposting between the comp.os.linux.* groups could be prevented. Naturally the administrators of the daemon would consult the readership before making major changes to its functioning, but it should not be fixed by charter. This will allow a certain amount of experimentation, and will especially allow poor ideas to be recognised quickly and abandoned. RELATIONSHIP TO ADVOCACY PROPOSAL ================================= The relationship between this and the current RFD for col.advocacy is not yet clear. Obviously moderating col.advocacy if created would be unnecessary and a poor idea; procedurally the two proposals appear to be orthogonal. However it may be the case that my proposal will remove any perceived need for an advocacy group, as it may well make it possible to redirect advocacy wars into a more appropriate group. This is a matter for discussion. PROCEDURE AND ADMINISTRATIVE MATTERS ==================================== I first proposed this in <[email protected]> on Thursday the 17th of February. There were no followups, but I received several messages in email which were very supportive. All discussion (both of this and of the .advocacy proposal) should take place in news.groups, not in comp.os.linux.misc. I expect that the discussion will decide whether to bring both proposals to a vote. If so the two votes could be held separately or in one CFV. -- Ian Jackson [email protected] ..!uknet!cam-orl!iwj These opinions are my own. Olivetti Research Ltd, Old Addenbrookes Site, Trumpington St, Cambridge, UK; Home: 35 Molewood Close, Cambridge, CB4 3SR; +44 223 327029. +44 223 343333 Email also via: [email protected] PGP2 public key available on request