[GRASS-PSC] git migration: Zenodo optionS

["Peter Löwe"]

Hi Markus, hi list,

I was raising the Zenodo-topic, since this might strategically affect how we need to structure the GRASS repository / repositories on GitHub, so we can make the most out of Zenodo for scientific citation later.

Zenodo currenlty mints for EACH SINGLE GitHub-project which is checked in EXACTLY ONE persistent identifier ("unbreakable Web-link"), a Digital Object Identifier (DOI). DOI have become crucial for scientific citation and indirectly also for the careers of early career scientists (who need lots a citations to eventually get tenure/rich)

Whenever there's a new release of the project repo on GitHub, the corresponding repo- instance in Zenodo is updated accordingly and the DOI is also updated to a new version (note: it's the same DOI, NOT a new/different DOI). This compares to the update note on GRASS man pages ("Note: A new GRASS GIS stable version has been released: GRASS GIS 7.6, available here. Updated manual page: here").

In this manner we're dealing with two different flavours of DOI-based reference: 1.) The "overall" DOI for the archived (GRASS-)software repo and 2.) the continuously increased version/release numbers (e.g. citing "GRASS GIS" versus a particular release "GRASS 4.2.1"; "GRASS 5.3", "GRASS 7.4", etc.). 

So from the Zenodo/DOI perspective need to consider (at least) two options for using GitHub:

a) We could _SPLIT_ the overall GRASS repo and create individual GitHub repos for each currently existing GRASS release, so each gets its own distinct DOI (this would allow for backports to be considered new (DOI)versions of the particular GRASS releases).

b) We keep __ONE__ GRASS project GUI, and get __ONE__ DOI for the greater GRASS project wich has LOTS of versions. Suggestion: We could start filling the repo (already linked with Zenodo) consecutively, beginning with the oldest archived GRASS releases, minting a DOI-version for each one. In this manner, each old GRASS release will receive it's own  distinct __version__ of the overall DOI. Things could get messy lateron, when backports to previous releases are made, which will also cause DOI version updates, but AFAIK there's no way yet to sort through all DOI versions (just) for a specific GRASS release.

We also should consider that Zenodo currently can't handle fine-grained DOI, to cite a particular GRASS module within a certain GRASS release. There's still a lot of development going on both in the DOI infrastructure and Zenodo, so this might come as a later step.

Another interesting aspect is the issue of ownership and due credit: Both the GRASS repo(s) on GitHub and the corresponding Zendo-archive(s) must have owners. This should be IMHO the "GRASS Development Team". Therefore the GRASS-related DOI(s) will be attributed to the GRASS Developer Team. We should think about a way, to link the ORCIDs of team members ("persitent identifiers for individual persons" https://orcid.org) to the GRASS DOI(s). This is not trivial (but innovative), but can be tackled later.  

best,
Peter

<peter.loewe at gmx.de>


> Gesendet: Montag, 01. April 2019 um 11:13 Uhr
> Von: "Markus Neteler" <neteler at osgeo.org>
> An: "Peter Löwe" <peter.loewe at gmx.de>
> Cc: GRASS-PSC <grass-psc at lists.osgeo.org>
> Betreff: Re: git migration: the Zenodo option
>
> Hi Peter,
> 
> On Mon, Apr 1, 2019 at 9:35 AM "Peter Löwe" <peter.loewe at gmx.de> wrote:
> >
> > Hello PSC,
> >
> > before we actually venture into GitHub, I propose we should consider beforehand how the GRASS repo(s) *could* make use  of the Zenodo archive in the future, so we can set up things in a way that this option can be used (setting up of credentials, etc.). Zenodo is a open-access long term scientific archive (https://en.wikipedia.org/wiki/Zenodo), operated and maintained by CERN. The Zenodo software itself is also FOSS.
> > Connecting repos on GitHub with Zenodo is easy: https://guides.github.com/activities/citable-code/
> >
> > IMHO we could use this mechanism to provide scientific citability and long term preservation for the old stable releases GRASS 4.x, 5.x and 6.x.
> 
> A very good idea.
> Just curious: why is this needed to be done (?) *before* migrating to
> GitHub? I'd rather get that done first, then put cool stuff on top.
> 
> Best
> Markus
>