Modify standard to generalize application request fields as voter record activity fields

[jungshadow]

Issue

The current version of the standard largely models a traditional absentee ballot process as the beginning of the process typically starts with a formal ballot request. While an all-mail state may receive a ballot request form of some kind (e.g. FPCA), data categorization is difficult for all-mail states as UOCAVA protections may be provided via an alternative means such as a voter record change (e.g. a mailing address change to an international address or change in military status).

Potential solution

In regards to the initial voter transaction—the ballot request or voter activity—the data standard is looking to track a few things:

• When were UOCAVA protections assessed (i.e. process dates)
• Were the UOCAVA protections accepted
• How were they put into place (e.g. was it through state application or FPCA)
• Through what method was the activity received (e.g. online, phone, fax)

In traditional absentee states, the receipt of a ballot request involves a kind of a voter record activity, which is analogous to all-mail states. If we change the names of most of the existing fields, delete the ones that assume policy (i.e. rejecting ballot requests). Some of the proposed field name changes

Original field name	New field name
ApplicationRequestMethod	VoterRecordActivityMethod
ApplicationRequestOtherMethod	VoterRecordActivityOtherMethod
ApplicationRequestPostmarkDate	<< deleted >>
ApplicationRequestProcessedDate	VoterRecordActivityProcessedDate
ApplicationRequestRejectionType and ApplicationRequestStatusType	VoterRecordActivityStatusType
ApplicationRequestRejectionOtherType	<< deleted >>
<< none >>	VoterRecordActivityStatusOtherType
ApplicationRequestType	VoterRecordActivityType

Some of the field definitions would also have to be updated to match the new model, but, before that, there needs to be general agreement on the rationale above and this approach.

[JDziurlaj]

@jungshadow, at first glance, this approach appears workable. Some thoughts:

• VoterRecordActivityType enumeration list may need to be expanded to support additional types of applications.
• It will need to be made clear what kind of VoterRecordActivity we are trying to capture, i.e. what kind of voter record activity qualifies, in the documentation.
• I might simplify the prefix to VoterActivity to emphasize that the activity comes from the voter, rather than the system.
• I don't see the need to delete ApplicationRequestPostmarkDate or ApplicationRequestRejectionType, unless this change was desired for other, unenumerated reasons.

[jungshadow]

Thanks, @JDziurlaj! Some additional thoughts:

VoterRecordActivityType enumeration list may need to be expanded to support additional types of applications.

Sure. What were you thinking?

It will need to be made clear what kind of VoterRecordActivity we are trying to capture, i.e. what kind of voter record activity qualifies, in the documentation.

Hmm...true. In our case, we're looking at new registrations, registration updates, and absentee ballot requests. I know that "registration updates" is vague (and could potentially encapsulate "absentee ballot requests"), but I'm not sure what the granularity of the data is at this point.

I might simplify the prefix to VoterActivity to emphasize that the activity comes from the voter, rather than the system.

Is this true in all cases (i.e. it's the voter and not the system)? Sounds right...I'm just thinking out loud to see if we come up with any edge cases.

I don't see the need to delete ApplicationRequestPostmarkDate or ApplicationRequestRejectionType, unless this change was desired for other, unenumerated reasons.

ApplicationRequestPostmarkDate was nixed due to no one collecting the information (NB: process-wise, it's pretty tough). ApplicationRequestRejectionType was applying policy where there may have been none (i.e. many jurisdictions don't reject ballot requests, so the term is incorrect in those cases).

[jungshadow]

I'm in favor of closing this to keep the working discussion in #32. What say you, @JDziurlaj?

[JDziurlaj]

Issue continued as #32.