[Date Prev][Date Next] [Chronological] [Thread] [Top]

# Letter from Anchorage RE questions about shadow/shadowed functionality

- To: <support@gesn.com>
- Subject: Letter from Anchorage RE questions about shadow/shadowed functionality
- From: "Tyler" <tyler@gesn.com>
- Date: Fri, 28 Jan 2000 10:02:09 -0600

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: Jurisdiction wide = Areawide: Means a race or proposition that everybody votes on and for which there is only one tally. Service area: Means a race or proposition that only persons within a certain geographic area vote on. The term could also be used to refer to Assembly districts and limited road service area races and propositions. Non-service area: Means…..We're not sure. We don't think we would have an occasion to use this since votes cast by people who are outside a particular service area would be tallied in the jurisdiction wide/areawide column. It's unclear what this category was designed to accommodate. Shadow race: Means a jurisdiction wide/areawide race or proposition that has a service area vote tally subset companion. Shadowed race: Means a jurisdiction wide/areawide race or proposition for which votes are tallied in a service area and is linked to a shadow race. Shadow/shadowed = Areawide/service area: Means a race or proposition for which votes are tallied in the jurisdiction wide/areawide column and also in the service area column. 2. Understanding of Mechanics: The Shadow controls the shadowed race or proposition so that once the link is made, the counting instructions follow along with the jurisdiction wide/areawide race or proposition, regardless of how the layout is manipulated. Vote tallies for the shadow race or proposition are jurisdiction wide/areawide and include the subset tally of votes in the shadowed race. Vote tallies for the shadowed race are the subset of votes cast in a service area. The system will generate ballot artwork and set up counting criteria so that votes on a given race or proposition can be tallied in the jurisdiction wide/areawide column only as well as "double counted" in the jurisdiction/areawide column and service area column. For example if 50 votes are cast in a shadow race and 25 of those votes are cast on ballots with the shadowed race the vote tally would read: Jurisdiction wide/areawide - 50 votes. Service area votes: 25. 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

- Follow-Ups:
  - RE: Letter from Anchorage RE questions about shadow/shadowed functionality
    - From: "Ken Clark" <ken@gesn.com>

- Prev by Date: Versions
- Next by Date: Re: Versions
- Index(es):
  - Chronological
  - Thread