[mod.std.unix] editorial policy for mod.std.unix

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/03/86)

A few weeks ago I promised a statement on editorial policy.  This is it.

I see the purpose of being the moderator of mod.std.unix as being to keep
the signal to noise ratio high, and I see five primary ways of doing this:

1) eliminating duplicate information
2) discouraging other noise
3) correcting factual errors
4) spelling correction and other production work
5) encouraging diversity

Lately I've tried to accomplish these by

1) rejections
2) rejections and editorial comments
3) editorial comments and occasional rejections
4) direct textual correction and extra articles (such as this one)
5) articles introducing new subjects


More comments on some of these methods later in this article, but 
first what happens to an article I receive for submission:

If it is rejected (about ten per cent are), I mail a reply either
explaining why or suggesting a better place to submit it (or, often,
both).  Sometimes this results in cycles of correspondence and even
sometimes in other articles by the same submittor that are posted.
This is desirable, but a rejection is almost always more work than
an acceptance, often much more.

The most common reason for rejection is duplication of information:
in that case I mail a reply pointing out something to the effect that
"what you wrote has already been remarked on by x and y in articles
that arrived after the one you're following up to:  do you still want
yours posted?"


If an article is approved, it is posted exactly as submitted with
the following possible exceptions:

	Some header lines of the posted article, such as Subject:,
	References, Keywords:, and Summary: are derived from header
	lines of the submission, such as Subject:, References:,
	In-Reply-To:, Keywords:, and Summary:.  Information from
	other header lines of the submission, such as From:, Date:,
	and Organization:, are preserved in the first few lines of
	the text of the posted article (the submittor's real name,
	if it can be found readily, is included in the From: line).

	Preliminary comments of the submittor that are addressed
	directly to the moderator (such as "submit this if you
	think it is appropriate") are removed.

	A Volume-Number: line is appended to the posted article.

	Readily apparent spelling errors (their vs. there, its
	vs. it's, here vs. hear, etc.) are corrected.  Network
	addresses (as found in signatures) that clearly will not
	work (such as user@ibm.arpa) are fixed, when known.
	Long or irrelevant signature lines are elided.

	Finally, comments by the moderator may be interspersed.
	They are always clearly marked.  [ Like this.  -mod ]

Other than as noted here, nothing is added to and nothing is deleted
from a submitted article when it is posted.

I've received a number of submissions that say something to the
effect of "post what parts of this you think appropriate."
Sorry, I don't do that.  I don't have time or inclination to edit for
content (just interspersing comments now and then takes a noticeable
amount of time), and the only way I could plausibly do it anyway would
be to edit an article and send it back to the submittor for approval
before posting.  The few times I've tried this have been dismal
failures due to the slow delivery speeds and high failure rate of the
UUCP mail network in addition to the amount of editing time involved.


Now, a few more involved comments, working more or less backwards.

I've gotten several letters lately regarding interspersed comments
by the moderator in recent articles (three for, two against).
One, which interpreted the interspersed comments as the moderator
taking sides, pointed out that that should be done in personally
signed (i.e., not signed by the moderator) followup articles.
In fact, that is my usual practice when I do take sides, as seen
in previous volumes of mod.std.unix.

Recent interspersed comments by the moderator have been for three
purposes:  to recapitulate information that the submittor doesn't seem
to have noticed but which nonetheless has been brought up at length by
other posters (this is to keep the other posters from having to say it
all again);  to correct factual errors (so other posters don't have to
do it); and to discourage ad hominem attacks and other irrelevant
rhetorical techniques that lead only to more noise and less technical
content.  Some have mistaken the last two of these for taking sides in
argument.  Those who have done so should examine the recent volume and
notice the lack of correlation between the side of the case sensitive
file name argument and article is on and the number of interspersed
comments by the moderator.


There has been a spate of submissions recently involving ad hominem
attacks (name calling, if you will) on opponents named or unnamed.
Those using personal names have been rejected.  Those not doing so have
been posted with comments by the moderator discouraging the practice.
Experience indicates to me that the former approach works better.  From
now on I will reject any article containing personal attacks on anyone
(or any group) named or unnamed, regardless of the content or lack
thereof of the rest of the article.  (If this happens to you, you can
always edit it yourself and resubmit it.)

It is evidently necessary to point out that there is a difference
between attacking an argument and attacking the person who made it.
It is ok to say an argument is "utterly loony."  It is not ok to
say someone who made an argument is "utterly loony" (or a cretin,
an idiot, lazy, etc.).

Why not?  Because such verbiage is irrelevant to a technical discussion
and will only cause the someone to at least be offended and probably
to followup with equally irrelevant verbiage, thus reducing the
technical content of the newsgroup not once but twice or many times.
It is probably unnecessary to point out that derogatory and untechnical
verbiage even applying to arguments should be used sparingly, if at all.

Why do I care?  Because I still suffer through reading net.unix
and net.unix-wizards and I don't want this newsgroup to descend
to that level.


By the way, remember that I don't get paid for moderating.  It takes
less time than some have thought (due to use of a really baroque
shell script), but that time is still taken from other things I'm
trying to do (like earn a living).

Finally, remember that the networks are flaky (and I've even been
known to manage to lose articles):  if you submit something and don't
see it in the newsgroup or get a reply in a week or two, it's probably
worth resubmitting it.

Moderator, John S. Quarterman

Volume-Number: Volume 8, Number 23