Article View: news.admin.policy
Article #125Re: Newsgroup creation guidelines (was Re: Folklore, synth, and guidelines)
From: Rob Strom
Date: Tue, 22 Dec 1992 19:49
Date: Tue, 22 Dec 1992 19:49
101 lines
5435 bytes
5435 bytes
In article <EMCGUIRE.92Dec22053832@fuller.intellection.com>, emcguire@intellection.com (Ed McGuire) writes: |> In article <1992Dec21.220935.35613@watson.ibm.com> strom@Watson.Ibm.Com (Rob Strom) writes: |> |> (1) eliminate subjective arguments about which rename proposals |> are "related" by using a purely syntactic criterion. |> |> I haven't seen a problem here that needs fixing. In fact I believe |> that the rename proponents are probably better judges of what should |> be covered in a single ballot than an syntax-based rule ever will be. |> This is particularly true given that the hierarchy is not consistent |> and therefore a syntax-based arbitrary rule, which can only digest the |> data fed to it, will split ballots which logically belong |> together--and most likely were specifically intended to be fixed by |> the rename. There is generally a good reason why these ballots you |> would be splitting are kept as a unit. |> Well, I've tried to argue this proposal without re-opening the whole rec.music.synth discussion. But since you mention that you haven't seen a problem here that needs fixing, perhaps I need to open Pandora's box just a crack: Your paragraph is worded from the perspective of the proposer of a multi-hierarchy reorg, or from the perspective of a "yes" voter who agrees that these groups logically belong together. From the perspective of a "no" voter --- someone who has never heard of some of these groups, or someone who thinks it's totally idiotic that these groups should be mentioned in the same breath --- such a ballot is a confusion and a trap for the unwary. In the case of rec.music.synth, the problem was compounded by the fact that the subject line described the ballot as a "rec.music.makers.* reorganization" ballot. Now it's been posted ad nauseam, and everybody except possibly one individual is convinced that the rms vote was properly conducted according to guidelines. By no means do I want to reopen *that* can of worms! We agree that today's guidelines stipulate that one ignores reading a CFV or RFD at one's peril. But I still think that folks who didn't believe rms "logically" belonged with rmm* were more likely to miss reading this ballot than folks who did. This is orthogonal to any discussion about whose fault it was that they missed reading the ballot, which is another can of worms I don't want to reopen. The fact that the difference between the proposal passing or failing was a margin of a couple of votes only made things worse. On the principle of "don't put a stumbling block in front of the blind", I want to avoid a repetition of this situation by (a) restricting how to label ballots on Subject lines, (b) making sure Subject lines stay short. I deal with (a) through a definition of what it means for a ballot to "affect" a group name, and (b) through restrictions on how many group names may be affected by a single ballot. |> (2) make it possible for the specification of the group names |> affected by a ballot to always fit on the subject line of an RFD/CFV. |> |> This is more simply accomplished without imposing an arbitrary rule |> either by posting the entire ballot in different hierarchies with |> variant subject lines or by posting "alert" subject articles with |> pointers to the single ballot. |> If my proposal is rejected, I will consider yours. |> (2) Possibly bad: sometimes people will have to vote two or |> more ballots when before they could have voted just one. |> This is bad only if the discussions and arguments for |> the two sets of votes are essentially the same discussions |> and arguments; otherwise it's neutral. |> |> I think this is what I'm arguing is going to happen too many times. In my experience, it's never happened. Besides the rec.music.synth vote (which I missed, but would have abstained from all questions other than the rms question had I voted), the only similar case I can recall is the rec.arts.drwho vote. This, too, was bundled with some other hierarchy like rec.sf-lovers, to which the proposer believed r.a.d "logically" belonged. I voted "no" on the question, abstained on the irrelevant ones, and the "logical" reorganization was defeated. On the other votes I have participated in, either they were for entirely new groups (for which my proposal makes no recommendation), or they were votes which would have been held on one ballot under both the old and the proposed new policies. I've been posting and voting here for about 2 years now. I think an extra ballot or two every couple of years is well worth the price of avoiding the kind of situation which we encountered with rms. -- Rob Strom, strom@watson.ibm.com, (914) 784-7641 IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY 10598
Technical Details
Message-ID:
<1992Dec22.194946.54964@watson.ibm.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!scifi!watson!Watson.Ibm.Com!stromReferences:
<Bz4G3p.6v7@rice.edu> <1992Dec14.125756.7888@jato.jpl.nasa.gov> <EMCGUIRE.92Dec22053832@fuller.intellection.com>Show Full Headers
Complete Article Headers
Newsgroups: news.admin.policy Path: arc1-ca.pugleaf.net!sparky!uunet!scifi!watson!Watson.Ibm.Com!strom From: strom@Watson.Ibm.Com (Rob Strom) Subject: Re: Newsgroup creation guidelines (was Re: Folklore, synth, and guidelines) Sender: @watson.ibm.com Message-ID: <1992Dec22.194946.54964@watson.ibm.com> Date: Tue, 22 Dec 92 19:49:46 GMT References: <Bz4G3p.6v7@rice.edu> <1992Dec14.125756.7888@jato.jpl.nasa.gov> <EMCGUIRE.92Dec22053832@fuller.intellection.com> Organization: IBM Research Lines: 101