home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: news.admin.policy
- Path: 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: <1992Dec21.220935.35613@watson.ibm.com>
- Date: Mon, 21 Dec 92 22:09:35 GMT
- References: <Bz4G3p.6v7@rice.edu> <1992Dec14.125756.7888@jato.jpl.nasa.gov> <EMCGUIRE.92Dec20122915@mother.intellection.com>
- Organization: IBM Research
- Lines: 77
-
- In article <EMCGUIRE.92Dec20122915@mother.intellection.com>, emcguire@intellection.com (Ed McGuire) writes:
- |> In article <1992Dec18.210827.52872@watson.ibm.com> strom@Watson.Ibm.Com (Rob Strom) writes:
- |>
- |> Can you clarify what you think the "needless complications" will
- |> be? With automated software doing the actual vote tallying,
- |> why is it so terrible if instead of a six-vote ballot, circumstances
- |> required you to have two three-vote ballots?
- |>
- |> Actually, I was thinking more of the complications introduced to the
- |> voter. A single vote article, containing a complete explanation of
- |> the proposed changes and a single ballot, seems simpler to me than
- |> multiple cross-referenced vote articles with multiple ballots, each of
- |> which I should find and vote on if the proposed changes are relevant
- |> to me. Rename proposals do not need to be artificially separated into
- |> multiple ballots to accomplish what you want. Just use a different
- |> subject line on the same vote article as appropriate.
-
- I wasn't suggesting multiple cross-referenced vote articles.
- I was suggesting multiple independent ballots.
-
- I don't view the separation as "artificial". There is always
- an element of subjectivity if I think that a rename of
- rec.truckers is related to a rename of rec.ham-radio, whereas
- you never read rec.ham-radio and therefore think that the
- rec.truckers rename is completely unrelated.
-
- My proposal tries to do the following:
-
- (1) eliminate subjective arguments about which rename proposals
- are "related" by using a purely syntactic criterion.
-
- (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 proposal does have the effect of splitting some ballots that
- previously hadn't been required to be split. This splitting
- has mixed effects:
-
- (1) Good: sometimes people can just ignore some of the ballots
- that before they were required to read and abstain on
-
- (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 the advantages of short clear subject lines, and
- precise guidelines as to when votes are sufficiently
- "related" as to appear on one ballot outweigh the disadvantage
- that some people will occasionally have to vote two three-vote
- ballots instead of one six-vote ballot.
-
- |>
- |> There's no point in putting something onto a ballot until you've
- |> first explained to the new users why they should read ballots.
- |>
- |> All of my proposals are based on the premise that readers
- |> have a limited time to read articles, and that by default
- |> they will ignore articles unless there is a compelling
- |> reason to read them.
- |>
- |> My feedback was based on the same premise. The problem is, how do you
- |> get people to read the "guidelines for voters?" Readers are far more
- |> likely to be motivated to pay attention by a well written subject line
- |> warning about the vote in their favorite newsgroup itself.
-
- If the guidelines for voters are put into news.announce.newusers,
- and the newsreading software points all newcomers into this group,
- then we're doing the best we can.
-
- The suggestions aren't mutually exclusive; I also agree that
- the subject lines and the contents of the ballots should be
- informative as well.
- --
- Rob Strom, strom@watson.ibm.com, (914) 784-7641
- IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY 10598
-