Various voter services are handled by different local offices at the locality level

[jungshadow]

Even after many years in elections, there's always something new to discover :) Just had a conversation with Alabama. Some voter services are run by different entities and sometimes in separate buildings. For example:

• The Probate Judge is the chief election official in the county who deals with the polling places, ballots, and running the election;
• The Board of Registrars, typically 3 or 4 member board, handles voter registration
• The Absentee Election Manager handles all absentee ballots

Currently, VIP can surface information on an the election official and an "overseas vote contact" (the latter probably inaccurately named), but they all link to a single physical address. Even with this model, we still couldn't present a contact for registration information (NB: many of these entities lack websites or online services).

Clearly, it would be ideal if we could route people to one contact, but, in this case, this is just going to add administrative overhead on the official who has to redirect voters and this will probably frustrate the voter. I'd welcome some thoughts on how to approach this.

[cjerdonek]

@jungshadow Based on your description, to address cases where the entities are completely different, it seems like it would make sense to have an object type corresponding to "entity responsible for some class of voter services," and then have the spec allow including more than one such object per jurisdiction. The object type could have a free text field describing what they are responsible for (or perhaps an enum, but there you run into having to know the possible descriptions / combinations in advance, which is probably impossible). Something like that seems potentially straightforward.

The other use case I can think of is if a single Department or organization is responsible for all of the voter services, but they might want to route types of requests to certain parts of the organization (e.g. a specific person or phone number, etc). For example, the SF Department of Elections has a list here of several phone numbers, e.g.

For questions about voter registration and vote-by-mail voting,
(415) 554-4411
For Voter Information Pamphlets,
(415) 554-4375
For information about becoming an Elections Officer (Pollworker),
(415) 554-4395
For information about candidates or campaign disclosure reports,
(415) 554-4375
For election results on Election Night,
(415) 554-4375
or this website
For a free workshop regarding current election information,
(415) 554-6184
For information about polling places and ADA issues,
(415) 554-4551

To address this case, it seems like a simple list of entities might not completely suffice (because you would want the information to reflect that these are all parts of a single entity, so there might be some additional relationships to capture).

The above example also illustrates why a free form field is probably necessary (specifically, "For a free workshop regarding current election information" for one).

[djbridges]

This disaggregated responsibility (as well as inconsistency in
responsibility assignments even intra-state) is true in many instances -
Texas, Georgia, and New Jersey come to mind immediately. An enum might work
for grouping responsibilities into broad buckets, but there definitely will
need to be a free text component to deal with all of the horrifying & ever
changing variations of responsibility.

Here's a fun flowchart for figuring out who is in charge of your voter
registration administrator in New Jersey. N.b. that this is only for the
administrator in charge voter reg, not for absentee voting, polling place,
etc.

[image: Inline image 1]

[cjerdonek]

@djbridges Your image didn't go through. You should be able to post it on the website though..

[djbridges]

Whoops - once more, with feeling:

[jungshadow]

@cjerdonek Not to go too far down the speculative rabbit hole, but wouldn't it be easier on both sides (i.e. voter and admin) to have a single number and an automated menu? I don't know a whole lot about the cost of automating phone lines, but I imagine shops like Twilio are making it cheaper/easier. With such a variance of options and granularity, I'm not sure how to break those numbers down into something that might translate easily across state lines. Though, it does bring up a good point: there is no phone number of any kind on election_administration

That aside, I think your idea is pretty solid. I'm wondering if it would be worthwhile to define an "abstract" ElectionAdministration model and implement PrimaryElectionAdmin, AbsenteeElectionAdmin, RegistrationElectionAdmin, and possibly include an OtherElectionAdmin as a catchall. I imagine those are the most popular and we can start gathering data on anything that falls into the catchall. Locality and state would have to accept more than one ElectionAdmin element and only one of each kind (though it may make sense to allow an unbounded number of "Others"). It may just be easier to implement an enumeration on the election_administration element, but I feel like there may be utility in making the elements more descriptive and generalizing the categories.

@djbridges Thanks for making our lives more complicated ;) Actually, it is good to know that this happens elsewhere.

Currently, on election_administration, there is an element to capture voter services:

<xs:element minOccurs="0" name="voter_services" type="xs:string" />

This should allow us to gather data on the "Other" part of the spectrum and hopefully refine the categories.

Here's the depressing part of this entire thing...I have a sinking feeling that, while the services have been broken out among multiple offices, none of this data is stored in an accessible database or only one of the offices is captured.

I hope I'm just plain wrong.

[pkoms]

@cjerdonek your case about routing different pieces of the office's work to different contacts is accurate: last time I checked, Montgomery County, MD has three different PO Boxes for different kinds of mail, and some SC counties use different phone numbers or different email addresses for different questions. And these are both states that otherwise have only single election offices.

@jungshadow many of the states that have this problem also don't work with VIP or don't provide election admin data. New Jersey does, and they currently only provide one admin / county. I wouldn't put my money on this data being stored in databases.

How does your suggestion above handle cases where (for example) one office is responsible for both absentee voting and registration, and another is responsible for polling places and poll workers? Would you just define the AbsenteeElectionAdmin and the RegistrationElectionAdmin to be identical? That seems inelegant.

[jungshadow]

@pkoms I'm all ears for your suggestion ;)

[pkoms]

It's not pretty, and only a notch more DRY, but since you asked....

Create a new election_administration object for every relevant office. Link them all to the state or locality as appropriate.

