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

# Re: Ballots not invalidated when changing controlling shadow race

- To: <bugtrack@dieboldes.com>
- Subject: Re: Ballots not invalidated when changing controlling shadow race
- From: "Talbot Iredale" <tiredale@dieboldes.com>
- Date: Mon, 13 May 2002 12:04:45 -0700
- References: <000001c1d10c$d7b52430$2304a8c0@kclark>

Changing a Shadow race for a Shadowed race now invalidates the ballot. Note: You still will get the same Ballot Style and Card Style but the Card Rot will be different. This will be in GEMS 1-18-10. Tab ----- Original Message ----- From: Ken Clark To: bugtrack@dieboldes.com Sent: Thursday, March 21, 2002 12:16 PM Subject: Ballots not invalidated when changing controlling shadow race On behalf of Don Biz and the good people of Anchorage. Changing the shadow race of a shadowed dependent does not force ballots to be regenerated. What this means is memory cards downloaded will count results into the “wrong” (ie, previous) controlling race. Because they are shadow races there is no way to tell just by looking at the ballot that they are acting on the wrong oval positions. Only a thorough L&A will show the problem. We’ll fix this in GEMS 1.17.23 so that users are warned that the change will affect ballots, and clobber the ballots if they choose to proceed. Unfortunately the cure is almost worse than the disease. In Anchorage, they had two shadowed races which pointed at the incorrect shadow race. The problem was not caught until after ballots were printed. This meant that regenerating artwork was not an option, since it would have forced a change in card numbers for every card with those races. Development hacked the database to preserve as many existing cards as possible. It worked out okay in the wash as only 1 card running in 10 pcts need to be reprinted. This was pure luck – it could have been all of them with a different shadow configuration (like that used in California primaries). There are a couple of important lessons here. First, be very careful when setting up races controlled by other races. You can’t tell by “proofing” the ballots that the AccuVote will count the same way a sentient being who knows how the controlling race works. It needs to be told the correct controlling race. Straight Party, Preference, and Recall races have the same issues. With shadow race, you should always set up the database with headers that show the district or party that differentiates the shadow race. For split precincts, you can do this with the 1.18 @district macro, or attach a header to the shadowed race. At least then you can tell by looking at the ballot what district it is in, and have a fighting chance of identifying the mistake during proofing. Ken

- Prev by Date: Recalled Races discarded - unless it's the last race you vote on.
- Next by Date: Erroneous selection offered on 'Create voter card' screen.
- Index(es):
  - Chronological
  - Thread