Add several missing ORCiD identifiers

[cthoyt]

No description provided.

[matentzn]

Almost looks good, one ORCID to remove please.

[matentzn]

I am fine with this but please let's get a @nataled review to be sure this is procedurally kosher

[cthoyt]

precedent for adding ORCiDs to inactive records without any fuss: #2321

[nataled]

To my knowledge, we don't have an official procedure to cover this situation (meaning: however it was handled before was never codified). However, in February of 2022, the Operations Committee did make it a point to send a message to all ontology contact people about adding their ORCID, and each person could opt out. On that basis, I would say that's as close as we have to procedural precedent: We ask.

That being said, if these ontologies were part of the Foundry in early 2022 and there is no ORCID, then it likely means they've already opted out and they should NOT be added. The question I'd have is "do we have any indication that the responsible people already opted out?" If we do, then definitely don't add. If we don't, then ask.

Do we have a date for admittance to the Foundry for these ontologies?

[matentzn]

if these ontologies were part of the Foundry in early 2022 and there is no ORCID, then it likely means they've already opted out and they should NOT be added.

@nataled did we receive any "opt-outs"? these need to be documented I think. I dont think we can assume they opted out - I myself have not heard of anyone opting out, and I would not even know through which channel that would be communicated.

All of these ontologies are much older, many inactive.

[nataled]

Okay, good, we at least know that they were around back in 2022 and COULD have opted out if they wished. By the rule established in that email, failure to opt out means that the ORCID would have been added. That's the basis for the assumption they likely opted out, but there are other possibilities (see below).

I could not find any opt out cases, but the only search I did was to see if anyone responded to that particular email. People might have opted out via Slack if an announcement was made that way, or some other way. I would hope we have the opt out evidence. The email was sent by @nicolevasilevsky so maybe she has a list somewhere.

The fact that there is no ORCID for these can be due to multiple possibilities:

1. The relevant people opted out already;
2. The relevant people did not opt out, but did not have an ORCID at the time we did the mass add;

In the case of (1), hopefully we have a log of it and can put it to rest with a 'do not add'. If we don't have a log, we then have two paths. The first is to still assume they opted out and put it to rest with a 'do not add'. The second is to ask. The only downside to asking is them saying "I already answered this" and getting annoyed that we are asking again. I don't think that's such a terrible thing.

In the case of (2), we have to consider that they didn't opt out because it simply didn't apply to them when asked. Now that it would apply, we would need to ask.

So, overall, I think the default path forward is to ask. Only if we have concrete evidence they opted out already do we not bother because we already have the answer.

[matentzn]

Its also so annoying to elicit permissions from this precise group because they dont even have a github handled registered. Sorry @cthoyt - your call but we have a clear rule here:

https://obofoundry.org/docs/SOP.html#META

1. First we have to tag with github handle (we cant in this case)

and then:

If the change pertains to one of the following metadata fields, an OBO Foundry operations committee member MUST send an email to the listed contact with a link to the pull request: activity_status, contact.

[matentzn]

Am I correct in assuming we dont have github handles for these people @cthoyt?