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.lo...@gmx.de>
> Gesendet: Montag, 01. April 2019 um 11:13 Uhr
> Von: "Markus Neteler" <nete...@osgeo.org>
> An: "Peter Löwe" <peter.lo...@gmx.de>
> Cc: GRASS-PSC <grass-psc@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.lo...@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
>
_______________________________________________
grass-psc mailing list
grass-psc@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-psc
