votingworks
Properly publish VxAggregator code and gauge whether Rochester wants to use it in November
From Slack:
Tabitha and I debriefed this over the phone already but just documenting that Rochester is opting not to use our aggregator tool this go around. They’re still excited about it, but want to stick with their tried and true process this time and also want to get the aggregator tool properly approved by the state. They also want to be able to test it out first in a non-election context. Which all makes sense to me! On our end, we can properly publish the code on GitHub and button things up a bit
Code and usage instructions: https://docs.google.com/document/d/1FCSNW1gYW9fAiOc3eT8Yw1Hw43l9oh6UxnamYkTkAYQ/edit?usp=sharing
In our comms, we should also let Rochester know that we're going to build some solution for this into the v4 product.
This is complicated by the realization that maybe we should treat each ward as a separate election, after discussion with SoS
Yup good call out! Tabitha and I did demo the current solution to Rochester, noting that it's an intermediate solution with a laptop on loan that we wouldn't charge them for. And I noted that, long-term, our solution will look different. I didn't dive into the weeds of the separate election definition discussion yet. But Rochester was excited to use the current VxAggregator for the November general.
They also noted that, having seen that it's offline, they don't believe that they need to get approval from the state. The state really only cares about the ward-level results anyway. The aggregated results are more for city use than anything else.
Demoed to Rochester again, made edits in response to feedback, and trained Rochester for the general! Code is now published: https://github.com/votingworks/rochester-results-aggregator. And the documentation has been updated: https://docs.google.com/document/d/1FCSNW1gYW9fAiOc3eT8Yw1Hw43l9oh6UxnamYkTkAYQ/edit?usp=sharing