[GRASS-user] Example project on GitLab: Access / discoverablity

[Vaclav Petras]

On Mon, Nov 19, 2018 at 10:01 AM "Peter Löwe" <peter.loewe at gmx.de> wrote:

>
>> Can you give recomendations what keywords/metadata should be attached to
>> such external GRASS repos so users will find them ?
>
>
> I think that's a challenge and that's one of the reasons, the official
> GRASS GIS Addons repository is still the best option.
>
> The search on GitLab as well as GitHub (and pretty much everywhere) does
> not distinguish keywords from names or descriptions, so as long as "GRASS
> GIS" and "module" is somewhere, it's good. However, this can also give a
> lot of results which are not GRASS GIS modules. The ultimate test is of
> course examining the content, e.g. the couple lines in the Makefile. Adding
> "g.extension" as a keyword and/or expecting in a README file might be a
> way, but still only approximate and it is an odd keyword to have.
>
>
> -> Maybe at this point the Citation File Format, as already introduced
> through the g.citation module, could be a step forward: IF a repo contains
> the keyword "GRASS GIS" AND there is a CFF file, this could be mined for
> structured information about the code.
>

A CFF might end up being a recommend part of a GRASS GIS module source code
(well, I can recommend it even now), but that still would not be enough to
identify a module because you can have e.g. a code using GRASS GIS
externally or a project analyzing GRASS GIS source code which would include
CFF file and GRASS GIS as a keyword.


>
> -> Currently, Zenodo (as a DOI generator) can only be linked to GitHub,
> but IMHO it's just a matter of time until they also support GitLab. Once
> that happens we should brace ourselves for a diaspora of GRASS mini-repos
> as the academia-based developers will go after scientific credit / citation
> by DOI. In such a situation finding/discovering useful add-ons will become
> a challenge (unless the code is placed in the canoncal GRASS project repos
> :-) ).
>

We already have a lot of modules floating around on personal websites or
servers. In these cases, GitHub and others made the discovery and perhaps
even the preservation actually easier because now things are at least in
couple of predictable and searchable places. But obviously, this is a worse
state than GRASS GIS Addons with its central registry, code maintained by
community, linked online documentation, compiled binaries for MS Windows
(!), compilation log, ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20181124/3db734ff/attachment.html>