Refactor `population_` prefixed columns in `Partner` model

[armahillo]

It would probably be worth considering a refactor at this point -- there are a TON of population_ prefixed columns and I suspect there will be more after these demographic categories are added. Could these be condensed into a population_demographic (or similar) JSON column? Could probably do the same with the other N+1 column headers as well.

Originally posted by @armahillo in https://github.com/rubyforgood/human-essentials/issues/2550#issuecomment-940422095

Two approaches come to mind for this:

1. Extract this to a separate resource
2. Combine these into a single JSON field

I have not dove deep into how this data behaves (very fluent in Diaper side, less so on Partner side), but the cursory look I've had suggests to me that it's just a simple scalar with a multitude of related variants. Something like:

population: :json that stored a collection like:

{ 
   "united-states": 1234,
   "canada": 2345,
   "mexico": 3456,
}

would probably work. PostgreSQL lets us query on JSON values natively, so we shouldn't take a performance hit if the app needs to query on those fields specifically (instead of only reporting them)

Nesting data, like:

{ 
   "united-states": {
      "region-1": 123,
      "northeast": 234,
      "south": 345,
      "some-other-region": 223,
   },
   "canada": {
     "quebec": 111,
     "ontario": { 
         "toronto": 22222,
         "other": 111
     },
   }

would be possible though that feels a bit wibbly and loose with the strucure of the data, particularly regarding a key naming scheme. I think doing a 1:1 migration of column names to keys would probably be sufficient and could be done with a lateral shift in behavior.

Alternately, were it to be done as an associative resource if we needed specific behaviors around it too -- this might be the way to go if there are a BUNCH of different demographic fields that need extraction like this, then they could fall under the same larger resource and subtype them via STI.

[seanmarcia]

I've also been thinking about this and the best way to proceed. For background, I know the races in there were supplied by the NDBN who use that specific list since that list of races is/was the list used in the census. I think for discovery I'd want to:

• See if the list of races was updated/changed with the 2020 census
• See what data the NDBN needs for their grant information
• Think about adding a new associated model -- ethnicity -- (races have many ethnicities) so we can collect both data for the NDBN and the specific bank. So we could capture that white/caucasian compromise 50% of the recipients and keep that information but can further break that down into irish/german/french/etc ethnicities.

[cielf]

From: https://www2.census.gov/programs-surveys/decennial/2020/technical-documentation/questionnaires-and-instructions/questionnaires/2020-informational-questionnaire-english_DI-Q1.pd

If I'm reading this correctly, the 2020 census added several more-specific race categories that (I presume) would have been under the Asian or Pacific Islander umbrellas before.

f

[cielf]

From the partnerbase working group meeting 2022/07/13,

• noting that the gov't is often a bit behind on preferred terminology
• recommended:
  • Black/African-American
  • White/Caucasian
  • Hispanic/Latin
  • Native American/Alaskan Native

[scooter-dangle]

Closing due to lack of activity