Properly publish VxAggregator code and gauge whether Rochester wants to use it in November

[arsalansufi]

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.

[benadida]

This is complicated by the realization that maybe we should treat each ward as a separate election, after discussion with SoS

[arsalansufi]

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.