|
Hey everyone,
I wanted to post text from this
letter from Anchorage and get some commentary. I will post on it myself
later. John McLaurin is requesting advice on the matter so he can respond
to Anchorage's letter. This is what Anchorage wrote:
January 6, 2000 My staff and I have reviewed your letter. We think we understand but aren't sure. So, I'm going to try to put in words what we think it means using terms we commonly use for our elections. Let me know if we've misunderstood. 1. Definitions:
2. Understanding of Mechanics:
If we've interpreted the definitions correctly and made the right assumptions, it appears you've accommodated the "vote once count twice concept". However, we have a few questions left. 1. Is there a limit to the number of shadow/shadowed races or propositions that can be assigned within a precinct? At this point, we have one precinct in which there are seven base precincts and at least five of these would involve shadow propositions. 2. What is the purpose of the non-service area category? 3. Database #1 created two ballot styles until "printed with precinct ID's" which then doubled the number of ballot styles generated. Is that a manual process or is it controlled through the assignment of base precinct identifiers? 4. When Vickie and I were in McKinney for training last January, we identified all base precincts for the 114 precincts in Anchorage. I think Tyler kept a disk and gave us a copy too. Would it be possible to run that set up with the enhanced software and send us a copy of the resulting base precinct report? If the report can be run, will it show which service area propositions would be shadowed within the precincts? On another note, I would like to thank you and the staff at Global for your efforts to make it possible for Anchorage to use your product. We've been working toward this end for about 18 months now and we seem very close to actually running our local election on the Accuvote system. However, we have no contract in place and we cannot take delivery of the hardware/software until a contract is signed. As we discussed on the phone, I understand your reluctance to sign a contract generated by the municipality but surely you understand the municipality will not sign a contract generated by Global. As Global has done with other jurisdictions, it will be necessary to make some accommodations. I want to convey to you my sense of urgency in this matter. To feel comfortable, I need to have a contract in place by the end of January, 2000. Otherwise, the window for this year's election will be missed. Quite frankly, if we don't make this window I don't intend to pursue the purchase further. I don't mean to be cantankerous but there's not much incentive for me to learn a new vote system when I only plan on directing the next two (2000 and 2001) local elections. Lejane Ferguson, Municipal Clerk Anchorage wrote this letter based upon an e-mail (excerpted below) which I sent to John which explained the functionality and the testing conducted. Here is the explanation of the materials I
gave you from the Anchorage testing. First, some background information on the
functionality itself. This is an excerpt from Ken’s e-mail on the topic:
(This) RCR (is) essentially a "vote once count twice" paradigm. GEMS now has new race types Shadow and Shadowed to accomplish this. Shadowed races sit on the ballot exactly on top of some precinct-wide shadow race. That is, they "shadow" the real race. The catch is that shadowed races can have different parties or split districts, and can hence generate different card ids even though the artwork "looks" the same. On reports, shadowed races appear just like any other race. The user interface for creating shadow races is a little like recall races. To use shadow races, you need to set up a shadow race that is on all cards of a precinct. For Anchorage, the shadow race would be an area wide district race. Next, create shadowed races and set the controlling race to the shadow race. Shadowed races do not have a candidate tab, nor have any layout options. These are maintained by the controlling race. The shadowed races should be set up for some subset of the ballots in the precinct. For Anchorage, it would be a race with the service area district, and might split some precincts. When ballots are generated, separate cards will be created for the splits/parties of the shadowed races. You don't need to do anything special in layout. If you manually move a shadow race on a card, the shadowed race will be automatically "moved" with it. The shadowed races are not actually drawn, but layout and download know they are there. There is no need for any ROM upgrade to take advantage of shadow races. To the AccuVote they are just races on the card that happen to have the same voting positions. We are still working on the AccuVote 2.0 firmware that will provide an alternate way of handling California and Alaska, but in the mean time shadow races will do the trick without the necessity of a ROM upgrade. The AccuVote-TS doesn't yet support shadow races. We'll get to that in plenty of time for early voting in California however. For the first database I created for this testing (which had only one double count question – the Hinterlands Water Question) there are three districts: Jurisdiction Wide, Non-Service Area, and Service Area. I created three precincts, one completely out of the Service Area (named precinct 1 and ID numbered 10), one completely in the Service Area (named precinct 2 and ID numbered 20), one split by Service Area and Non-Service Area (named precinct 3 and ID numbered 30). I created four races; race 10 is a candidate race assigned to the Jurisdiction Wide district, race 20 is a candidate race assigned to the Non-Service Area district, race 30 is a shadow race assigned to the Jurisdiction Wide district which contains the text of the Hinterlands Water Question, race 40 is a shadowed race assigned to the Service Area district and controlled by race 30. This creates two ballot styles, four when printed with precinct ID’s (which the ballots used for the testing were). These were tested using memory cards from each of the three precincts to produce the results tapes and election night reports which you have. For the second database I created for this testing (which had two double count questions – the Hinterlands Water Question and the Northwoods Fire Question) there are three districts: Jurisdiction Wide, Water Service Area, and Fire Service Area. I created one precinct with four splits ("base precincts" to use the correct GEMS terminology). One base precinct is Out of the Water district and Out of the Fire district, one base precinct is Out of the Water district and In the Fire district, one base precinct is In the Water district and Out of the Fire district, and one base precinct is In the Water district and In the Fire district. I created five races; race 10 is a candidate race assigned to the Jurisdiction Wide district, race 30 is a shadow race assigned to the Jurisdiction Wide district which contains the text of the Hinterlands Water Question, race 40 is a shadowed race assigned to the Water district and controlled by race 30, race 50 is a shadow race assigned to the Jurisdiction Wide district which contains the text of the Northwoods Fire Question, race 60 is a shadowed race assigned to the Fire district and controlled by race 50. This creates four ballot styles which were tested using a memory card from the one precinct to produce the results tapes and election night reports which you have. I think Anchorage has it pretty much correct. Like I said, I will post on it later. Sorry for the big to-do but John wanted to get our input. Thanks, y'all Tyler |