|
Excuse me while I play the devil's
advocate here.
Is this "jam event record" something
we want to have displayed or recorded at all? If there is a problem with
the count totals between the AccuVote display and the ballots in the Ballot Box,
why do you want to so quickly use it as an excuse? What would you do
if there was no jam event recorded and yet there was still a mismatch between
ballots in the box and the counter on the AccuVote?
What would you get from a jam event
record? That a jam happened? But who
was at fault: the poll worker or the machine?
How do you know if the mismatch was caused by that jam.
Would they call into question the
results of an election if a unit showed multiple jams yet the ballots totals
matched the counters?
I understand it would be great to have the detail for troubleshooting,
but do you think they would find the fault due to the poll worker when they
have a machine that could be perceived as "at fault" instead? I think
less info is better under these circumstances.
What kind of interpretation would someone make when seeing that
detail?
Example
"Oh, look here! The paper tape
shows it jammed during the day. The machine must be responsible for the
error in the totals."
If we provide this "jam event record"
as an excuse, wouldn't it throw doubt onto the integrity of the machine and its
programming. I believe it is better to leave answers for these
unsubstantiated anomalies to the discretion of the election
supervisor.
Outside of the "O" level ROMS, when a
ballot is processed into a Ballot Box by the AccuVote, it is
counted. If a reader takes a ballot, it
accurately scans that ballot and deposits it into the Ballot Box. If
there is any problem with the reader (i.e., hung or failed Self Test), it will
not process the ballot into the Ballot Box.
Play out an election night scenario
in your head with these kind of questions arising. Now imagine there is
nobody there from Global to explain the information provided.
Let's not consider every user's
request as an absolute. Perhaps the user is just as much in the
dark about the ramifications of that request as we are.
Ian
----- Original Message -----
Sent: Thursday, December 09, 1999 8:26
PM
Subject: Re: Logging Scanner Jams (was:
Audit trail improvement suggestions)
I think the statistical approach would be adequate, although
the log with a
date and time stamp would be the preference.
I think
that saving these for the 2.0 release is OK in the sense that we
might be
able to "sell" the upgrade, vs having it be required. However,
it
might mean the AV would have to be recertified in many states. Not
good.
Other thoughts?
----- Original Message -----
From: Guy
Lancaster <glanca@dieboldes.com>
To:
Kerry Martin <kerry@dieboldes.com>
Cc:
<rcr@dieboldes.com>
Sent: Thursday,
December 09, 1999 8:40 AM
Subject: Re: Logging Scanner Jams (was: Audit
trail improvement suggestions)
> Some form of
logging scanner jams has been brought up
> before and I think that I
spoke with Steve about a month ago
> about it. This may also be
related to Jane's RCR: Print
> Vote Centers Activity of Oct 27,
1999.
>
> The problem, as Monica stated, is that the
officials need
> statistical support when trying to resolve
discrepencies
> between the number of ballots in the ballot box and
the
> number recorded by the Accu-Vote. I can see three
possible
> ways of providing this, each with pros and
cons.
>
> 1) Add a stats counter for the number of jams
experienced
> since the counters were last cleared. While we're at
it, we
> could have separate counters for counted and returned
ballot
> jams. This would be my preference since it provides
the
> required statistics while consuming the minimum of
>
resources. However it requires a memory card format change
> and so
would only be available in major new releases such as
> the upcoming
version 2.0. These statistics would appear on
> the audit reports
and could be uploaded for reporting by
> GEMS.
>
> 2) Print
a log entry on the internal printer for each jam.
> This could be
selectively enabled and disabled from GEMS'
> Accu-Vote parameters and
would not affect the memory cards.
> Downsides include having to prevent
the tape from jamming
> while it's locked in the printer compartment and
having to
> count the entries on the tape to gather the
statistics. The
> upside is that it would provide a timestamp on
each entry
> which could help with resolving the
problems.
>
> 3) Record an entry in the audit log for each
jam. This one
> scares me a little because we have limited space
on the
> memory card for the audit log and currently we allow
for
> about 400 entries. The purpose of the log is to
record
> critical operations such as inserting the memory card,
>
powering on the unit, the starting and ending of counting,
> printing
reports, and a few others. Although possible, it
> is very
unlikely that we would overflow the audit log with
> these
entries. Events like jams are far less predictable
> and a problem
with a machine could cause a large number of
> jams. Should the
log overflow, the oldest entries are lost.
>
> Some
would suggest that we increase the size of the audit
> log or
dynamically allow it to grow to use available memory
> card space.
The latter is technically difficult especially
> if we want to record
events starting from the beginning of
> the download operation as we do
currently. Allocating more
> space for log entries comes at the
expense of less space for
> ballot information and counters which will
affect those
> counting absentee ballots. It seems less of an
issue for
> 128K memory cards than for 32K but once we decide to
log
> jams, we have to allow for it in all
systems.
>
> My suggestion is to add support for
optionally printing a
> jam log message in the next 1.94 release.
For version 2, we
> would continue to support this plus add statistics
counters
> for jams. Unless people feel both that it is critical
that
> we record the time of each jam and that managing the
printer
> tape is not acceptable, I would avoid adding this to
the
> audit
log.
>
>
Guy
>
>
|