Closed vteague closed 4 months ago
The prototype has implementations of IRV sanity checking in CVRContestInfoJsonAdapter. This saves a lot of work and is worth redoing in the same way. Related also to CVRContestInfo addition of raw_choices.
Note: very important to consider this functionality in conjunction with creating "ACVRs".
A complexity is that the ranking on IRV votes in both cases, when parsed, will be in the format "Candidate A(1), Candidate B(2), ..." and so on. This allows us to check that the ranking is valid and apply interpretation rules (eg. in the case where two candidates have been ranked second). However, when creating the colorado-rla data structures relating to votes (eg. CVRContestInfo), the names in the ranking cannot be different from the candidate names in the associated Contest data structures (otherwise a validation error is produced). Ideally, we don't want to specify the candidate list of an IRV contest as "Candidate A(1), Candidate A(2) ..." and so on. So, for ACVRs, we need to do the interpretation of the "Candidate A(1), Candidate B(2), ..." style ranking before we create data structures like CVRContestInfo.
All true. The IRVChoices (PR #101 and #105) should do the parsing and the production of the right candidate list, in preference order. The IRV sanity checking (PR #104) should address the problem you mention above - a choice like Candidate A(1) should be accepted as valid if Candidate A is valid - but there could well be more gotchas in the parsing.
Expand the CSV parsing in DominionCVRExportParser to handle IRV ballots. This can possibly be done better than it was in the prototype, using the checks for IRV ballot choice/ contestSanityChecks implemented elsewhere.