home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / news / groups / 22665 < prev    next >
Encoding:
Text File  |  1992-11-21  |  5.2 KB  |  120 lines

  1. Newsgroups: news.groups
  2. Path: sparky!uunet!newsgate.watson.ibm.com!yktnews!admin!watson!Watson.Ibm.Com!strom
  3. From: strom@Watson.Ibm.Com (Rob Strom)
  4. Subject: Re: RF(Informal)D: Standard RFD/CFV Format
  5. Sender: @watson.ibm.com
  6. Message-ID: <1992Nov21.202828.25201@watson.ibm.com>
  7. Date: Sat, 21 Nov 92 20:28:28 GMT
  8. References:  <1ei0pdINNg3n@talon.UCS.ORST.EDU>
  9. Organization: IBM Research
  10. Keywords: RFD CFV formats guidelines votes
  11. Lines: 107
  12.  
  13. In article <1ei0pdINNg3n@talon.UCS.ORST.EDU>, stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
  14.  
  15. |> >It is very unclear on the issue of what is required vs. what is
  16. |> >merely recommended.  Here are the guidelines with respect to Subject lines:
  17. |> >
  18. |> >               Use Descriptive Titles
  19. |> 
  20. |> This text is not in the guidelines for group creation. It may be in the
  21. |> 'netiquette' postings, but those are not guidelines for group creation.
  22. |>
  23.  
  24. The text is from "A Primer on How to Work with the Usenet Community",
  25. one of the articles in news.announce.newusers which all users are
  26. encouraged to read.  Here is an excerpt from the introduction to that
  27. document:
  28.  
  29.   *** You now have access to Usenet, a network of thousands of
  30.   computers.  Other documents or your system administrator will provide
  31.   detailed technical documentation.  This message describes the Usenet
  32.   culture and customs that have developed over time.  All new users should
  33.   read this message to find out how Usenet works. ***
  34.   *** (Old users could read it, too, to refresh their memories.)  ***
  35.  
  36. It defines the Usenet "culture and customs", which is the closest
  37. thing to "guidelines" we have.  You are correct that it is not
  38. from the guidelines for group creation.  It is instead part of more 
  39. general guidelines covering *all* postings to Usenet. 
  40. It is reasonable to assume that a guideline covering all postings 
  41. to Usenet also applies a fortiori to the CFV postings mandated by the
  42. guidelines for group creation.  
  43.  
  44.  
  45. |> >Now after reading the post-mortem of the rms vote, the net-consensus
  46. |> >seems to be that despite the above, the current process expects
  47. |> >that a CFV appearing in your newsgroup should be read regardless
  48. |> >of what the title says, as long as it says "CFV".  
  49. |> 
  50. |> It doesn't take too much effort to connect the ideas that "newsgroups
  51. |> are formed to carry traffic relevant to the newsgroup" and "a posting
  52. |> in a newsgroup is most likely relevant to the newsgroup."
  53. |> 
  54. The subject line guidelines explicitly say the opposite.  They
  55. say that many postings in a newsgroup are not relevant to every
  56. reader of that newsgroup.  They say that it is reasonable for
  57. readers of a newsgroup to not read postings unless their
  58. subject indicates that they are relevant for them.  They
  59. say that it is therefore incumbent upon authors of articles to
  60. use appropriate subject lines if they want to make sure that
  61. their articles are read.  
  62.  
  63. So as far as I can tell, the rules for subject lines are
  64. quite explicit.  The only dispute is whether, as applied
  65. to CFVs, the rules for subject lines are requirements
  66. or mere suggestions.  The consensus is that they
  67. are currently mere suggestions and I am proposing to
  68. the net that the newsgroup creation rules be amended
  69. to explicitly make them requirements.
  70.  
  71. |> >Furthermore
  72. |> >Mr. Stanley believes that this fact is well-documented.
  73. |> 
  74. |> Don't you dare decide for me what I believe or not. I have never said
  75. |> it is well documented, nor have I implied that. I have also never
  76. |> claimed that it needed to be well documented. There are things that
  77. |> don't need a whole lot of documentation for them to be important to
  78. |> know. Where is the documentation that says that cutting your hand off
  79. |> may cause you to bleed to death? Why should ladder companies have to
  80. |> tell people if they stand on the top step that they might fall off?
  81. |> 
  82.  
  83. Well, excuse me.  This was a discussion about what the
  84. written rules should say.  So when you said that "people
  85. should know X" I inferred that this was synonymous with
  86. "X is documented".   I had no idea that you had this
  87. strong view about how people ought to know things without
  88. being told.  And I have no interest in sidetracking this
  89. discussion to debate that with you.  I disagree:  this
  90. is a worldwide forum with people from different languages,
  91. different cultures, different levels of knowledge about
  92. computers.  People shouldn't have to know a lot to
  93. use the system, and what they do have to know should
  94. be written down.
  95.  
  96.  
  97. |> >and (2) even if it
  98. |> >were perfectly documented, it's not as good a process as the
  99. |> >modified one which I proposed.
  100. |> 
  101. |> I disagree.
  102.  
  103. I think we ought to get back to the topic of explaining why.
  104.  
  105. I think the controversy over this vote and the fact that
  106. several people posted that they were unaware of it is
  107. evidence that we should change the guidelines.  
  108.  
  109. I agree that we should not change them retroactively,
  110. but several people have posted that once we stop this
  111. crazy flaming about trying to undo the vote, we should
  112. get to work on amended guidelines.   My proposal for
  113. requiring a syntax-driven rule governing the allocation
  114. of votes to ballots and governing the appearance
  115. of subject lines of calls for votes remains on the table.
  116.  
  117. -- 
  118. Rob Strom, strom@watson.ibm.com, (914) 784-7641
  119. IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10598
  120.