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

Skip to content