Re: about the Python code

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Thu Jul 24 2003 - 14:11:34 CDT

OK, I concede.

> > Perhaps we should add a "ballot type" to the ballot number in case
>> there are multiple ballot types at an election. There are multiple
>> ballot types at a primary election, and we need to handle that.
>I don't see where this has anything to do with ballot number. In the larger
>study, we'll have to deal with how to deal with primary elections. Our demo
>is for a general election. Let's worry about that later.

I disagree. I'll say more below.

> >(We also need a way to ensure that the voter votes only with the
>> correct ballot type. What's our solution to that problem?)
>I think you might be mixing the meaning of "ballot type" and "ballot style."
>Doug can probably give us some better terminology here, but "ballot style"
>refers to the mix of contests that appears on the ballot according to the

One of the purposes of the demo is to lend an air of credence to
realism to what we do. People will attack us on that very trivial
but real point. I don't care what it is called, but we should plan
for at least ostensible support for it, and adding a code to the ID
is something easier to do now than later. Why not plan in what we
know now? How does it simplify things to leave it out? We don't
have to handle it, we just have to include it from the CD, as you
mentioned below.

>FYI, the design I've described deals with ballot styles like this: The
>county produces CDs which include a database covering all the contests in
>all the precincts in the county. All the CDs would be exactly the same and
>would include all the software for the voting machine. For each precinct,
>floppy disks (or some other media) are provided for each PC/voting machine.
>The floppy disk would have a parameter file that indicates the precinct
>number and machine number. The voting machine boots up from the CD and
>reads the parameter file on the floppy so the machine provides the correct
>ballot style based on the precinct number and sets the correct ballot number
>prefix accordingly.

In primary elections, ballot styles differ. Don't demonstrate a
system that doesn't include that concept, at least in the talking
points. Leaving it out provides a cheap shot for our opponents. We
need to have an answer to that question and not leave it for the
vague "later." We don't need to fully implement the solution, but we
do need to have one we can talk about and partially implement.

> > Then date in the form YYYYMMDD.
>Depends on how precious our character space is. We may want the date

You may want to use a binary (or other) encoding, but we do need to
use a four digit year for Y2K compliance (yeah I know it doesn't
really matter, but do you want non-Y2K compliance as a bar for

> > I think there should then be a ballot sequence number (one
>> digit/character). If someone makes a mistake and prints another
>> ballot, then use the same ballot number with an incremented ballot
>> sequence number. It's a good check that the spoiled ballot won't be
>> used (since it matches in ballot number except for the
>> ballot sequence number on the spoiled ballot is smaller). Does
> > someone who spoils a ballot have to go back to the same PC they
>> originally voted on?
>I see no need for your "ballot sequence number." But again, this is not an
>issue for the demo. The voter is instructed to go to a poll worker when a
>ballot is spoiled. The poll worker would tear off a corner of the ballot
>(containing the number) and shred the rest of the ballot. The torn off
>number would be put in a box to facilitate reconciliation. It's not really
>necessary to have the tear off but it will make it quicker to reconcile.
>The ballot numbers of spoiled ballots are entered into the admin PC so that
>when the polls close, they can account for all the ballot numbers used. If
>someone doesn't follow procedures such that it doesn't add up, then the
>ballot numbers must be read from each ballot from the ballot box so that all
>the extra ballot numbers in the electronic file are excluded that way.

For the same reason as above, it IS an issue for the demo. We need
to have a solution even if we don't implement it fully. Look up the
word verisimilitude. We need to have that or we'll be summarily
rejected. We don't want to give them any more reasons for saying
we're not for real.

- --
Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA 94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
Received on Thu, 24 Jul 2003 12:11:34 -0700

This archive was generated by hypermail 2.1.8 : Wed Aug 06 2003 - 12:50:26 CDT