Write in candidates must be known in advance, PlaintextBallot.ExtendedData unneeded. #229
JohnLCaron
started this conversation in
General
Replies: 2 comments
-
write-in is a tricky subject well beyond the scope of this request. for purposes of SDK support, each write-in should be treated as its own unique candidate; if the system has additional information to store about the write-in candidate generated by the voter, it should be stored in the extended metadata field. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I just mean to point out that the current library assumes that any candidates to tally already exist in the Manifest, including write-in candidates. So, perhaps a topic for 2.0 to handle write-ins differently? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Currently its assumed that all write in Candidates are known in advance. ExtendedData has "indicate a write-in candidate text value" which is redundant if an actual Candidate record exists.
If all write in candidates have to be in the Manifest, then the Manifest cant be finalized until all ballots are read.
Each independent processor can then have a different Manifest, unless all ballots are read globally.
I dont see how thats scalable to large number of independent tallies.
I suppose some elections require write in candidate to register themselves if they want to be counted?
Can ballot scanners actually read write-in candidate names?
Ok, so lets stick with all write in Candidates are known in advance. Then ExtendedData is unneeded.
Beta Was this translation helpful? Give feedback.
All reactions