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