home *** CD-ROM | disk | FTP | other *** search
- 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
-
-