usnistgov / VoterRecordsInterchange

Common data format specification for voter records interchange data
https://pages.nist.gov/VoterRecordsInterchange
Other
14 stars 2 forks source link

Need MailedBallotPrecinct status, qualification on poll location #4

Open carl3 opened 6 years ago

carl3 commented 6 years ago

Organization Name: Carl Hage

Organization Type: 4

Document: VoterRecordsInterchange

Reference: 3.1.6.18 The VoterRegistration Element, 3.1.6.12 The ReportingUnit Element

Comment: For a specific election, a precinct (split-precinct) could be assigned to use mail ballots only (while others have a poll location), or all precincts in an election might vote by mail (or use a dropoff location or vote center). This is independent of the <BallotReceiptPreference>. In the <VoterRecordsInterchange> a poll location (ReportingUnit) can be specified, but there is no way to indicate mail-ballot only for that voter in an election. Sometimes a message is stored as a fake address, but this is not machine readable, so an explicit machine-readable tag is needed.

Note the schema definition for <ReportingUnit> has a <Location> but the spec does not show this in the table above. The note at the <ElectionAdmininstration> definition, it says that it can be used in a <ReportingUnit> but the ReportingUnit xsd doesn't say that.

Is the intent with a VRI retreival to be able to include Poll Locations (the actual address)? <ContactInformation> is allowed in a ReportingUnit of SP1500-100 election results but not SP-1500-103. (A Location is allowed apparently, but Contact isn't.)

A number of online "VR/poll locator" look apps are in use-- a voter registration query form has name, birth date, and some other information (like street address or house number), then the voter registration status, poll location for an upcoming election, and sometimes district list is returned. SP1500-103 provides a basis for an interoperable API for these systems. Is that an intent?

Sometimes poll locations are To-Be-Determined. Rather than put in a fake address, it is better to qualify the address with a status. An enumerated type could be used. Also, an address might be present, but locations have not been finalized. When there is a last minute change, it could be useful to note that to highlight to a user there has been a change, e.g. from prior mailed information.

Suggested Change: Add <PollLocationStatus> to the members of <VoterRegistration>, a new enumerated type. (also applicable to a specified election date). Values could be not-in-election (for a selected date), mail-ballot-election, mail-ballot-precinct, not-yet-assigned, not-yet-final, final, changed (after it became final).

JDziurlaj commented 5 years ago

Will not be implemented for v1. Will leave open for future consideration.