<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 19, 2018 at 10:01 AM "Peter Löwe" <<a href="mailto:peter.loewe@gmx.de">peter.loewe@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Verdana;font-size:12.0px"><div><div name="quote" style="margin:10px 5px 5px 10px;padding:10px 0 10px 10px;border-left:2px solid #c3d9e5;word-wrap:break-word"><div name="quoted-content"><div class="gmail_quote"><div></div>

<blockquote class="gmail_quote" style="margin:0.0px 0.0px 0.0px 0.8ex;border-left:1.0px solid rgb(204,204,204);padding-left:1.0ex"><br>
Can you give recomendations what keywords/metadata should be attached to such external GRASS repos so users will find them ?</blockquote>

<div> </div>
I think that's a challenge and that's one of the reasons, the official GRASS GIS Addons repository is still the best option.</div>

<div class="gmail_quote"> </div>

<div class="gmail_quote">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.</div>

<div class="gmail_quote"> </div>

<div class="gmail_quote"> </div>

<div class="gmail_quote">-> 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.</div></div></div></div></div></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Verdana;font-size:12.0px"><div><div name="quote" style="margin:10px 5px 5px 10px;padding:10px 0 10px 10px;border-left:2px solid #c3d9e5;word-wrap:break-word"><div name="quoted-content">

<div class="gmail_quote"> </div>

<div class="gmail_quote">-> 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 :-) ).</div></div></div></div></div></div></blockquote><div><br></div><div></div><div>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, ...</div><div><br></div><div><br></div></div></div>