home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v8 / text0022.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  6.5 KB  |  145 lines

  1. A few weeks ago I promised a statement on editorial policy.  This is it.
  2.  
  3. I see the purpose of being the moderator of mod.std.unix as being to keep
  4. the signal to noise ratio high, and I see five primary ways of doing this:
  5.  
  6. 1) eliminating duplicate information
  7. 2) discouraging other noise
  8. 3) correcting factual errors
  9. 4) spelling correction and other production work
  10. 5) encouraging diversity
  11.  
  12. Lately I've tried to accomplish these by
  13.  
  14. 1) rejections
  15. 2) rejections and editorial comments
  16. 3) editorial comments and occasional rejections
  17. 4) direct textual correction and extra articles (such as this one)
  18. 5) articles introducing new subjects
  19.  
  20.  
  21. More comments on some of these methods later in this article, but 
  22. first what happens to an article I receive for submission:
  23.  
  24. If it is rejected (about ten per cent are), I mail a reply either
  25. explaining why or suggesting a better place to submit it (or, often,
  26. both).  Sometimes this results in cycles of correspondence and even
  27. sometimes in other articles by the same submittor that are posted.
  28. This is desirable, but a rejection is almost always more work than
  29. an acceptance, often much more.
  30.  
  31. The most common reason for rejection is duplication of information:
  32. in that case I mail a reply pointing out something to the effect that
  33. "what you wrote has already been remarked on by x and y in articles
  34. that arrived after the one you're following up to:  do you still want
  35. yours posted?"
  36.  
  37.  
  38. If an article is approved, it is posted exactly as submitted with
  39. the following possible exceptions:
  40.  
  41.     Some header lines of the posted article, such as Subject:,
  42.     References, Keywords:, and Summary: are derived from header
  43.     lines of the submission, such as Subject:, References:,
  44.     In-Reply-To:, Keywords:, and Summary:.  Information from
  45.     other header lines of the submission, such as From:, Date:,
  46.     and Organization:, are preserved in the first few lines of
  47.     the text of the posted article (the submittor's real name,
  48.     if it can be found readily, is included in the From: line).
  49.  
  50.     Preliminary comments of the submittor that are addressed
  51.     directly to the moderator (such as "submit this if you
  52.     think it is appropriate") are removed.
  53.  
  54.     A Volume-Number: line is appended to the posted article.
  55.  
  56.     Readily apparent spelling errors (their vs. there, its
  57.     vs. it's, here vs. hear, etc.) are corrected.  Network
  58.     addresses (as found in signatures) that clearly will not
  59.     work (such as user@ibm.arpa) are fixed, when known.
  60.     Long or irrelevant signature lines are elided.
  61.  
  62.     Finally, comments by the moderator may be interspersed.
  63.     They are always clearly marked.  [ Like this.  -mod ]
  64.  
  65. Other than as noted here, nothing is added to and nothing is deleted
  66. from a submitted article when it is posted.
  67.  
  68. I've received a number of submissions that say something to the
  69. effect of "post what parts of this you think appropriate."
  70. Sorry, I don't do that.  I don't have time or inclination to edit for
  71. content (just interspersing comments now and then takes a noticeable
  72. amount of time), and the only way I could plausibly do it anyway would
  73. be to edit an article and send it back to the submittor for approval
  74. before posting.  The few times I've tried this have been dismal
  75. failures due to the slow delivery speeds and high failure rate of the
  76. UUCP mail network in addition to the amount of editing time involved.
  77.  
  78.  
  79. Now, a few more involved comments, working more or less backwards.
  80.  
  81. I've gotten several letters lately regarding interspersed comments
  82. by the moderator in recent articles (three for, two against).
  83. One, which interpreted the interspersed comments as the moderator
  84. taking sides, pointed out that that should be done in personally
  85. signed (i.e., not signed by the moderator) followup articles.
  86. In fact, that is my usual practice when I do take sides, as seen
  87. in previous volumes of mod.std.unix.
  88.  
  89. Recent interspersed comments by the moderator have been for three
  90. purposes:  to recapitulate information that the submittor doesn't seem
  91. to have noticed but which nonetheless has been brought up at length by
  92. other posters (this is to keep the other posters from having to say it
  93. all again);  to correct factual errors (so other posters don't have to
  94. do it); and to discourage ad hominem attacks and other irrelevant
  95. rhetorical techniques that lead only to more noise and less technical
  96. content.  Some have mistaken the last two of these for taking sides in
  97. argument.  Those who have done so should examine the recent volume and
  98. notice the lack of correlation between the side of the case sensitive
  99. file name argument and article is on and the number of interspersed
  100. comments by the moderator.
  101.  
  102.  
  103. There has been a spate of submissions recently involving ad hominem
  104. attacks (name calling, if you will) on opponents named or unnamed.
  105. Those using personal names have been rejected.  Those not doing so have
  106. been posted with comments by the moderator discouraging the practice.
  107. Experience indicates to me that the former approach works better.  From
  108. now on I will reject any article containing personal attacks on anyone
  109. (or any group) named or unnamed, regardless of the content or lack
  110. thereof of the rest of the article.  (If this happens to you, you can
  111. always edit it yourself and resubmit it.)
  112.  
  113. It is evidently necessary to point out that there is a difference
  114. between attacking an argument and attacking the person who made it.
  115. It is ok to say an argument is "utterly loony."  It is not ok to
  116. say someone who made an argument is "utterly loony" (or a cretin,
  117. an idiot, lazy, etc.).
  118.  
  119. Why not?  Because such verbiage is irrelevant to a technical discussion
  120. and will only cause the someone to at least be offended and probably
  121. to followup with equally irrelevant verbiage, thus reducing the
  122. technical content of the newsgroup not once but twice or many times.
  123. It is probably unnecessary to point out that derogatory and untechnical
  124. verbiage even applying to arguments should be used sparingly, if at all.
  125.  
  126. Why do I care?  Because I still suffer through reading net.unix
  127. and net.unix-wizards and I don't want this newsgroup to descend
  128. to that level.
  129.  
  130.  
  131. By the way, remember that I don't get paid for moderating.  It takes
  132. less time than some have thought (due to use of a really baroque
  133. shell script), but that time is still taken from other things I'm
  134. trying to do (like earn a living).
  135.  
  136. Finally, remember that the networks are flaky (and I've even been
  137. known to manage to lose articles):  if you submit something and don't
  138. see it in the newsgroup or get a reply in a week or two, it's probably
  139. worth resubmitting it.
  140.  
  141. Moderator, John S. Quarterman
  142.  
  143. Volume-Number: Volume 8, Number 23
  144.  
  145.