Move almost all contact information and voter_services into election_official. Add a new election_official to election_administration for every appropriate set of contact information, so if the office has one email and two phone numbers, each election_official would have the same email and different phone_numbers.

Then, enumerate the contents of voter_services, and use the presence of voter_services in election_official objects to tell users what contact information to associate with which activities. We can expand the enumeration as we learn more about the space of options.

[pstenbjorn]

@jungshadow some states do maintain lists of voter services offices in state VR systems, some do not. I think @pkoms suggestion has some merit.

See below for a sample of what I think @pkoms (and @jungshadow) are recommending.

        <xs:element name="locality">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="name" type="xs:string" />
              <xs:element name="state_id" type="xs:string" />
              <xs:element name="type" type="xs:string" />
              <xs:element minOccurs="0" maxOccurs="unbounded" name="election_administration_id" type="xs:string" />
              <xs:element minOccurs="0" maxOccurs="unbounded" name="polling_location_id" type="xs:string" />
              <xs:element minOccurs="0" maxOccurs="unbounded" name="external_identifier_id" type="xs:string" />
            </xs:sequence>
            <xs:attribute name="id" type="xs:string" use="required" />
          </xs:complexType>
        </xs:element><xs:element name="election_administration">
          <xs:complexType>
            <xs:all>
              <xs:element minOccurs="0" name="name" type="xs:string" />
              <xs:element minOccurs="0" name="eo_id" type="xs:string" />
              <xs:element minOccurs="0" name="ovc_id" type="xs:string" />
              <xs:element minOccurs="0" name="elections_url" type="xs:string" />
              <xs:element minOccurs="0" name="registration_url" type="xs:string" />
              <xs:element minOccurs="0" name="am_i_registered_url" type="xs:string" />
              <xs:element minOccurs="0" name="absentee_url" type="xs:string" />
              <xs:element minOccurs="0" name="where_do_i_vote_url" type="xs:string" />
              <xs:element minOccurs="0" name="what_is_on_my_ballot_url" type="xs:string" />
              <xs:element minOccurs="0" name="rules_url" type="xs:string" />
            </xs:all>
            <xs:attribute name="id" type="xs:string" use="required" />
          </xs:complexType>
        </xs:element>
        <xs:element name="election_official">
          <xs:complexType>
            <xs:all>
              <xs:element name="name" type="xs:string" />
              <xs:element minOccurs="0" name="title" type="xs:string" />
              <xs:element minOccurs="0" name="phone" type="xs:string" />
              <xs:element minOccurs="0" name="fax" type="xs:string" />
              <xs:element minOccurs="0" name="email" type="xs:string" />
              <xs:element minOccurs="0" name="physical_address" type="simpleAddressType" />
              <xs:element minOccurs="0" name="mailing_address" type="simpleAddressType" />
              <xs:element minOccurs="0" name="voter_services" type="voterServices" />
              <xs:element minOccurs="0" name="hours" type="xs:string" />
            </xs:all>
            <xs:attribute name="id" type="xs:string" use="required" />
          </xs:complexType>
        </xs:element>

    <xs:simpleType name="voterServices">
        <xs:restriction base="xs:string">
          <xs:enumeration value="PrimaryElectionAdmin"/>
          <xs:enumeration value="AbsenteeElectionAdmin"/>
          <xs:enumeration value="RegistrationElectionAdmin"/>
          <xs:enumeration value="OtherElectionAdmin"/>
        </xs:restriction>
    </xs:simpleType>

[cjerdonek]

Here is an idea I had a few days ago for how to represent multiple points of contact that might differ only in a phone number, room number and/or contact person name, etc (any combination basically).

Define a "contact information" object that has all the usual fields you are interested in, including ID. Then also add a field called something like parent_contact_information_id. The idea here would be that the contact information object inherits all the properties from the parent. So you would only need to specify the information that's different.

The tricky thing this addresses is not knowing in advance how points of contact can differ from one another.

Alternatively, to make this model a little less flexible but perhaps a little simpler (e.g. to avoid more than one level of nesting), one could define an "elections department" object (which may or may not already exist in the spec). The department object would have all the usual contact information fields. Then define a "contact information" object like above, but instead of a parent_contact_information_id field, it would have an elections_department_id field. A contact information instance would inherit all the info from the department, and you would only need to specify what's different.

[jdmgoogle]

I think this is a symptom of a larger issue where we still need to fully integrate the 1622.2 common elements (e.g., Person, Contact, etc) into the VIP schema. For example, the election_official object is really just a Person with some Contact elements. The election_administration object could use some similar cleaning up.

[jktomer]

+1 to jdmgoogle's comment; using a standard Person/Contact seems inherently valuable. election_official (election_office?) might need to subclass Person to add extra election-official-related properties.

If you want to have a voter_services enum for election administrators at all, +1 to pkoms's suggestion to move it into election official rather than election administration; in the common(?) case where a single office handles everything, this adds no pain, and in the case where there are multiple offices with independent, possibly-overlapping spheres of influence, it is required.

I would advocate against trying to enumerate voter services, though; the data seems too complicated to model properly for the dubious benefit (is it that valuable to know which of the two or three or six relevant offices one needs to call in order to become a poll watcher, to report problems with a poll watcher, to file campaign finance disclosure forms, to get copies of other people's filed campaign finance disclosure forms, to ask for an absentee ballot to be mailed to you, to report an absentee ballot lost in the mail, to ask about voter ID laws, ...?). I'm willing to be overruled on that, though.

[cjerdonek]

@jungshadow should this be closed?

[jungshadow]

As long as it works as advertised, yup :)

[cjerdonek]

Great!