csg-org / esb-data-standard

EAVS Section B Data Standard
https://eavs-section-b-data-standard.readthedocs.io/en/latest/
2 stars 1 forks source link

Move to Voter Activity Model #32

Closed JDziurlaj closed 4 years ago

JDziurlaj commented 4 years ago

Make the following changes to the esb tableschema, including relevent updates to the embedded documentation (description).

jungshadow commented 4 years ago

A few things here:

Thoughts, @JDziurlaj?

JDziurlaj commented 4 years ago

One of the issues is that the terminology VoterActivityX implies the activity qualifies as "Voter Activity", if that's true, it doesn't make sense to reject it. However, if we label the fields as plain old Activity, then we can conditionally add the qualifier Voter (i.e. activity we care about). So perhaps:

Rename all fields from VoterActivityX to ActivityX Rename VoterActivityStatusType to VoterActivityQualificationStatusType Rename VoterActivityStatusRejectedType to VoterActivityDisqualificationType

VoterActivityQualificationStatusType would determine if the Activity is also Voter Activity, and probably change the enumeration values to qualified, disqualified (unqualified?)

jungshadow commented 4 years ago

@JDziurlaj I think this shows promise. I'm a little unclear on one thing though: are these scenarios or are thinking all of these should happen?

@ctice5, @david-varas what do you think?

JDziurlaj commented 4 years ago

@jungshadow I think these changes make sense as a package. Here is an example definition:

VoterActivityQualificationStatusType

Specifies whether the activity represented by the transaction qualifies as UOCAVA voter activity. Possible values are disqualified, pending, qualified, and other.

CMHockenberry commented 4 years ago

I think it makes sense and allows us to be more agnostic because (correct me if I'm wrong) that UOCAVA Flag date would only be appearing in all mail systems as opposed to traditional. My question is as to Pending under qualification status. Wouldn't that be similar to the cured issue we discussed previously?

JDziurlaj commented 4 years ago

Changing several of the fields from ApplicationRequest to VoterActivity has not been the most straightforward process. A lot of this comes down to the clumsy prose that must be written when things are put in terms of activity instead request. My understanding is this change was made to better comport with the way all-mail states operate. However, I think a side effect will be confusion for non-all-mail states, as voter activity usually has a different, particular meaning related to list maintenance (NVRA). I propose a compromise. We would rename ApplicationRequest to Request (or even VoterRequest). This makes the language a bit more inclusive, but still keeps things in terms of cause (request), rather than effect (activity).

jungshadow commented 4 years ago

@JDziurlaj I think I'm in favor of this. Can you provide a rough outline of the changes (kinda like the mapping I did in #25)?

JDziurlaj commented 4 years ago
Original field name New field name
ApplicationRequestMethod RequestMethod
ApplicationRequestOtherMethod RequestOtherMethod
ApplicationRequestPostmarkDate (deleted)
ApplicationRequestProcessedDate RequestDate
ApplicationRequestReceivedDate (deleted)
ApplicationRequestRejectionType RequestStatusType
(new) RequestStatusRejectedType
ApplicationRequestRejectionOtherType RequestStatusOtherType
ApplicationRequestStatusType (deleted)
ApplicationRequestType RequestType
jungshadow commented 4 years ago

This LGTM. @ctice5, @david-varas what do you think?

My question is as to Pending under qualification status. Wouldn't that be similar to the cured issue we discussed previously?

@ctice5, I think we could see pending qualifications, but we wouldn't see cured as that isn't tracked (as far as I can tell).

CMHockenberry commented 4 years ago

@jungshadow Ok, but how do they track that in their system? So if someone verifies the information would the voter have two entries, one that says pending and one that says qualified or do they have one singular entry that they flip to qualified? Are we also tracking why it was pending?

Are there some states that don't leave you as pending but instead disqualify you, but notify you that you of what needs to be done to qualify?-->This I assume is something that David would want to know to determine the successfulness of FWAB (aka is it too hard to use so people are getting disqualified and not bothering to try again)

Am I making any sense?

jungshadow commented 4 years ago

Ok, but how do they track that in their system? So if someone verifies the information would the voter have two entries, one that says pending and one that says qualified or do they have one singular entry that they flip to qualified? Are we also tracking why it was pending?

I'm unaware of the underlying process as to how it's being tracked, but my understanding from the conversations we've had is that an FPCA might be in a pending state due to missing information, but, when an FPCA is cured, it overwrites the original pending record, so we wouldn't know what transactions flipped from pending to qualified (NB: assuming pending and qualified are the enumerations we pick). We'd just see the qualified transactions.

Are there some states that don't leave you as pending but instead disqualify you, but notify you that you of what needs to be done to qualify?

Yes. Those are what the previous standard captured in some places. There are rejected FPCAs. FWABs can also be ballots and registrations so that example gets a little hairy.

Am I making any sense?

Nope 😉 (Of course you are)