🚀 go-pugleaf

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