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
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
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.
From Slack:
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.
The text was updated successfully, but these errors were encountered: