From: jmaynard@oac.hsc.uth.tmc.edu (Jay Maynard)
Newsgroups: news.groups
Subject: Re: Give up, Dave, you've lost!
Date: 18 Nov 1992 16:02:04 GMT
Organization: UT Health Science Center Houston

In article <1992Nov17.193259.18024@watson.ibm.com> strom@Watson.Ibm.Com (Rob Strom) writes:
>As I posted elsewhere, one of the things being voted on was
>whether the groups alleged to be related were, in the opinion
>of the voters, actually related in the way being claimed.

OK...but, by that argument, there's no way to know whether or not the groups
are actually related until the vote's in. Other factors, therefore, must
determine how things are to be done.

>So it is already forbidden to run *one vote* for multiple groups.
>I assume you meant *one ballot*.

I did.

>In my opinion, if there is
>any doubt as to whether people will agree on the relatedness
>of the votes, there should be several ballots, although they
>can be posted on the same date.  If the groups turn out to
>be as related as the proposers think they are, people will
>see all the ballots and vote them;  otherwise they won't.
>That's why I proposed a purely syntactic and not a semantic
>test for merging votes onto a ballot.  Otherwise the person
>composing the ballot is presuming the truth of the very
>question being voted.

The problem is that you've just multiplied the votetaker's work by the number
of questions to be voted on, and made the issue much more confusing for the
voters. Voters will see multiple ballots, assume they've already voted, and
skip on to the next one. Proposers have to deal with multiple ballots for a
person, and that directly multiplies the work to be done.

>Presumably you were the vote-taker for the rec.ham-radio reorg.

I was.

>Why is it significantly harder to sort the yes/no in each of
>3 different piles than to sort 3 columns of yes/no in one
>single pile?

Here's what the reorg accomplished:
rec.ham-radio ==> rec.radio.amateur.misc
rec.ham-radio.packet ==> rec.radio.amateur.packet
rec.ham-radio.swap ==> rec.radio.swap
create rec.radio.amateur.policy as a split from rec.ham-radio
create rec.radio.cb as a split from rec.ham-radio, more or less

I handled this as five votes on one ballot, with a specified format that
allowed me to send each vote to an automated process that parsed, condensed,
and recorded it; tallying the vote was done by another process.

As I understand your proposal, you would have required the first two proposals
to be on one ballot, the third to be on another, and the last two to be on yet
another. This would have made the task of collecting and tallying votes three
times more work for me, and would have led to more confusion.

What would have been gained?

>I think the percentage of network traffic devoted to votes
>is small enough relative to the total network traffic that
>multiplying it by a small factor is not a serious impact.

What about the work of collecting and tallying the votes, and hat about the
confusion factor for the voters?
-- 
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@oac.hsc.uth.tmc.edu      | adequately be explained by stupidity.
           "Cat: Four legs and an attitude." -- Jim Reese