Initial discussion and possible takers?

[yarikoptic]

Dear @adswa @snastase @vsoch @effigies @mih @soichih and all of the @con/i18n and the internet.

I initiated this repo since found no existing implementation yet. README.md gives more content but overall point is to automaintain .zenodo.org based on information from allcontributors for which there is a very convenient setup/bot available.

Immediate needs are in OBC: https://github.com/con/open-brain-consent/issues/71 and datalad-osf where it is maintained "manually" ATM

Just thought to ask first if someone already saw an implementation or has an coding itch to cure

[vsoch]

Choose me! I always have a code itch :)

You mean take the json generated by all-contributors and create a .zenodo.json (having a record already created, and then amended, or not created and created totally programmatically?)

I'm working on a more streamlined generation of the usrse map, but I'll be done within an hour or so and can work on this later today.

[effigies]

This might be helped by asking contributors to adopt the convention in https://github.com/effigies/meta where users can specify their Zenodo author information.

[yarikoptic]

The choice is made, yes and cool @vsoch ! Will add you to this repo as admin in a sec. Yes, @effigies , it would help! But if could be automated - why not? ;-)

[effigies]

Oh sure. Just not sure how to automatically associate that information.

[vsoch]

@yarikoptic can we walk through the steps, e.g.,

1. a script that takes
   • a Zenodo DOI as input
   • optionally a GitHub repository (connected repos have the GitHub address in the Zenodo metadata as a related identifier).
2. Generates a .zenodo.json based on contributors (any thresholding / other criteria for adding?)
3. What about updating an existing zenodo.json?

And in terms of metadata for the contributors - are we wanting to ping into other APIs to derive that (e.g., orcid ID) or is that overkill?

[vsoch]

Just kidding, you already wrote it out in the README! I really need to read things more carefully before asking. Let me see if I can get started on something.

[vsoch]

okay I've started something locally, and I think I'm going to provide a one off script to run it, but also a GitHub action that can handle the whole thing for you. I won't be able to finish this today, but I have most of tomorrow to work on it, so soon :)

[yarikoptic]

Just kidding, you already wrote it out in the README! I really need to read things more carefully before asking. Let me see if I can get started on something.

yeap, I think there is enough information/API to associate github login name with an orcid id. Thank you @vosch!

[vsoch]

hey @yarikoptic I have almost enough for PR, but we have an issue when the user doesn't expose their email publicly via the API (I don't) which means that we cannot find any kind of email to resolve for an ORCID id.

Also, you've framed it like "use the allcontributors to update zenodo" and I don't think that's quite right - it's more like "Use the GitHub API to update a zenodo.json and/or an .all-contributorsrc." Thoughts?

[yarikoptic]

Also, you've framed it like "use the allcontributors to update zenodo" and I don't think that's quite right - it's more like "Use the GitHub API to update a zenodo.json and/or an .all-contributorsrc." Thoughts?

I framed it that way because we already use allcontributors to selectively add and annotate contributors. allcontributors CLI and github bot made it very easy, and I do not think it is worth re-implementing allcontributors. I do not think that we should anyhow update .all-contributorsrc to not interfere with aforementioned CLI and bot. We should only establish linkage from github logins/info to orcid IDs (and get affiliation(s)).

hey @yarikoptic I have almost enough for PR, but we have an issue when the user doesn't expose their email publicly via the API (I don't) which means that we cannot find any kind of email to resolve for an ORCID id.

Interesting... I thought because AFAIK people are typically using a real email for their git configuration, which gets into each commit; that would be the email they likely have associated with github account and that hiding it would provide no additional "privacy" in case of logins with public repositories... how many e.g. from https://github.com/con/open-brain-consent/blob/master/.all-contributorsrc have it available?

Another possibility -- make it explicit at orcid level. I see in "Help" there on external identifiers: "Github username (currently in beta when one connects to both ORCID and Github from one's DataCite profile)". I have now logged in to datacite via globus via dartmouth auth, linked to orcid (on https://profiles.datacite.org/) but do not see how I could add github profile there... but it could be a line to explore.

Also, I guess for any such tricky cases (unknown email, absent or wrong search result from orcid) we would need to provide ability to override, but only then -- I hope that it would be automatic for most of people. We could also perform search on orcid by name known to all-contributors. Some interactive UI listing "candidates" with information (affiliation) would allow to verify and/or quickly select the correct one in such cases.

[vsoch]

I framed it that way because we already use allcontributors to selectively add and annotate contributors. allcontributors CLI and github bot made it very easy, and I do not think it is worth re-implementing allcontributors. I do not think that we should anyhow update .all-contributorsrc to not interfere with aforementioned CLI and bot. We should only establish linkage from github logins/info to orcid IDs (and get affiliation(s)).

How about scoping it as a zenodo update tool then? By default, we would parse from GitHub. The user can then add an .all-contributorsrc file as another source to find people.

Interesting... I thought because AFAIK people are typically using a real email for their git configuration, which gets into each commit; that would be the email they likely have associated with github account and that hiding it would provide no additional "privacy" in case of logins with public repositories... how many e.g. from https://github.com/con/open-brain-consent/blob/master/.all-contributorsrc have it available?

Nope, I tested this. I'm one of those folks that has my email defined by private. Even with my own GitHub token and using the GitHub users api the email is "None." I'm not sure about how many have it for your current config/repo.

Another possibility -- make it explicit at orcid level. I see in "Help" there on external identifiers: "Github username (currently in beta when one connects to both ORCID and Github from one's DataCite profile)". I have now logged in to datacite via globus via dartmouth auth, linked to orcid (on https://profiles.datacite.org/) but do not see how I could add github profile there... but it could be a line to explore.

Do you mean having the main client be focused around Orcid? I'm not totally following - could you give details and examples of what the interaction would look like?

Also, I guess for any such tricky cases (unknown email, absent or wrong search result from orcid) we would need to provide ability to override, but only then -- I hope that it would be automatic for most of people. We could also perform search on orcid by name known to all-contributors. Some interactive UI listing "candidates" with information (affiliation) would allow to verify and/or quickly select the correct one in such cases.

Well at least for zenodo.json, you technically aren't required to have an affiliation or orcid, at least I've seen plenty of creators that just have a name.

[vsoch]

First version of the library is done, going to close this issue.