Closed JDziurlaj closed 4 years ago
A few things here:
UOCAVAFlagDate
and VoterActivityDate
should theoretically be the same thing. It largely comes down to naming convention. Do we want to explicitly call it out as UOCAVA-specific? Personally, I'd like to maintain how absentee-model-agnostic it is, but that may not be possible.VoterActivityStatusRejectedType
, VoterActivityStatusType
, and VoterActivityStatusOtherType
needs some additional thinking/reworking...which is largely my fault for it being a mess. Can you take a stab at that?Thoughts, @JDziurlaj?
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
?)
@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?
@jungshadow I think these changes make sense as a package. Here is an example definition:
Specifies whether the activity represented by the transaction qualifies as UOCAVA voter activity. Possible values are disqualified, pending, qualified, and other.
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?
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).
@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)?
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 |
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).
@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?
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)
Make the following changes to the esb tableschema, including relevent updates to the embedded documentation (description).
ApplicationRequestMethod
toVoterActivityMethod
cured
fromVoterActivityMethod
ApplicationRequestOtherMethod
toVoterActivityOtherMethod
ApplicationRequestPostmarkDate
ApplicationRequestProcessedDate
toVoterActivityDate
VoterActivityDate
requiredApplicationRequestReceivedDate
ApplicationRequestRejectionType
toVoterActivityStatusType
cured
fromVoterActivityStatusType
VoterActivityStatusRejectedType
ApplicationRequestRejectionOtherType
toVoterActivityStatusOtherType
ApplicationRequestStatusType
ApplicationRequestType
toVoterActivityType
BallotReturnType
toBallotReturnMethod
BallotReturnOtherType
toBallotReturnOtherMethod
BallotTransmissionType
toBallotTransmissionMethod
BallotTransmissionOtherType
toBallotTransmissionOtherMethod
JurisdictionId
toJurisdictionID
JurisdictionIdType
toJurisdictionIDType
UOCAVAFlagDate