Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use vendor defined candidate list when available to auto-load candidates #865

Open
chughes297 opened this issue Jul 3, 2024 · 8 comments
Labels

Comments

@chughes297
Copy link
Collaborator

chughes297 commented Jul 3, 2024

Right now the candidate auto-load feature relies on reading in the whole CVR to generate its list of candidates. This can be time consuming for large, verbose CVRs (like those from Dominion) and won't necessarily capture all candidates (if, say, a candidate received no rankings in an election and therefore does not appear in the CVR data).

At least some CVRs (Dominion, Hart) lay out each of the candidates explicitly somewhere in the CVR. Finding and reading that file should be much faster and more accurate than reading in their whole CVR. Here is a list of vendors and, if known, where to find this data

Dominion: CandidateManifest.json
Hart: Unknown
ES&S: Unknown
ClearBallot: Unknown

Open Questions

@yezr
Copy link
Collaborator

yezr commented Jul 3, 2024

@chughes297 for either Dominion or Hart, if you already know explicitly where the candidate list is will you add that detail into this ticket?

@chughes297
Copy link
Collaborator Author

chughes297 commented Jul 3, 2024

I don't know for Hart, but in Dominion this is always in the CandidateManifest.csv/.json file.

@artoonie
Copy link
Collaborator

artoonie commented Jul 3, 2024

The Dominion reader already does this.

For Hart, there's no separate file with candidate names, but we can make auto-load load their names into the GUI instead of the ID.

@yezr
Copy link
Collaborator

yezr commented Jul 3, 2024

Can you elaborate on the second ask here: the candidate/alias file upload. With 2.0 we have an enhanced "Manually Add Candidate" section that I think provides near equal performance vs. what it would take for a user to manually create this file outside of the app. What format of file are you thinking?

The main benefit I could see is if we could upload directly the file that is automatically created by the vendor system, like the Dominion CandidateManifest.json. Which, in that case, we should just do it automatically when reading CVRs.

@chughes297
Copy link
Collaborator Author

chughes297 commented Jul 3, 2024

The Dominion reader already does this.

For Hart, there's no separate file with candidate names, but we can make auto-load load their names into the GUI instead of the ID.

When I ran some Dominion data through the most recent version of 1.3.999 that I have, it just reviewed the whole CVR and did not grab candidate names from the candidatemanifest file. Is this a newer thing in some later version of 1.3.999?

@chughes297
Copy link
Collaborator Author

Can you elaborate on the second ask here: the candidate/alias file upload. With 2.0 we have an enhanced "Manually Add Candidate" section that I think provides near equal performance vs. what it would take for a user to manually create this file outside of the app. What format of file are you thinking?

The main benefit I could see is if we could upload directly the file that is automatically created by the vendor system, like the Dominion CandidateManifest.json. Which, in that case, we should just do it automatically when reading CVRs.

Right now I find entering candidate name/code data by reviewing the candidatemanifest.json or whatever other file and then typing it into the interface pretty clunky. I can't think of a way to make this less clunky, though, which is why I'm thinking about the ability to upload a file. Making that file probably would be just as clunky, though, unless you can just export a candidate manifest type of file from each vendor. So maybe the best thing to do is suggest to people that they have an easy reference sheet or file to use when if they're manually typing data into the candidates tab...

@yezr
Copy link
Collaborator

yezr commented Jul 3, 2024

Got it. I'm going to prune that from this ticket, and if we find after implementing auto-load from the vendor files that it is still too cumbersome we can revisit that part.

@yezr yezr changed the title Use a CVR's candidate file or allow user to upload a candidate names/codes file for candidate auto-load When vendor has a defined candidate list use that to auto-populate candidates instead of reading through every CVR Jul 3, 2024
@yezr yezr changed the title When vendor has a defined candidate list use that to auto-populate candidates instead of reading through every CVR When vendor has a defined candidate list use that to auto-load candidate list to avoid reading through every CVR Jul 3, 2024
@yezr yezr added the WIP label Jul 3, 2024
@yezr yezr changed the title When vendor has a defined candidate list use that to auto-load candidate list to avoid reading through every CVR Use vendor defined candidate list when available to auto-load candidate list Jul 3, 2024
@yezr yezr changed the title Use vendor defined candidate list when available to auto-load candidate list Use vendor defined candidate list when available to auto-load candidates Jul 3, 2024
@artoonie
Copy link
Collaborator

artoonie commented Jul 3, 2024

The Dominion reader already does this.
For Hart, there's no separate file with candidate names, but we can make auto-load load their names into the GUI instead of the ID.

When I ran some Dominion data through the most recent version of 1.3.999 that I have, it just reviewed the whole CVR and did not grab candidate names from the candidatemanifest file. Is this a newer thing in some later version of 1.3.999?

Apologies, you're right: it does read the candidate list, but it also reads the entire CVR to see if there are any candidates that are not included in the list. I can make it skip the second phase and only look at the CandidateManifest file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

3 participants