Add IsMailOnly flag to State, Locality objects

[afsmythe]

More and more States and Counties are and will be offering vote by mail (VBM) options for voters. Right now, the specification requires a VBM state or county to specify the flag on the Precinct level, but for States like Hawaii and Utah (100% VBM) and other states which have a portion of their Counties holding VBM elections (Nebraska, North Dakota) it would be simpler for the VIP spec to allow the IsMailOnly flag to be assigned to a top level, the State or the Locality object.

source: https://voteathome.org

[jungshadow]

@afsmythe This sounds good/efficient, but I'm a bit worried about the danger of the flag being set at a high level and it overriding counties that still have some additional in-person methods of voting (e.g. King County, WA). As long as there's some sort of validation check for this scenario (e.g. a feed that has polling location elements populated with no IsDropBox flag), this seems fine.

A few other things come to mind:

• What do you do if there are conflicts between the state and local elements?
• Does the state element override the local or vice versa? Or is the entire feed invalid?

[jdmgoogle]

I generally like the proposal, @afsmythe, but definitely would like to hear your thoughts on @jungshadow's questions.

[afsmythe]

Thanks for the feedback! Some comments below:

I'm a bit worried about the danger of the flag being set at a high level and it overriding counties that still have some additional in-person methods of voting (e.g. King County, WA)

Presently, the Voting Information Tools will display information specific to vote by mail when it is available in addition to what is otherwise available to the voter address. So, if a particular user is in a vote by mail jurisdiction and they also have access to in person voting or drop off locations, then they would be notified by VIP tools they can mail in their ballot or visit one of the locations returned to them in the tools. I don't see any complication with this scenario if the IsMailOnly flag were assigned to either Locality or the State record.

What do you do if there are conflicts between the state and local elements?

I think the parent record (from State > Locality > Precinct) should take precedence and it would be a responsibility of the data providers to ensure correctness, e.g. if not all counties in a particular state have VBM, then the State.IsMailOnly flag should be set to 'false' and each Locality.IsMailOnly record would be set appropriately. This could be simple validation to provide to VIP States in the Dashboard, for example.

Does the state element override the local or vice versa? Or is the entire feed invalid?

See above. Is there any potential complication with that way of thinking?

[jungshadow]

I don't see any complication with this scenario if the IsMailOnly flag were assigned to either Locality or the State record.

My concern is really on the non-VIP interpretation. The name of the field is IsMailOnly, which, to me, sounds like "this is the only way we vote." How would this be surfaced in the API and how would consumers interpret it?

I think the parent record (from State > Locality > Precinct) should take precedence and it would be a responsibility of the data providers to ensure correctness...

Well you had me until there :wink: In all seriousness, my concern here is twofold:

1. Decentralized data ownership—even if centrally aggregated—might cause problems. Would states feel empowered to change data coming from a local system?
2. The election officials are (always) under massive strain. Would a validation in the dashboard be clear enough?

I'm not saying it's a showstopper, but you're basically highlighting policy within the spec/API/tools/etc... It's hard to get it right and tends to make a lot of people unhappy if it's wrong.

[jdmgoogle]

Good point about data ownership.

Counter-proposal: add this to the Locality element, but not the State. Localities are responsible for knowing:

• if a precinct is mail-only
• if they have decided to go to mail-only
• if their state has implemented mail-only (as they are executing it)

It does result in a slightly duplicated amount of information, but at least (hopefully) this should work cleanly for both state-created and state-aggregated feeds.

Thoughts?

[jungshadow]

Largely it sounds good and is kind of where I was thinking it would go. So I'm understanding how this is modeled, if a state/locality has some form of multi-modal voting—e.g. VBM and vote centers—would the IsMailOnly flag be false? Depending on the answer, there would still have to be a few validations to catch the inappropriate configurations, such as localities with IsMailOnly set to true with polling locations (not drop boxes) and localities with IsMailOnly set to false without polling locations.

[jdmgoogle]

That is correct. I believe the IsMailOnly is true if that is actually the only option for that locality. The only caveat I can think of is if a state/locality has set up drop boxes to collect mail ballots. If there is no in-person voting, but multiple channels one can use to return a mailed ballot, what are people's thoughts about modeling that as IsMailOnly = true?

[jungshadow]

As long as the IsDropBox element is set to true on the PollingLocation, I don't see that as in conflict with IsMailOnly being set to true. There is still no in-person voting (as I define/interpret it).

[afsmythe]

These are good points. I don't know how we'd handle the @jungshadow stipulation in the XSD, but we might include some wording in the documentation YAML on the Locality.IsMailOnly (eventually) and the Precinct.IsMailOnly such as:

If this field is set to true then all PollingLocation objects referenced by this [Locality, Precinct] object should be flagged as IsDropBox = true, otherwise the implementation is required to ignore the PollingLocation.

Or, we scrap the idea and continue only flagging IsMailOnly on the Precinct level :)

[jdmgoogle]

I don't think we can handle it completely in the XSD. It'll need to be managed/enforced via code, and we'll need feed creators to know how to implement this correctly.

[jungshadow]

What @jdmgoogle said. I was just trying to say it needs to be communicated to both sides: states with docs and validations; API docs for consumers.

[afsmythe]

Proposing that we include this update in the 5.2 release and limit the change to only Locality objects as @jdmgoogle suggests. If I don't hear any objection in a day then I'll make the milestone assignment and should have the documentation update ready shortly thereafter.

[jdmgoogle]

Sounds like we're aligned on this. Is there a PR that's forthcoming? If so, who's driving it?

[jdmgoogle]

Sorry, this is PR #403.

[afsmythe]

Correct! Sorry for that. Closing this issue now since the PR has been merged.