home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / news / admin / policy / 835 < prev    next >
Encoding:
Text File  |  1992-12-22  |  5.2 KB  |  113 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 (was Re: Folklore, synth, and guidelines)
  5. Sender: @watson.ibm.com
  6. Message-ID: <1992Dec22.194946.54964@watson.ibm.com>
  7. Date: Tue, 22 Dec 92 19:49:46 GMT
  8. References: <Bz4G3p.6v7@rice.edu> <1992Dec14.125756.7888@jato.jpl.nasa.gov> <EMCGUIRE.92Dec22053832@fuller.intellection.com>
  9. Organization: IBM Research
  10. Lines: 101
  11.  
  12. In article <EMCGUIRE.92Dec22053832@fuller.intellection.com>, emcguire@intellection.com (Ed McGuire) writes:
  13. |> In article <1992Dec21.220935.35613@watson.ibm.com> strom@Watson.Ibm.Com (Rob Strom) writes:
  14. |> 
  15. |>    (1) eliminate subjective arguments about which rename proposals
  16. |>        are "related" by using a purely syntactic criterion.
  17. |> 
  18. |> I haven't seen a problem here that needs fixing.  In fact I believe
  19. |> that the rename proponents are probably better judges of what should
  20. |> be covered in a single ballot than an syntax-based rule ever will be.
  21. |> This is particularly true given that the hierarchy is not consistent
  22. |> and therefore a syntax-based arbitrary rule, which can only digest the
  23. |> data fed to it, will split ballots which logically belong
  24. |> together--and most likely were specifically intended to be fixed by
  25. |> the rename.  There is generally a good reason why these ballots you
  26. |> would be splitting are kept as a unit.
  27. |> 
  28.  
  29. Well, I've tried to argue this proposal without re-opening the
  30. whole rec.music.synth discussion.  But since you mention that
  31. you haven't seen a problem here that needs fixing, perhaps
  32. I need to open Pandora's box just a crack:
  33.  
  34. Your paragraph is worded from the perspective of the proposer
  35. of a multi-hierarchy reorg, or from the perspective of a "yes"
  36. voter who agrees that these groups logically belong together.
  37. From the perspective of a "no" voter --- someone who has
  38. never heard of some of these groups, or someone who thinks
  39. it's totally idiotic that these groups should be mentioned
  40. in the same breath --- such a ballot is a confusion and a trap
  41. for the unwary.  In the case of rec.music.synth, the problem
  42. was compounded by the fact that the subject line described
  43. the ballot as a "rec.music.makers.* reorganization" ballot.  
  44.  
  45. Now it's been posted ad nauseam, and everybody except possibly
  46. one individual is convinced that the rms vote was properly
  47. conducted according to guidelines.  By no means do I want
  48. to reopen *that* can of worms!  We agree that today's guidelines
  49. stipulate that one ignores reading a CFV or RFD at one's peril.
  50.  
  51. But I still think that folks who didn't believe rms "logically"
  52. belonged with rmm* were more likely to miss reading this
  53. ballot than folks who did.  This is orthogonal to any
  54. discussion about whose fault it was that they missed reading
  55. the ballot, which is another can of worms I don't want to reopen.
  56. The fact that the difference between the proposal passing
  57. or failing was a margin of a couple of votes only made things worse.
  58.  
  59. On the principle of "don't put a stumbling block in front
  60. of the blind", I want to avoid a repetition of this situation
  61. by (a) restricting how to label ballots on Subject lines,
  62. (b) making sure Subject lines stay short.
  63.  
  64. I deal with (a) through a definition of what it means
  65. for a ballot to "affect" a group name, and (b) through
  66. restrictions on how many group names may be affected by
  67. a single ballot.
  68.  
  69. |>    (2) make it possible for the specification of the group names
  70. |>        affected by a ballot to always fit on the subject line of an RFD/CFV.
  71. |> 
  72. |> This is more simply accomplished without imposing an arbitrary rule
  73. |> either by posting the entire ballot in different hierarchies with
  74. |> variant subject lines or by posting "alert" subject articles with
  75. |> pointers to the single ballot.
  76. |> 
  77.  
  78. If my proposal is rejected, I will consider yours.
  79.  
  80. |>    (2) Possibly bad:  sometimes people will have to vote two or
  81. |>        more ballots when before they could have voted just one.
  82. |>        This is bad only if the discussions and arguments for
  83. |>        the two sets of votes are essentially the same discussions
  84. |>        and arguments; otherwise it's neutral.
  85. |> 
  86. |> I think this is what I'm arguing is going to happen too many times.
  87.  
  88. In my experience, it's never happened.  
  89.  
  90. Besides the rec.music.synth vote (which I missed, but would have
  91. abstained from all questions other than the rms question had I voted),
  92. the only similar case I can recall is the rec.arts.drwho vote.
  93. This, too, was bundled with some other hierarchy like rec.sf-lovers,
  94. to which the proposer believed r.a.d "logically" belonged.  I
  95. voted "no" on the question, abstained on the irrelevant ones,
  96. and the "logical" reorganization was defeated.  
  97.  
  98. On the other votes I have participated in, either they were
  99. for entirely new groups (for which my proposal makes no
  100. recommendation), or they were votes which would have been
  101. held on one ballot under both the old and the proposed new 
  102. policies.
  103.  
  104. I've been posting and voting here for about 2 years now.
  105.  
  106. I think an extra ballot or two every couple of years is
  107. well worth the price of avoiding the kind of situation
  108. which we encountered with rms.
  109.  
  110. -- 
  111. Rob Strom, strom@watson.ibm.com, (914) 784-7641
  112. IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10598
  113.