CUNY Academic Commons

If we're just saving email addresses, I will just add_user_meta() for each one. If we need more data, we'll need a different system. Serialized arrays may limit queryability in the future.)

`add_user_meta()` is also what I would recommend for now.

Hi All -- I don't object (at all) to this, but I would suggest that it be considered in the context of our discussions earlier this year around data privacy and keeping a minimal amount of info on our members

Matt, this is a good point. Currently, it's possible for a user to have a more or less pseudonymous Commons account: while we require a CUNY address to register for the site (which reflects your real name), it's then possible to change your email address to something arbitrary, with no further indication of your identity.

Luke, can you remind us what some of the specific applications of having this data might be? I can't remember how it came up in the conversation. (Deduplication during invitations, I guess?) Perhaps we shouldn't be collecting this data unless there's a pressing need for it.

No pressing need, and certainly worthy of deliberation.

First came up when gaming what a bulk add user process might look like as a way of locating existing accounts on the Commons for folks who've changed their email addresses. I don't think we'll need it for those purposes, given the direction the onboarding work is going.

But then it seemed like there might be instances where this data was useful, since it's really the only piece of accurate metadata that we require, and is the only way that we can accurately trace who's joined us from what campus and when. If we do want to allow permanently pseudonymous accounts, then I agree that we should avoid this (and perhaps be more explicit that this is possible, and how, and why). But if we don't, then this is a way to capture some data that might be useful. We could also deidentify by disassociating the email from the account, and merely storing an independent record of what email addresses have registered (though that wouldn't allow us to use this to manage users).

I don't feel particularly strongly about this... just thought it was worthy of a think.