search

electorama / abif

The _Aggregated Ballot Information Format_ provides a concise, aggregated, text-based document to describe the ballots cast in range-based or ranked elections, as well as approval-based and choose-one balloting systems.
Other
4 stars 1 forks source link

ABIF implementations need to handle skipped rankings #35

Open nealmcb opened 9 months ago

nealmcb commented 9 months ago

I'm glad ABIF can handle equal rankings. But what about skipped rankings? When voters mark ballots, e.g. on a Dominion ballot, they are presented with a grid

   first    second    third  fourth
c1  _       _         _      _
c2  _       _         _      _
c3  _       _         _      _
c4  _       _         _      _

Different jurisdictions invalidate choices with different rules. E.g. in Alaska, two skipped rankings means further rankings are ignored. In Colorado, that happens with a single skipped ranking. I think we should support exact representations of such ballots so people can write software to process them according to the different rules.

I guess all that requires for ABIF is making it clear that the ">" sign can appear any number of times at the beginning of a list of preferences, or between preferences.

e.g. 42:>Memphis>>Nashville=Chattanooga for 42 voters who skipped the first preference and the third, and ranked Nashville and Chattanooga both in fourth place.

Is that already handled? Can it be?

robla commented 9 months ago

Interesting! I don't think there's a test case for skipped rankings, but there should be. Let's take the Tennessee example assume that voters skip a rank when they are over 150 miles away from the nearest remaining city: 

42:Memph>>Nash>Chat>Knox
26:Nash>Chat>>Knox>Memph
15:Chat>Knox>Nash>>Memph
17:Knox>Chat>>Nash>Memph

I think ">>" is a good way of expressing a skipped rank. It seems like we MAY want to have some way of making this more explicity (e.g. ">(null)>" or something like that, but I think that an empty "cand_id" (without "(null)" or whatever) should be acceptable for ABIF implementation, and it should mean "no candidate marking detected".

As for "handling exact representations of marked ballots", that's incredibly large rabbithole we could disappear down (e.g should we distinguish different types of "dangling chads"?). I'll consider issue #35 resolved when we properly handle skipped rankings on ranked ballots, and we may want to change the issue title accordingly.

nealmcb commented 9 months ago

Well put. I note that Dominion's json format includes mark density information for each oval, and I'm not talking about that level of representation either. I just mean a full representation of which ovals a voter intended to mark on their modern scanned ballot. Vs some other (older?) way to indicate rankings like writing numbers in, filling in arrows, or others I haven't thought of. New title ideas welcomed.