[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Ballot Station v4.0.11 "anomaly" and other JoCo questions
Comments below:
Sent: Thursday, April 25, 2002 3:54 PM
Subject: RE: Ballot Station v4.0.11 "anomaly" and other JoCo
questions
CENTRAL UPLOAD ONLY: I am also concerned, because due to
this incident, JoCo is opting to NOT modem in results from regional substations,
much less precincts. They are planning to set up parallel GEMS server
systems to upload all PC cards centrally, twice. That way they have two
reports from the same data loaded into separate systems to compare and
audit. Is there no way we can provide some kind of report off the Regional
upload units that can be compared to some kind of report from GEMS to be
accountable that an "anomaly" has NOT occurred? What is our "standard"
check and balance proof for returns on election night?
I may be off base with my opinion here,
however:
Based on what I'm reading, the tail is starting
to wag the dog here. Whatever, procedures are used on election night
should be used in the testing and L&A. Problems will be caught
if they exist. Procedures were not followed and an error was encountered
that was not tested for. As long as JoCo is successful in keeping
this issue a technical one, we are on the defensive.
We need to emphasize the importance of the
L&A, procedures, and the canvass process - all of which are part of the
entire election. Writing new codes to give feedbacks about unanticipated
anomolies is not realistic. The answer to the last question is "the
L&A and the canvass are the check and balance". Every voting system in
the world depends on these two functions to ensure election results, whether its
lever, punch card, or touch screen. Yes. There was a bug not found on
election night - because we didn't test the procedure used on election
night. Bug found and fixed. This is a procedural issue not
a technical issue.
Finally, if they follow the same procedure on
the dual upload concept, and again break with their published procedures, and
encounter another bug, they will simply replicate any bug that they
encounter. Had they done the exact same procedure on a dual system, they
would have had the same issue - twice.
>
> LOGIC AND ACCURACY PRETEST METHODOLOGY: A
reference has been made to be
> sure that a regional upload client be sure
to include that functionality in
> the logic and accuracy pretest.
Do we have documentation on all the
> functionalities that should be
included in our logic and accuracy testing?
I know I don't. These are hammered
out with the project manager and the site. The reason it is often different from
site to site is related to state law differences, as well as history in the
county of how things are done, as well as how the county interprets the
law. There are 25 different ways of doing a checklist for L&A in
California, even though the code may read one way.
> Is there a
checklist to use to prepare the test and then to run the test?
Same answer. There should be a
baseline check list, but you take the base and modify it. Basically you
replicate all functions you will use during the actual counting of
ballots. Robert may have something he's doing for Alameda if you need a
place to start.
> For the optical scan test deck, why are we not
sending out the algorithms
> being used to created the test deck? If
we at least send out "how the test
> was prepared" we could account for
NOT sending out a "Test Deck Report" to
> compare the L&A report
to.
The algorith is LA5 deck gives you a
1,2,3,4,5 pattern. That is the output of the report. Once you know
the output, you don't need a report. Let me
know if you mean something else or I'm not getting what you're
saying.
>
> Thanks. Les
>
>
>
>
> -----Original Message-----
> From: owner-bugtrack@dieboldes.com
[mailto:owner-bugtrack@dieboldes.com]On Behalf
> Of Jeff Hintz
> Sent:
Thursday, April 25, 2002 4:28 PM
> To: bugtrack@dieboldes.com> Cc: stevem;
barry
> Subject: RE: Ballot Station v4.0.11 "anomaly"
>
>
> Hi Lesley,
>
> There was no Error Message received for
this problem that occurred on
> Election Night. The transferring of
the results to the GEMS host computer
> went through without any error
messages displaying a problem. The problem,
> as Tab wrote up in the
e-mail that Frank sent out to Connie, is that during
> the direct
transferring process, the information on the first Vote Center
> that was
transferred, was stored in the Cache memory of the AVTS unit, when
> the
second, or subsequent, Vote Center was inserted and then transferred,
>
the AVTS unit was then transferring those new totals, but with
previously
> stored Race ID's as well as the new Race ID's, and GEMS being
confused,
> simply put the totals into the Races where it thought the
totals should go.
>
> That is the best explanation that I can give
you. For a better and clearer
> picture, you will have to refer to
Ken or Tab.
>
> Jeff
>
> -----Original
Message-----
> From: owner-bugtrack@dieboldes.com
[mailto:owner-bugtrack@dieboldes.com]On Behalf
> Of Lesley Thompson
>
Sent: Thursday, April 25, 2002 2:31 PM
> To: BugTrack@dieboldes.com> Cc: stevem;
barry
> Subject: Ballot Station v4.0.11 "anomaly"
>
>
> Jeff Hintz, Ken, Tab, or Robert Chen...
>
> What were the
ballot station error code messages that were received during
> the central
upload of the election day vote centers? Johnson County still
> has
questions and I am trying to finalize the Report of Findings. Also,
can
> you explain to me what the statement:
>
> "This
problem only occurred when the second, or subsequent, Vote Centers
> being
uploaded during the same transmission session, had the same Race as a
>
previously uploaded Vote Center."
>
> And, why would the Leawood
Mayor's race, which was not on any of the vote
> center PC cards uploading
centrally, end up with errant votes? And, where
> did the 300 votes
go that were not accounted for in the initially released
> report?
>
> Can someone draw me a picture?
>
> Thanks!
Les
>
>
>
>