You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
core functionality for this project is being able to work through a queue of adjudication issues (overvote, marginal mark, etc.). To be able to filter for these ballots and contests quickly, I think they're going to need to be cataloged and tagged on import in some way. It won't be efficient enough to essentially re-tabulate all CVRs whenever you want to adjudicate them
an implementation idea starting point - on import, the contests on every ballot are analyzed for all possible adjudication reasons:
overvote
undervote
marginal marks
write-in
for each contest, we create an entry in a needs_adjudication column that has flags for each of those reasons. we can easily search based on issue and contest ID and join to the CVR table for more advanced filtering.
that table could also track the status of the contest as "unresolved" or "resolved." to simplify the project, let's say that if a contest is resolved for one issue, it is resolved for all issues, and set the UX up accordingly. for example, if you started by adjudicating overvotes and you hit a contest with a write-in, the UX gently forces you to resolve the write-in too. this greatly simplifies the resolved vs. unresolved tracking and avoids complexity that emerges when people resolve different issues in different orders.
The text was updated successfully, but these errors were encountered:
adghayes
changed the title
build infrastructure for tagging and filtering contest adjudication issues
VxAdmin: build infrastructure for tagging and filtering contest adjudication issues
Dec 20, 2024
core functionality for this project is being able to work through a queue of adjudication issues (overvote, marginal mark, etc.). To be able to filter for these ballots and contests quickly, I think they're going to need to be cataloged and tagged on import in some way. It won't be efficient enough to essentially re-tabulate all CVRs whenever you want to adjudicate them
an implementation idea starting point - on import, the contests on every ballot are analyzed for all possible adjudication reasons:
for each contest, we create an entry in a needs_adjudication column that has flags for each of those reasons. we can easily search based on issue and contest ID and join to the CVR table for more advanced filtering.
that table could also track the status of the contest as "unresolved" or "resolved." to simplify the project, let's say that if a contest is resolved for one issue, it is resolved for all issues, and set the UX up accordingly. for example, if you started by adjudicating overvotes and you hit a contest with a write-in, the UX gently forces you to resolve the write-in too. this greatly simplifies the resolved vs. unresolved tracking and avoids complexity that emerges when people resolve different issues in different orders.
The text was updated successfully, but these errors were encountered: