Re: [OVC-demo-team] Re: Reconciliation System GUI (was: Re: Ballot GUI)

From: Alan Dechert <alan_at_openvotingconsortium_dot_org>
Date: Tue Feb 24 2004 - 18:03:41 CST


> Was anything decided so we can move forward with the BRS? I don't want to
> begin coding again until I'm clear that I've got the green light to do so.
> would be great to have another Qt developer on board, but I'd like to
> advocate we stick with Python as our implementation language (for the many
> reasons discussed before).
Here's what I believe to be true on this. Jan and Greg should be able to
address this too. Fred should tell us something more definitive.

As I mentioned, I thought Jan had some code that could be easily adapted to
accomplish the first part of this: namely, take the barcode data and write
out an XML file for the ballot. Here's what Jan wrote on Sunday:

So this leaves a couple of parts to be done for the BRP (what some are
calling BRS). We need some code that

> Also, I noticed Alan's code for the BVA; it is assuming it will be run in
> Win32 environment? I thought the goal was to produce a system using
> completely open components? If all he needs is something to read barcodes
> generate an audio playlist, that can be done in Linux just as easily. ....
Right. The problem is that I spent a lot of time trying to get someone to
write this ... then finally wrote it myself in one afternoon with tools I am
familiar with. At this point, it has been tested by several people and it
works fine on a legacy system.

Keep in mind that with the demo, we are only demonstrating some concepts.
We can break whatever rules to get it done. The software will be thrown out
after the demo. I really don't want to re-do pieces that are done enough at
this point. I want to focus on getting the pieces done that are left to be
done. If we have time to put something in there that is better, we can do
that. But let's get it all done and assembled before we talk about re-doing
parts of it. We are going to make a go/no-go decision March 1 for a March
15 demo.

> It would also complicate matters if the ballot and reconciliation software
> targets X11 instead. Let's nail down some harder technical specs.
We'll "nail down harder technical specs" for the production system.

> Going back to the BRS, is my workflow pretty accurate? Here it is again:
> 1. User verification/authentication

> 2. Voting Station inventory checking
Not sure what you mean. The procedure is outlined here

> 3. Manual voted ballot count/scan
Okay. Count is one step; scan is next. The manual count is entered before
you start scanning.

> 4. Collect voting station data (check #2)

> 5. Check test ballots
More specifically, "Enter the ballot ID number for each of the test ballots
that were printed on start up"

> 6. Register spoiled/missing ballots
Well... you can only enter the IDs for known spoiled ballots. The missing
or unaccounted ballots will be figured from what's left (EBIs not matched in
any other way).

> 7. Compute/report errors on totals (#3 == #4 - (#5 + #6))

> 8. Serialize voter data; run diff on ballot vs. vote station data
I'm not sure what you mean by "serialize voter data." Anyway, this part
really is part of the previous step (your "7"). That is, in order to
produce the report in 7, you have to find the matching v-something file for
each b-something file (as Matteo calls them). Then you have to check the
contents to make sure they have the same vote data (except that the
b-something EBIs won't have any write-in data.. other than the indication
that a writein was indicated). If there is no matching v-something for a
b-something, then you have an error to report. If the matching v-something
has some data that differs from the b-something EBI, then you an error to

The number of unaccounted ballots is the number of v-something EBIs left
after you take away the (voted ballots + spoiled ballots + test ballots),
where the voted ballots equals the number of b-something EBIs.

> This could be done any number of ways; I remember Matteo envisioning a
> of simple programs that could be strung together. I'd like to see things
> integrated as components instead, as both approaches solve the same goals
> I don't see why such loose coupling is necessary. Is this to be a
> GUI application, a simple UI-wizard type system, or done on the command
It should look nice. People will want to see this.

> Or would it be up to us to see what we can do? Also important is how we
> structure the codebase. Will we be installing this as a Python
> Will each component be a separate package?
The BRP will be running on the "admin PC." I don't know of anything else
that will be running on this PC for the demo (it could be Linux/Python but I
don't really care... whatever it takes to get it done!). Before the
procedure is run, some data will be entered like authorized users/passwords,
serial numbers for the CDs coming from each voting machine PC. i.e., when
it prompts to insert the disk for voting machine #2, you need to put in the
CD it's expecting or it will complain.

Also--I think I mentioned this somewhere--the witnesses sign in at the
beginning. They should also signoff to indicate they witnessed the
completion of the procedure with no funny business.

Alan D
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Thu Apr 1 02:40:20 2004

This archive was generated by hypermail 2.1.8 : Thu Apr 01 2004 - 02:40:36 CST