From: strom@Watson.Ibm.Com (Rob Strom)
Newsgroups: news.groups
Subject: Re: Give up, Dave, you've lost!
Date: 18 Nov 92 20:31:20 GMT
Organization: IBM Research

In article <7900@lib.tmc.edu>, jmaynard@oac.hsc.uth.tmc.edu (Jay Maynard) writes:
|> 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.
|> 

Exactly!  That's why I said in an earlier posting that
it is circular reasoning to argue that votes are legitimately
bundled onto a single ballot because they're "related".

That's why I advocated a *syntactic* criterion for determining
whether votes may be bundled.


|> 
|> 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.
|> 

I disagree that voters will assume they've already voted, since
each ballot will have a different Subject line.

I disagree that this multiplies the work to be done, because
there are exactly the same number of yea's and nay's --- they're
just distributed onto different ballots, instead of different
columns of a single ballot.

Even if this did make it more difficult for the vote taker,
my concern is more for the voters and maximizing fairness
of all, rather than minimizing work for the vote taker.

|> 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.
|> 

Actually, assuming that ==> means renaming (i.e. that there
was no previous group called rec.radio.amateur.misc), the
1st, 4th, and 5th votes could be bundled onto one ballot,
and the 2nd and 3rd votes would be on different ballots.

The first ballot affects the newsgroup rec.ham-radio:

The three questions are:
(1) Shall the name of this group be changed to rec.radio.amateur.misc?
(2) Shall the charter of this group be changed to exclude policy discussions,
    which would then be moved to a new group called rec.radio.amateur.packet?
(3) Shall the charter of this group be changed to exclude CB radio,
    which would then be moved to a new group called rec.radio.cb?

The second ballot affects the newsgroup rec.ham-radio.packet.

The third ballot affects the newsgroup rec.ham-radio.swap.

Presumably all the ballots could be sent to the same location,
and your automated parser/tallyer could have done exactly
what it did before.  The parsing algorithm would be different, that's all.

|> What would have been gained?

People who read only the newsgroup rec.ham-radio.swap, never
having heard of the newsgroup rec.ham-radio (this is probably
less likely than the recent case, where I read rec.music.synth
but not any of the rec.music.makers.* groups) would
have gotten a CFV whose subject line mentioned *their*
group, rather than possibly receiving a CFV whose subject
line mentioned a group they never read.

My position is based upon generalizing the published subject line
guidelines for general postings:  subject lines should
be the gating factor in deciding whether to read a posting;
you should not expect a posting with a seemingly irrelevant
subject line to be read, even if it is posted in
the correct group.  I agree with these guidelines as
applied to general postings; I think they should be
equally applicable to CFVs.


|> 
|> >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?

The work of collecting and tallying the votes was done by
computer, so I claim there was no impact.

And the voters would not be confused at all.  Voters
interested in rec.ham-radio could vote on their issues;
voters interested in rec.ham-radio.packet could vote
on their issue, etc.  Voters with multiple interests
could vote on multiple issues.  Voters not having
multiple interests or not knowing or not caring
about certain issues wouldn't have to wade
through questions they don't care about and
wouldn't have to abstain about questions they
don't care about.  Simple.

-- 
Rob Strom, strom@watson.ibm.com, (914) 784-7641
IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10598
Newsgroups: news.groups