Query users

[joeflack4]

Summary

We need to query users (authors and respondents).

Major features

• 1. Users
• 2. Roles
• 3. "Profiling"

Steps

1. Query list of messages (done)
2. Get unique list of author email addresses
3. Use user endpoint to get additional user information

• Edit: joeflack4 2022/08/15: Looks like this part is not necessary. The message API returns user ID, name, and email. I think that's all we'll need right now, but we should ask.

4. Roles
   4b. Profiles
5. Output

Steps, expanded

4. Roles (@pending initial results)

@DaveraGabriel will give us a mapping list of {person name --> role} once we present her w/ the list of people. Davera will fill in this spreadsheet: https://docs.google.com/spreadsheets/d/1OB0CEAkOhVTN71uIhzCo_iNaiD1B6qLqL7uwil5O22Q/edit#gid=1504038457

There are different classes of roles.

List of roles:
i. FHIR Management Group / FHIR-I
ii. Terminology Services Management Group / Vocab WG
iii. IG Developer / WG member
iv. External Terminology steward /representative
v. FHIR (... other standard) implementer

4b. Profiles

Davera said 2022/09/18:

look at the users. what categories or keywords come up in their messages.
predominantly author (quantile based~) vs respondent

This would be like clustering based on information about the users.

5. Output

@DaveraGabriel What kinda output would you like to see? A new CSV? What columns?
~i. Counts of individuals, grouped by [author, respondent]
ii. Counts of "types / roles" grouped by "authors / respondents"
Example CSV Fields:

• type: individual, role
• name: e.g. a person name or a role name
• count~

Edit: joeflack4 2022/08/15: I came up with a better idea for how the output should look, I think.

Later we can do fancier, like JOIN on keywords for more information, disaggregate by author/respondent, etc.

Questions that we're interested in are "this type of role is interested / talking about 'x'"

[joeflack4]

Major bugfix I need to do:

    # TODO: Bugfix: Major bug; respondent/author counts are not all correct. This is because (i) threads are being 
       counted multiple times when multiple keywords are matched against them, and (ii) we are *only* counting messages
       within threads that have keyword matches; not every message in every thread that has a keyword match for any 
       message.

Related: #32