home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / news / admin / policy / 834 < prev    next >
Encoding:
Text File  |  1992-12-22  |  14.7 KB  |  340 lines

  1. Newsgroups: news.admin.policy
  2. Path: sparky!uunet!scifi!watson!Watson.Ibm.Com!strom
  3. From: strom@Watson.Ibm.Com (Rob Strom)
  4. Subject: Re: Newsgroup creation guidelines
  5. Sender: @watson.ibm.com
  6. Message-ID: <1992Dec22.174745.56455@watson.ibm.com>
  7. Date: Tue, 22 Dec 92 17:47:45 GMT
  8. References:  <1h629qINNp3r@gaia.ucs.orst.edu>
  9. Organization: IBM Research
  10. Lines: 328
  11.  
  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. |> >In article <1glu0dINNmc5@gaia.ucs.orst.edu>, stanley@ruby.OCE.ORST.EDU (John Stanley) writes:
  15. |>  
  16. |> >|> The fact that an RFD/CFV was posted to a group implies relevance, no
  17. |> >|> matter what the rest of the Subject line contains. The three characters
  18. |> >|> RFD or CFV indicate the relevance.
  19. |> 
  20. |> >I agree that this is what is the policy today.  That's whu I
  21. |> >want to change it.  I think many people (including myself)
  22. |> >treat RFD for what looks like a group they don't read
  23. |> >as irrelevant despite what you say above.  
  24. |> 
  25. |> That you still treat them as irrelevant only proves that you can't
  26. |> provide enough information to some people to educate them as to what the
  27. |> policies are. Your claims are contradictory -- you say that you accept
  28. |> that the User's Guide reflects cuurent policy (which implies that you
  29. |> have read and understood it), but you also claim to continue to believe
  30. |> that RFD posted to groups you read are irrelevant. 
  31. |> 
  32.  
  33. I haven't tried to educate others yet as to what the policies are.
  34.  
  35. I was simply trying to point out that when I come to work, I
  36. can only spend a little time reading and responding to posts.
  37. If I spent any more, my productivity would be affected and
  38. my managers and co-workers would complain.
  39.  
  40. So I'm going to use all kinds of shortcuts to reduce the
  41. amount of material I read.
  42.  
  43. For example, at this very moment I don't read news.admin.policy
  44. *except for this one thread*.  If you responded to me and
  45. changed the Subject line even by one character, the chances are 
  46. excellent that I just wouldn't see your response at all.
  47.  
  48. I don't read news.announce.newgroups at all.  And if
  49. I saw a header in comp.lang.misc which said "RFD: comp.unix* reorg*"
  50. there is still a good chance I would not scan the article in
  51. detail to see if the "comp.unix* reorg" possibly might
  52. rename comp.lang.misc.  I didn't say I *believe* these RFD's
  53. are irrelevant.  Read my posting again.  I said I *treat*
  54. them as irrelevant.  I spend too much time as it is reading
  55. and posting news, and one of the ways I cut down is to
  56. only read items whose subject lines are appropriately
  57. compelling.  That only-proprieties-and-not-a-guideline
  58. document in news.announce.newusers accurately describes
  59. my attitude towards selectivity in reading news, and
  60. the use of subject lines to help me become efficiently selective.
  61.  
  62. |> >So either
  63. |> >we can change people's habits to reflect current policies
  64. |> >or change current policies to reflect the habits, and
  65. |> >I'm proposing to do the latter.
  66. |> 
  67. |> Changing policies because people don't bother to find out about them
  68. |> will lead to a never ending cycle of changes, for there will always be
  69. |> people who don't bother to find out how things work  no matter how
  70. |> things work.
  71.  
  72. We still haven't communicated.  I am not suggesting to change
  73. policies because people don't bother to find out about them.
  74. I obviously have found out, both by experience, and by
  75. reading your Users Guide, that the policy is that anything
  76. with the word RFD in the subject line might be a proposal
  77. to rename the group you're reading even though the subject line mentions
  78. a totally different group.  *I know this*!!!!  I'm not trying
  79. to deal with the fact that some folks don't know this.
  80. I'm trying to deal with the fact that IMHO it's a bad policy, because
  81. it forces people to read RFD's and CFV's that they otherwise
  82. wouldn't have to read if the subject lines were more precise.
  83.  
  84. |> 
  85. |> >|> I have written no guidelines. I wrote a descriptive document, not a
  86. |> >|> proscriptive one.
  87. |> 
  88. |> >I'm not convinced there's such a clear line.  If you say
  89. |> >"Ignore RFDs at your peril no matter what the rest of the
  90. |> >Subject line says", that has a prescriptive
  91. |> >flavor to it.
  92. |> 
  93. |> Then you do not understand the difference. As Chip has pointed out,
  94. |> telling pople what is polite or good is not the same as telling them
  95. |> what they must do.
  96. |> 
  97.  
  98. This isn't worth debating.  All I meant was that both your Users Guide
  99. and the guidelines have statements of the form "You should do <X>;
  100. If you don't do <X>, then <this thing you don't like> will happen".
  101.  
  102. |> >I didn't try to stuff every piece of information into the Subject line.
  103. |> 
  104. |> If the current process is bad because this one particular piece of
  105. |> information is missing, then it is bad because other pieces are missing.
  106. |> On the other hand, you can accept that Subjects are not meant to convey
  107. |> every piece of information. 
  108. |> 
  109. |> >I simply proposed that one particular piece of information be
  110. |> >inserted into the Subject line:  the name of the group or hierarchy
  111. |> >whose names and/or charters may be changed by the vote.
  112. |> 
  113. |> First, I will tell you again, charters are not changed.
  114. |> 
  115.  
  116. If rec.scouting is split into rec.scouting and rec.scouting.policy,
  117. then discussions of scouting policy, currently permitted in rec.scouting,
  118. will no longer be welcome in rec.scouting.  Posters who post
  119. policy discussions in rec.scouting will be told to move them. (To simplify the
  120. discussion, I'm assuming that the creation of rec.scouting.policy
  121. succeeds and the rename of rec.scouting to rec.scouting.misc fails.
  122. By the time you read this, the vote will be over, and my example
  123. will be obsolete.)
  124.  
  125. |> Second, there is more than one piece of information you want included.
  126. |> Renaming a.b.c to a.d.e affects both the a.b hierarchy and the a.d
  127. |> hierarchy, as well as the a.b.c newsgroup. I count three things that
  128. |> need to be in the Subject.
  129.  
  130. In my proposal, I am concerned only about the effect on the
  131. a.b.c newsgroup, not the other two effects.
  132.  
  133. I am assuming that a reader of the a.b.c newsgroup will have
  134. to physically change his/her subscription list to avoid being cut off
  135. from accustomed news.  I consider that a major effect.
  136.  
  137. The other effects are more subtle: readers of other groups
  138. in the a.b hierarchy, such as a.b.d, suddenly discover they've
  139. lost a sister newsgroup; readers of other groups in the a.d
  140. hierarchy suddenly discover they've gained a sister newsgroup.
  141. There may be psychological consequences to this, but they're
  142. not as immediate as the other effect.  There are also effects
  143. on future readers who are not currently voting when they
  144. try to find the name of a group which matches a topic they're
  145. interested in.  I'm treating these non-physical effects
  146. as less important than the physical one.
  147.  
  148.  
  149. |> 
  150. |> >As far as I know, anyone may post an RFD, and there are
  151. |> 
  152. |> Of course, anyone may POST one. There is only ONE moderator of
  153. |> news.announce.newsgroups, however, and thus each and every RFD is
  154. |> required to pass through him. He has yet to pass on frivolous RFD (with
  155. |> one exception), so claiming since anyone can post one that newsgorups
  156. |> are flooded with irrelevant RFD is foolish. There is a gate to prevent
  157. |> such occurances.
  158. |> 
  159. Are you telling me that if I post an RFD to news.announce.new(s)groups
  160. and crosspost it to other groups, it doesn't appear in
  161. the other groups until the moderator of n.a.n passes it?
  162.  
  163. This I'm going to try, using ny.test.
  164.  
  165. |> >The more frequently readers find irrelevant RFDs, the
  166. |> 
  167. |> I thought you accepted that the presence of an RFD in a newsgroup meant
  168. |> it was relevant. This is the cuurent policy that you want to change,
  169. |> remember?
  170. |> 
  171. Sorry for speaking over-elliptically.  I meant
  172. irrelevant-to-the-reader, as opposed to officially-deemed-relevant.
  173.  
  174. |> >more likely they are to ignore future ones.  My syntactic
  175. |> >criterion is a way to increase the likelihood that
  176. |> >Subject lines match content.
  177. |> 
  178. |> As long as an RFD contains an RFD and a CFV contains a CFV, then subject
  179. |> matches content, problem solved.
  180. |> 
  181.  
  182. Same thing.  I meant that readers are more likely to know whether
  183. an RFD for a name change is relevant-to-the-reader if the newsgroup name 
  184. or hierarchy name in the subject line specifies which group(s) are 
  185. affected-in-my-specialized-sense by the name change.
  186.  
  187. |> >Sometimes charters are changed.  For example, if rec.scouting
  188. |> 
  189. |> Present an example of a charter ever being changed by a vote. Provide
  190. |> both the pre-vote and post-vote charter. Save your time, there hasn't
  191. |> been one.
  192.  
  193. I had assumed that the charter of rec.scouting.misc would
  194. exclude policy discussions if rec.scouting.policy is also
  195. created.  That is certainly what the proposers of the split
  196. intend to happen.
  197.  
  198. |> 
  199. |> >|> No, both are in rec. Rec.truckers, as a group, is in the same hierarchy
  200. |> >|> as the group rec.ham-radio.
  201. |> >
  202. |> >You're right.  But then it couldn't be called any longer
  203. |> >"rec.ham-radio* reorg".  It would have to be called "rec.* reorg".
  204. |> 
  205. |> Which ficticious quidelines are you now using to claim that reorganizing
  206. |> rec.ham-radio should have been called rec.* reorg? There ain't no such
  207. |> rule. It could have quite properly been called rec.ham-radio reorg. As
  208. |> it was, I believe it was called "rec.radio.* reorg...", and that nobody
  209. |> whined about the fact that the Subject  didn't have rec.ham-radio in
  210. |> it.
  211.  
  212. The context was my proposed guidelines.  If they went into effect,
  213. if you rename rec.truckers and rec.ham-radio, then either the
  214. changes go on separate ballots, or the ballot would have to
  215. be called a rec.* reorg.  I viewed the second alternative as
  216. absurd, so my first posting listed the first as the only possibility.
  217.  
  218. |> 
  219. |> I didn't notice whether you caught the comment: rec.ham-radio is an
  220. |> obsolete group. Don't use that as an example group in your proposal for
  221. |> the guidelines.
  222. |> 
  223.  
  224. I'll change the example.  The reason I used this example is that
  225. earlier when this was being discussed on news.groups, the original
  226. proponent of the rec.ham-radio reorg asked how I would have handled
  227. that change had my proposed-guidelines been the guidelines at the
  228. time of that reorg.  I used this as a motivating example since
  229. it actually came up.
  230.  
  231. |> >|> The only problem with this is that it will not permit logical
  232. |> >|> reorganizations to occur all at once, for anything that attempts to pull
  233. |> >|> groups from more than one hierarchy on the net and put them into a new
  234. |> >|> one that covers them all can't be done.
  235. |> 
  236. |> >They can be done, but they can't be done in one ballot. 
  237. |> 
  238. |> Like I said, "all at once". 
  239. |> 
  240. They can be done all at once with two ballots.
  241.  
  242. |> > I
  243. |> >think this is a good thing, because people will argue
  244. |> >ad infinitum on whether a particular reorganization is
  245. |> >"logical".  But in my proposal, whether a vote is well-labelled
  246. |> >or not is a purely syntactic question which both 'yes' voters
  247. |> >and 'no' voters can agree on.  
  248. |> 
  249. |> And they will still argue ad-infinitum about whether the reorganization
  250. |> is a logical one. Your proposal will do absolutely nothing about that.
  251. |> The only thing your proposal would reduce is the number of people who
  252. |> whine about missing a vote because they  chose not to read the CFV, and
  253. |> even then it won't fix that problem because people will STILL choose not
  254. |> to read things.
  255. |> 
  256.  
  257. It's one thing to say that there's no excuse for not reading
  258. the new-user information.  It's another thing to say that
  259. there's no excuse for not reading a CFV with a misleading label.
  260. I agree that everyone should read the new-user information.
  261. But I disagree that everyone should read every RFD or CFV,
  262. as the guidelines currently require them to.
  263. My whole premise here is to allow people to skip more
  264. postings while still seeing the ones they need to see.
  265.  
  266. |> >|> >(2)
  267. |> >|> >The RFDs and CFVs for name changes and reorganizations should
  268. |> >|> >be clearly labelled in the Subject line with the acronym RFD
  269. |> >|> >or CFD and the name of the newsgroup or newsgroup hierarchy
  270. |> >|> >which would be directly affected by the proposed change.
  271. |> >|> >
  272. |> >|> >For example:  Subject: RFD: rec.ham-radio.* reorganization
  273. |> >|> 
  274. |> >|> Problem: there are two hierarchies affected by this change.
  275. |> >|> rec.ham-radio and rec.radio.*. Are both to be included? If not, how
  276. |> >|> are the readers of the destination hierarchy to know that the RFD
  277. |> >|> applies to them? (Barring, of course, that it would be posted in their
  278. |> >|> groups.)
  279. |> >|> 
  280. |> >|> And, technically, splitting rec.ham-radio is not a reorganization of
  281. |> >|> rec.ham-radio.*.
  282. |> >
  283. |> >Yes; the dot before the star should be deleted.  
  284. |> 
  285. |> Good try, but I'm not going to go for it. You nicely avoided answering
  286. |> the problem that your example is 1) obsolete, and 2) incorrect. To meet
  287. |> the requirement you are proposing, the Subject, using the same obsolete
  288. |> groups you continue to use, would have to be:
  289. |> 
  290. |> Subject: RFD rec.ham-radio reorganization and rec.radio.* reorganization.
  291. |> 
  292. |> That is more than the 40 characters that the "guidelines" specify.
  293. |> 
  294. Yes, the example is obsolete.  It doesn't matter.  You can treat
  295. these names as meaningless charstrings if you like.
  296.  
  297. No, my proposed-guidelines do not require rec.radio.* to be mentioned,
  298. because no newsgroup in rec.radio.* has its name or charter changed
  299. by the reorganization.
  300.  
  301. ...
  302. |> If, as you claimed earlier, splitting a group changes the charter of the
  303. |> remaining one, then moving another group into a hierarchy changes the
  304. |> charter of every other group in the hierarchy.
  305. |> 
  306. No.  Not unless there are postings formerly welcome in rec.radio.foobar
  307. which are no longer welcome in rec.radio.foobar after the reorg.
  308.  
  309. |> Thus, every group in rec.radio.* would be affected in exactly the sense
  310. |> you define affected to be.
  311. |> 
  312. |> Uhhh, what was that comment about "syntactic specification that both yes
  313. |> and no voter could agree on"? Your own example doesn't agree with your
  314. |> rule.
  315. |> 
  316. See above.
  317.  
  318. |> >|> This, of course, was in the User's Guide.
  319. |> 
  320. |> >Yes, the User's Guide reflects current policy.  If I succeed
  321. |> >in changing current policy, the User's Guide should be updated
  322. |> >to be consistent with the new policy.
  323. |> 
  324. |> If policy changes, I will update the User's Guide, in spite of your
  325. |> instructions to do so. I don't see that your proposed changes would
  326. |> require any changes, however.
  327.  
  328. The users guide currently tells readers that if they see an RFD posted
  329. in a newsgroup they read, they should read that RFD regardless of
  330. what the subject line says.  If my changed policy were to go into
  331. effect, the users guide would explain to readers that groups named
  332. in the RFD might get new names and that certain topics formerly
  333. permitted to be posted to some of these groups will be removed or
  334. moved elsewhere.
  335.  
  336.  
  337. -- 
  338. Rob Strom, strom@watson.ibm.com, (914) 784-7641
  339. IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10598
  340.