home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / news / admin / policy / 891 < prev    next >
Encoding:
Internet Message Format  |  1992-12-26  |  11.6 KB

  1. Path: sparky!uunet!spool.mu.edu!umn.edu!gaia.ucs.orst.edu!ruby!stanley
  2. From: stanley@ruby.OCE.ORST.EDU (John Stanley)
  3. Newsgroups: news.admin.policy
  4. Subject: Re: Newsgroup creation guidelines
  5. Date: 26 Dec 1992 16:26:18 GMT
  6. Organization: Oregon State University, College of Oceanography
  7. Lines: 265
  8. Message-ID: <1hi13aINNitm@gaia.ucs.orst.edu>
  9. NNTP-Posting-Host: ruby.oce.orst.edu
  10.  
  11. In article <1992Dec22.174745.56455@watson.ibm.com> strom@Watson.Ibm.Com (Rob Strom) writes:
  12. >In article <1h629qINNp3r@gaia.ucs.orst.edu>, stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
  13. >|> In article <1992Dec21.225351.18200@watson.ibm.com> strom@Watson.Ibm.Com (Rob Strom) writes:
  14.  
  15. Would you PLEASE set your quote character to be ONE character? It is
  16. extremely confusing to see what looks like two levels of quotes where
  17. there should be one.
  18.  
  19. >|> That you still treat them as irrelevant only proves that you can't
  20. >|> provide enough information to some people to educate them as to what the
  21. >|> policies are. Your claims are contradictory -- you say that you accept
  22.  
  23. >I haven't tried to educate others yet as to what the policies are.
  24.  
  25. I am not referring to others -- I am referring to you.
  26.  
  27. >So I'm going to use all kinds of shortcuts to reduce the
  28. >amount of material I read.
  29.  
  30. That is your choice. 
  31.  
  32. >For example, at this very moment I don't read news.admin.policy
  33. >*except for this one thread*.  If you responded to me and
  34. >changed the Subject line even by one character, the chances are 
  35. >excellent that I just wouldn't see your response at all.
  36.  
  37. I made a considerable change to the Subject line and you still saw the
  38. reply I made. So much for your estimation of excellent chances.
  39.  
  40. >rename comp.lang.misc.  I didn't say I *believe* these RFD's
  41. >are irrelevant.  Read my posting again.  I said I *treat*
  42. >them as irrelevant.  
  43.  
  44. That is, again, your choice. That you choose to treat them as irrelevant
  45. despite claiming to understand that material that says that they are not
  46. is your problem, not the net's, and wanting the net to change because
  47. you don't want to spend the time at home to read news is not going to
  48. get much sympathy.
  49.  
  50. >I spend too much time as it is reading
  51. >and posting news, and one of the ways I cut down is to
  52. >only read items whose subject lines are appropriately
  53. >compelling.  
  54.  
  55. Fascinating. You claim to understand and accept the current policy, yet
  56. you continue to act as if the term CFC is not compelling enough. That
  57. sounds suspiciously like an apathetic attitude towards the new group
  58. creation process.
  59.  
  60. Now explain why, in light of your actions, you would expect people to
  61. be more apt to read RFD and CFV with "more compelling" Subjects. You
  62. don't bother to read them, and you KNOW what they are.
  63.  
  64. >We still haven't communicated.  I am not suggesting to change
  65. >policies because people don't bother to find out about them.
  66.  
  67. That is exactly waht you are proposing. Were people "aware" of the
  68. policy, the Subject RFD and CFV would be compelling to those who are
  69. interested. The point that you are missing is that all it takes to
  70. become aware of the policy is to read ONE of the RFD and one CFV. 
  71.  
  72. >I'm trying to deal with the fact that IMHO it's a bad policy, because
  73. >it forces people to read RFD's and CFV's that they otherwise
  74. >wouldn't have to read if the subject lines were more precise.
  75.  
  76. Nobody is forced to read anything. Arguing from the premise that they
  77. are is a waste of time.
  78.  
  79. >This isn't worth debating.  All I meant was that both your Users Guide
  80. >and the guidelines have statements of the form "You should do <X>;
  81. >If you don't do <X>, then <this thing you don't like> will happen".
  82.  
  83. I used many of the same words that are found in the Bible. Does that
  84. make the User's Guide a religious work?
  85.  
  86. >|> Second, there is more than one piece of information you want included.
  87. >|> Renaming a.b.c to a.d.e affects both the a.b hierarchy and the a.d
  88. >|> hierarchy, as well as the a.b.c newsgroup. I count three things that
  89. >|> need to be in the Subject.
  90. >
  91. >In my proposal, I am concerned only about the effect on the
  92. >a.b.c newsgroup, not the other two effects.
  93.  
  94. Why this lack of concern for affected newsgroups? Why aren't the a.d.*
  95. readers worthy of the same clear, concise Subject line that will notify
  96. them of proposed changes? If you define "affected" the way you want, you
  97. MUST include a.d.*. Waffling about it by saying "I don't want to notify
  98. them" is a direct violation of your own proposed rule. If you don't
  99. think your own rule should be followed, don't propose it.
  100.  
  101. >I am assuming that a reader of the a.b.c newsgroup will have
  102. >to physically change his/her subscription list to avoid being cut off
  103. >from accustomed news.  I consider that a major effect.
  104.  
  105. Really major. "New newsgroup a.d.e, subscribe? [ynYN]".
  106.  
  107. Typing ONE character is hardly a major effect.
  108.  
  109. >interested in.  I'm treating these non-physical effects
  110. >as less important than the physical one.
  111.  
  112. Your own rule talks about changing charters. Either you mean it, or you
  113. don't. Which is it? Either those who will have their "charter" changed
  114. get clear notification, or your rule degenerates into shouting matches
  115. about who should have been mentioned in the Subject line.
  116.  
  117. It is clear from your own example that teis "syntactic rule" is
  118. useless, for you yourself don't believe it should be applied.
  119.  
  120. >Are you telling me that if I post an RFD to news.announce.new(s)groups
  121. >and crosspost it to other groups, it doesn't appear in
  122. >the other groups until the moderator of n.a.n passes it?
  123.  
  124. That is how it is supposed to work. Your news software can't post it,
  125. because it isn't approved for the moderated group, so it mails it to the
  126. moderator. 
  127.  
  128. >|> >The more frequently readers find irrelevant RFDs, the
  129.  
  130. >|> I thought you accepted that the presence of an RFD in a newsgroup meant
  131. >|> it was relevant. This is the cuurent policy that you want to change,
  132. >|> remember?
  133.  
  134. >Sorry for speaking over-elliptically.  I meant
  135. >irrelevant-to-the-reader, as opposed to officially-deemed-relevant.
  136.  
  137. It is impossible to determine prior to the reader seeing it whether an
  138. RFD will be deemed relevant. This determination will vary from reader to
  139. reader. The only useful meaning to relevant in this sense is "relevant to
  140. the newsgroup as a whole".
  141.  
  142. You should also be aware that your proposal will do nothing to decrease
  143. the "irrelevant to the reader" RFD that are posted -- in fact, it will
  144. INCREASE the likelyhood, since it will take more RFD to do the same
  145. thing as is being done now.
  146.  
  147. >  I meant that readers are more likely to know whether
  148. >an RFD for a name change is relevant-to-the-reader if the newsgroup name 
  149. >or hierarchy name in the subject line specifies which group(s) are 
  150. >affected-in-my-specialized-sense by the name change.
  151.  
  152. Which specialized meaning are you using now? The one you defined in your
  153. proposed change which talks about "charter changes", or your "physical
  154. change" (the one character one) that you just brought up?
  155.  
  156. >|> >Sometimes charters are changed.  For example, if rec.scouting
  157.  
  158. >|> Present an example of a charter ever being changed by a vote. Provide
  159. >|> both the pre-vote and post-vote charter. Save your time, there hasn't
  160. >|> been one.
  161.  
  162. >I had assumed 
  163.  
  164. Present an example of a changed charter. Don't keep assuming things,
  165. because you have a horrible track record at assuming things.
  166.  
  167. >|> >|> No, both are in rec. Rec.truckers, as a group, is in the same hierarchy
  168. >|> >|> as the group rec.ham-radio.
  169.  
  170. >|> >You're right.  But then it couldn't be called any longer
  171. >|> >"rec.ham-radio* reorg".  It would have to be called "rec.* reorg".
  172.  
  173. >|> Which ficticious quidelines are you now using to claim that reorganizing
  174. >|> rec.ham-radio should have been called rec.* reorg? There ain't no such
  175. >|> rule. It could have quite properly been called rec.ham-radio reorg. As
  176. >|> it was, I believe it was called "rec.radio.* reorg...", and that nobody
  177. >|> whined about the fact that the Subject  didn't have rec.ham-radio in
  178. >|> it.
  179.  
  180. >The context was my proposed guidelines.  
  181.  
  182. If your proposed guidelines say that reorganizing rec.ham-radio into
  183. rec.radio.amateur.* must be listed in the Subject as "rec.* reorg", then
  184. there is something seriously wrong with your proposal. I just want you
  185. to notice that YOU are the one who made the interpretation of your
  186. proposed rules, not me, and YOu are the one who said it would need to be
  187. called the rec.* reorg.
  188.  
  189. >|> Like I said, "all at once". 
  190. >|> 
  191. >They can be done all at once with two ballots.
  192.  
  193. Which new definition of the phrase "at once" are you using?
  194.  
  195. >|> > I
  196. >|> >think this is a good thing, because people will argue
  197. >|> >ad infinitum on whether a particular reorganization is
  198. >|> >"logical".  But in my proposal, whether a vote is well-labelled
  199. >|> >or not is a purely syntactic question which both 'yes' voters
  200. >|> >and 'no' voters can agree on.  
  201.  
  202. >|> And they will still argue ad-infinitum about whether the reorganization
  203. >|> is a logical one. Your proposal will do absolutely nothing about that.
  204. >|> The only thing your proposal would reduce is the number of people who
  205. >|> whine about missing a vote because they  chose not to read the CFV, and
  206. >|> even then it won't fix that problem because people will STILL choose not
  207. >|> to read things.
  208.  
  209. >It's one thing to say that there's no excuse for not reading
  210. >the new-user information.  
  211.  
  212. Please stick to the topic. You implied very strongly that there would be
  213. fewer  arguments over reorganizations (whether they are logical or not)
  214. because of your rule. Your rule will have no such effect. Reading new
  215. user doumentation or not has absolutely nothing to do with it.
  216.  
  217. >I agree that everyone should read the new-user information.
  218. >But I disagree that everyone should read every RFD or CFV,
  219. >as the guidelines currently require them to.
  220.  
  221. Which set of guidelines is this? It isn't The Guidelines, they don't
  222. require any such thing. The User's Guide? No, it doesn't require that.
  223.  
  224. Just which "guidelines" are you talking about now?
  225.  
  226. >|> Subject: RFD rec.ham-radio reorganization and rec.radio.* reorganization.
  227. >|> 
  228. >|> That is more than the 40 characters that the "guidelines" specify.
  229. >|> 
  230. >Yes, the example is obsolete.  It doesn't matter.  You can treat
  231. >these names as meaningless charstrings if you like.
  232. >
  233. >No, my proposed-guidelines do not require rec.radio.* to be mentioned,
  234. >because no newsgroup in rec.radio.* has its name or charter changed
  235. >by the reorganization.
  236.  
  237. Please pick a position and stick with it. If creating
  238. rec.scouting.policy changes the charter of rec.scouting, then creating
  239. rec.radio.amateur.* changes the charters of every other rec.radio
  240. group, for exactly the same reason.
  241.  
  242. >|> Uhhh, what was that comment about "syntactic specification that both yes
  243. >|> and no voter could agree on"? Your own example doesn't agree with your
  244. >|> rule.
  245.  
  246. >See above.
  247.  
  248. See above, yourself. I think the fact that your example doesn't agree
  249. with the rule is pretty reliable evidence that the "syntactic
  250. specification" is a failure. Even ignoring that we are not polarized by
  251. being on the opposing sides of a newgroup argument and we can't
  252. determine whether a hierarchy should be in the Subject or not based on
  253. your rule.
  254.  
  255.  
  256. >The users guide currently tells readers that if they see an RFD posted
  257. >in a newsgroup they read, they should read that RFD regardless of
  258. >what the subject line says. 
  259.  
  260. That is a valid statement of fact.
  261.  
  262. >If my changed policy were to go into
  263. >effect, the users guide would 
  264.  
  265. Until you start writing these things, don't tell me what it would say.
  266.  
  267. >explain to readers that groups named
  268. >in the RFD might get new names and that certain topics formerly
  269. >permitted to be posted to some of these groups will be removed or
  270. >moved elsewhere.
  271.  
  272. That is a current statement of fact, as well. Your proposal cdoes not
  273. change that. However, reading the RFD will adequately cover that topic.
  274.  
  275.  
  276.