Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential to support IsVoterRegistrationSite tag in future specifications for PollingLocation element #411

Open
robertandremitchell opened this issue Mar 12, 2021 · 3 comments

Comments

@robertandremitchell
Copy link

In conversations with two states, there was a stated desire to be able to support/flag when there were polling locations or early vote sites where voters could register to vote. I see this as a great value-add to the PollingLocation element of the specification, particularly as more states adopt same-day registration as well as early voting centers that are intended to serve as one-stop entry points for voters.

One option for achieving this would to add a IsVoterRegistrationSite tag to PollingLocation in a future spec.

Another option would be finding a way to link VoterService elements to PollingLocation. This might help if there are other voter services that should be similarly flagged. As of now, VoterService can only be linked to ElectionAdministration. This might then allow for states to provide custom messages as well, if there are rules/requirements/IDs necessary in the Description tag of VoterService.

Open to thinking of this in other ways, but it could be valuable.

@afsmythe
Copy link

afsmythe commented May 26, 2021

I like the option of extending VoterService to PollingLocation. The specification already handles a registration voter service via the VoterService.VoterServiceType = "voter-registration". There may be some disconnect between the original intention of VoterService (per the docs, it seems to be for identifying what services an ElectionAdministration object has control over), but if those services are offered at a voting location (in addition to an elections office) then the disconnect may not be so wide.

I believe the changes needed to extend VoterService to PollingLocation are:

  • In vip_spec.xsd add a line item to PollingLocation for the VoterService object (the actual specification update)
<xs:complexType name="PollingLocation">
  <..>
  <xs:element name="VoterService" minOccurs="0" maxOccurs="unbounded">
  <..>
  • In polling_location.yaml add "VoterService" to the extends section (the update to the documentation)
<..>
extends:
- LatLng
- SimpleAddressType
- VoterService
<..>

EDIT: for the YAML update, we might instead need VoterService to be defined as a SubType of PollingLocation, rather than an extending element.

@afsmythe afsmythe added this to the Up for Debate milestone May 26, 2021
@jswiesner
Copy link
Collaborator

I like the idea of repurposing VoterService to the PollingLocation element, but when I look at the VoterServiceType enumeration, none of the other types aside from "voter-registration" seem relevant to a polling location. Before opting for this approach, I think it would be good to have some clear, plausible extensions for its usage in the future. Are there any other use cases you have in mind where a VoterService element could be relevant to a PollingLocation?

@afsmythe
Copy link

afsmythe commented Jun 9, 2021

There's been some discussion this past week about another open Issue #359 and we are hoping to gather feedback over the summer from states and accessibility rights groups about further details.

As an example, in 2020 we had a few requests from states about adding in details about "voter services" such as shuttles (from a parking lot to a voting location), ADA compliance and others.

So I think we're considering using an expanded VoterServices enumeration to handle some of these for 6.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants