Votes not showing PersonVoteNode's voter information correctly


#1

I’ve found, when querying bills, voter information not being pulled in despite it existing in Openstates, e.g., Florida’s HB 351 senate vote compared to v2 API result for the query:

{
  bill(id: "ocd-bill/1978f5ff-2503-4a56-88ee-8c0d6e4edc09") {
    id
    identifier
    otherIdentifiers {
      note
      scheme
      identifier
    }
    title
    versions {
      note
      date
      links {
        url
      }
    }
    votes {
      edges {
        node {
          counts {
            value
            option
          }
          organization {
            id
            name
          }
          motionText
          motionClassification
          identifier
          startDate
          result
          extras
          votes {
            voterName
            voter {
              id
              name
            }
            option
          }
        }
      }
    }
  }
}

The PersonVoteNode shows the last name, the option, but the voter is almost always null…specifically, for the vote in question:

              "node": {
                "counts": [
                  {
                    "value": 37,
                    "option": "yes"
                  },
                  {
                    "value": 0,
                    "option": "no"
                  },
                  {
                    "value": 1,
                    "option": "not voting"
                  }
                ],
                "organization": {
                  "id": "ocd-organization/c540c1bb-d614-4174-86db-a146526169f8",
                  "name": "Florida Senate"
                },
                "motionText": "Third Reading",
                "motionClassification": [
                  "passage"
                ],
                "identifier": "",
                "startDate": "2018-03-08T01:11:00-05:00",
                "result": "pass",
                "extras": "{}",
                "votes": [
                  {
                    "voterName": "Baxley",
                    "voter": null,
                    "option": "yes"
                  },
                  {
                    "voterName": "Garcia",
                    "voter": null,
                    "option": "yes"
                  },
                    /* etc. */
                ]
              }

#2

The work we did in moving people over to a new repo in essence declared bankruptcy on the issue of name resolution, with the plus being that we now have a very clean path towards solving these problems going forward.

Sorry for getting into the weeds here, but here’s the current situation & plan going forward:

The old system had a manual resolution tool, basically we could go into the database and see what data wasn’t matched and fix it. This worked fairly well when we had a full-time staff/etc. In fact, this was essentially an intern’s job for ~4 months a year. We opted for this because we could afford an intern & it was better than automatic resolution getting things wrong.

The new system relies on exact matches, but allows legislators to have any number of aliases. This was intended to eventually accommodate common situations, for instance where we see votes from Jones-32 and Jones-1, or Smith, J. and Smith, A.

These legislators can now have aliases added to them and then the votes will be automatically resolved. This still has a bit of manual work to do, but it has to be done less frequently.

So, right now in v1, we have the remnants of the matching table built from ~2010-2015. Nobody has been able to maintain it since then, but it does OK.

Now v2 is powered by the https://github.com/openstates/people repo, which means that people can actually contribute to the process by adding known aliases (be they last names or other ways votes show up).

So what are the next steps:

  • we need to generate a list of unmatched aliases (which is happening here: https://github.com/opencivicdata/pupa/pull/319)
  • once that’s ready (soon!) we need to start publishing that somewhere that people can contribute files mapping those to our legislator ids/etc.
  • and then we’ll need an easy way for people to add those matches into the people repo without making a couple hundred individual (error-prone) yaml edits. there’s a bit of work towards that in the people repo, but I figure it makes sense to wait until we are a bit further along since I’m not 100% sure what format will be easiest for people to work in

#3

Can you relate this to the problem described?
Why are these legislators in those votes not resolving?

Besides missing aliases, are there large classes of 2018 votes that are likely to never be resolved? If so, what is characteristic of them?