Error? Counts should have a Status field

[sfsinger19103]

Currently the Count element has an optional Type field (datatype CountItemType), but no Status. This is problematic in an application trying to track the progress of the counts over time in the canvass, a subject of considerable interest to political scientists and the public.

Some solution options:

• include an optional Status field (datatype CountItemStatus) in the Count element
• include a CountStatus field in the Count element, and remove the Type field (because it's included in CountStatus

[JDziurlaj]

What are the possible values of this new Status attribute?

[sfsinger19103]

Values of Status would be chosen from the CountItemStatus enumeration. So it's not really new.

It might be cleaner to link the Count element to the CountStatus element that already exists .

[sfsinger19103]

If one of the solutions proposed above is adopted, it would be possible to remove the CountStatus field from the ReportingUnit element. I don't know all the uses of that field in that element, so I can't say definitively, but for my applications the CountStatus field in the ReportingUnit element introduced unnecessary complications.

And there's a logical problem with the CDF as is that would be solved by removing the CountStatus field from the ReportingUnit element: each Office has at most one ElectionDistrict. But if I'm using CountStatus, then a single Office could have several ElectionDistricts.

Concrete example: Here are two different ReportingUnits:

• 'Snyder County PA with completed count'
• 'Snyder County PA with count in progress'
  It doesn't make sense to choose either one as the sole ElectionDistrict for the Office 'Snyder County Commissioner'.

[JDziurlaj]

So is the goal to be able to store multiple versions of election results for a given type/reporting unit over a time period? I want to make sure I understand the use-case.

[sfsinger19103]

Yes, one goal is to store multiple versions of election results for a given type/reporting unit over a time period. Another use case is to handle a report where the counts of one type (say, election-day) have one status (say, ‘completed’) while counts of another type (say, ‘absentee-mail’) have another status (say, ‘in-process’). —Stephanie

…

On Apr 14, 2020, at 8:34 AM, John Dziurlaj ***@***.***> wrote: So is the goal to be able to store multiple versions of election results for a given type/reporting unit over a time period? I want to make sure I understand the use-case. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNQLHUICUKE3G5WR2MRK4LRMR7AVANCNFSM4LFFMFMA>.

[JDziurlaj]

My feeling is this addition does not fit within one of the existing use-cases of the Election Results Reporting CDF, which tend to be centered around activities of an election jurisdiction. That's not to say the use-case could not be added, but this change is breaking and would need to be considered for ERR vNext (3.0).

[raylutz]

I'm not certain but perhaps the issue of taking a snapshot at different periods of time could be simply handled by producing multiple reports as time passes.

[sfsinger19103]

“This change is breaking” sounds bad. What does it mean? What breaks? What’s the recommendation for handling the issue of each office having a single election district, in which one might want to combine completed election-day counts with in-progress absentee counts? That could happen in a single interim report, to give a complete-as-possible count.

[johnpwack]

Breaking here means that modifying the UML would result in a new schema that, if validating to it, would break existing implementations that need to validate to the previous schema. Thus it might be better to wait for a period of time before releasing a new version; during that period, other changes might arise and so forth. Given that one could produce multiple reports as time passes, and if I understand everything, my opinion is it would be better to wait.

I'm seeing the issue of having multiple types of counts associated with the office as straightforward to me, but I'll defer to John here.

[sfsinger19103]

Having multiple types of counts associated to an office is not a problem; having multiple election districts associated to an office *is* a problem. In the current CDF, the state of California with counts in progress is a different reporting unit from the state of California with counts completed. Which is the Election District for the Governor of California?

[sfsinger19103]

Thanks to a helpful conversation with @JDziurlaj , I think I understand an excellent reason for attaching the CountItemStatus to the ReportingUnit rather than the Count element: because the CountItemStatus is the same for all Selections, it is a wasteful of memory to keep the CountItemStatus with each Count rather than with an element that is independent of the Selection element. Makes sense. Follow-up question: doesn't the reasoning about CountItemStatus apply also to CountItemType? In other words, wouldn't it be less wasteful of memory to have a CountType field in the ReportingUnit element, rather than in the Count element?

[JDziurlaj]

The Counts::Type attribute ( of CountyItemType) is to associate a particular count with the reporting bucket it should be associated with. Since this data is about the particular count, it is not duplicative.

[sfsinger19103]

I still don't understand the logic that dictates treating CountItemStatus differently from CountItemType. It’s a reasonable choice to construe CountItemType as data about a particular Count; why isn’t it just as reasonable to construe CountItemStatus as data about a particular Count? Maybe I’m misunderstanding “duplicative”. All the many Counts from a single set of ballots of a particular type (e.g., absentee-mail) will all have the same CountItemType. So there are many VoteCounts of the same VoteType — at least one for each selection on the ballot. This is a duplication of data that could be avoided by adding a CountItemType [0..*] attribute to the ReportingUnit class. What advantage makes this duplication of data worthwhile?

[jdmgoogle]

Quick question: is this for V2 of the spec?

[sfsinger19103]

Yes, this is for V2 of the spec.

[jdmgoogle]

(This is probably overly long since I'm thinking "out loud" and maybe not directly addressing some of the questions since it's a long thread, so (a) apologies, and (b) please bear with me if I'm off-base...)

I thought there is a CountItemStatus and CountItemType on the ReportingUnit? There's a CountStatus which has both a status and a type. Contests also have a CountStatus.

The short answer (I think) is that the spec allows the representation of the data in multiple different ways. This is good for providers because it allows them to represent complex realities in ways that feel natural; it's challenging for consumers because of the same reasons. For example, let's say there's the following situation:

• Contests on the ballot include President, Governor (both statewide), and per-county sherrifs
• All counties are done counting (mail-in) absentee ballots
• Election night counting is in-progress everywhere
• Some counties have started counting provisional ballots
• There are some mail-in absentee ballots where the marks for President are being disputed
• There are no such issues (or at least no such challenges) being levied against the other contests

How should that be represented? E.g., should the state say that all mail-in absentee ballots state-wide are "in-progress" when only one contest is affected, and then each individual contest overrides the mail-in status? Or should the state say "completed" for state-wide mail-in absentee and only the Presidential contest overrides it?

As for the individual VoteCounts, they do have a CountType, and there are multiple VoteCounts associated with each BallotSelection. This is to enable multiple levels of reporting possible for a single selection (e.g., the number of early votes Trump/Pence got state-wide, the number of early votes they got in county X, the number of election day votes they got in county Y, etc. Each one of those doesn't also need a status since presumably the status for that type can be pulled from the GpUnit in the ID.

<!-- etc etc etc -->
<GpUnit xsd:type="ReportingUnit" objectId="pa-state">
  <Name>Snyder County</Name>
  <!-- The state considers everything to be "in progress"? Or should this be "completed"? -->
  <CountStatus>
    <Status>in-progress</Status>
    <Type>early</Type>
  </CountStatus>
  <CountStatus>
    <Status>in-progress</Status>
    <Type>election-day</Type>
  </CountStatus>
<GpUnit xsd:type="ReportingUnit" objectId="pa-snyder">
  <Name>Snyder County</Name>
  <!-- This county is done with early voting and election day is in-progress -->
  <CountStatus>
    <Status>completed</Status>
    <Type>early</Type>
  </CountStatus>
  <CountStatus>
    <Status>in-progress</Status>
    <Type>election-day</Type>
  </CountStatus>
</GpUnit>
<GpUnit xsd:type="ReportingUnit" objectId="pa-burke">
  <!-- This county is in-progress with everything -->
  <Name>Burke County</Name>
  <CountStatus>
    <Status>in-progress</Status>
    <Type>early</Type>
  </CountStatus>
  <CountStatus>
    <Status>in-progress</Status>
    <Type>election-day</Type>
  </CountStatus>
</GpUnit>
<!-- etc etc etc -->
<Contest xsd:type="CandidateContest" objectId="cc-pres">
  <BallotTitle>President of the United States</BallotTitle>
  <ElectionDistrictId>pa-state</ElectionDistrictId>
  <!--
  The count status could be optional. However, maybe there are disputed absentee opscan marks
  for this contest but not others. This version of the spec allows the state-level ReportingUnit
  object to say "in-progress" for absentee in general but the other contests (e.g., Governor) could
  tag their early vote counts as "completed".
  -->
  <CountStatus>
    <Status>in-progress</Status>
    <Type>early</Type>
  </CountStatus>
  <CountStatus>
    <Status>in-progress</Status>
    <Type>election-day</Type>
  </CountStatus>
  <!--
  Per-selection VoteCounts left as an exercise to the reader because I've been typing this up
  for 40 minutes already. :)
  -->
</Contest>