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