Re: [GRASS-PSC] Introducing DOI for software, documentation and data in the GRASS project

[Michael Barton]

In fact, our plan is to mint DOI's via Zenodo to replace handles minted by ASU 
Libraries in the future.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















> On Nov 21, 2016, at 7:20 AM, Helmut Kudrnovsky  wrote:
> 
> Michael Barton wrote
>> Markus and Co.
>> 
>> This is something CoMSES Net (Network for Computational Modeling in Social
>> and Ecological Sciences: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.comses.net=CwIGaQ=AGbYxfJbXK67KfXyGqyv2Ejiz41FqQuZFk4A-1IxfAU=vxOW6PLS28MPea_dWUwPfRf71TAIziRDuFqWJimQN1I=fxAwSdFUptqrNZhLpoUeV51d4MElroWSZqBOxXCcNhw=2XqftSPoWzzKpQBZsef2l78EzFJ7V-qFsxgPlEbR98I=
>>  ) has been working with for
>> some years now. We maintain a software code library, where researchers can
>> publish model code. We also provide for the option of code peer review,
>> which can happen when code is submitted to the library for review along
>> with a paper sent to a journal, or independent of any paper review. Code
>> that has passed peer review is currently assigned a “handle” from
>> handle.nethttps://urldefense.proofpoint.com/v2/url?u=http-3A__handle.net-26gt-3B=CwIGaQ=AGbYxfJbXK67KfXyGqyv2Ejiz41FqQuZFk4A-1IxfAU=vxOW6PLS28MPea_dWUwPfRf71TAIziRDuFqWJimQN1I=fxAwSdFUptqrNZhLpoUeV51d4MElroWSZqBOxXCcNhw=UGR-DI_wHshdnJafI6Bq9052kj0tJtFttN95PJGI9c0=
>>  . 
>> Handle.nethttps://urldefense.proofpoint.com/v2/url?u=http-3A__handle.net-26gt-3B=CwIGaQ=AGbYxfJbXK67KfXyGqyv2Ejiz41FqQuZFk4A-1IxfAU=vxOW6PLS28MPea_dWUwPfRf71TAIziRDuFqWJimQN1I=fxAwSdFUptqrNZhLpoUeV51d4MElroWSZqBOxXCcNhw=UGR-DI_wHshdnJafI6Bq9052kj0tJtFttN95PJGI9c0=
>>  
>> is the organization that oversees the digital identifier ecosystem. DOI’s
>> are commercial instances and handles are open source instances, but both
>> are ultimately under the purview of 
>> handle.nethttps://urldefense.proofpoint.com/v2/url?u=http-3A__handle.net-26gt-3B=CwIGaQ=AGbYxfJbXK67KfXyGqyv2Ejiz41FqQuZFk4A-1IxfAU=vxOW6PLS28MPea_dWUwPfRf71TAIziRDuFqWJimQN1I=fxAwSdFUptqrNZhLpoUeV51d4MElroWSZqBOxXCcNhw=UGR-DI_wHshdnJafI6Bq9052kj0tJtFttN95PJGI9c0=
>>  .
>> With a new grant from NSF, CoMSES Net is now part of a new national data
>> infrastructure network in the US. One of our plans is to transition from
>> handles to DOI’s because these are more widely recognized.
>> 
>> Given all this, we’ve had to think quite a bit about how to ‘publish’
>> model code and assign identifiers. As Vaclav points out there are
>> significant issues with versioning. What happens with a new version? We’ve
>> adopted a conceptual position that we are not a versioning repository
>> primarily, but a place where authors can publish ‘finished’ code used in a
>> research project or product. We are trying to treat this like a library
>> and journal environment in that sense. We allow for minor revisions to
>> correct errors (including as a response to reviews). But if a new product
>> (e.g., a research paper) uses a new version of model code, we consider
>> that a new digital object published, which could get a new handle/DOI
>> distinct from a version of a model used for an earlier product. This
>> remains something that is complicated to implement in practice. But the
>> concept involves the reason for giving out the handle/DOI in the first
>> place.
>> 
>> Currently, only about 10% of published model based science makes code
>> available for review or reuse. We think it is increasingly important that
>> researchers share the code that is an important component to scientific
>> practice in the same way they share research protocols and results—and are
>> increasingly encouraged to share data. But sharing code takes effort, and
>> even researchers with the best intentions may find it difficult to find
>> the time or energy to make code available. So we are trying to create
>> incentives that will have some value in the academic/research world,
>> including citable products. All models published in the CoMSES Net library
>> have automatically generated citations. Those that have passed peer
>> review, verifying some degree of software quality, are also given
>> permanent identifiers (handles/DOIs), with the idea that researchers can
>> put them on their CVs where they at least have the possibility of gaining
>> them some recognition for the work carried out. That is, we consider a DOI
>> as an incentive for sharing code and a bit of a lever to get others to
>> cite that code if they use it.
>> 
>> We are still trying to work out how best to handle improvements (bug
>> fixes) to a model vs. new models. We are moving our library to a Git
>> environment, but are still working out how to 

Re: [GRASS-PSC] PSC management

[Moritz Lennert]

On 18/11/16 01:55, Anna Petrášová wrote:

On Thu, Nov 17, 2016 at 10:54 AM, Markus Neteler  wrote:

On Thu, Nov 17, 2016 at 2:53 PM, Margherita Di Leo  wrote:

On Thu, Nov 17, 2016 at 12:15 PM, Markus Neteler  wrote:

...

https://trac.osgeo.org/grass/wiki/PSC/Roles

Now I think that all new and confirmed members may contribute to this
question and edit the trac page directly (and report here)
 :-)



The first email in this thread dates back to 2014 and no action has been
taken,


Right. Howver, we have a new PSC in place now.


from my POV we would need to discuss this thread, as well as other
threads that were posed by members of the community, in a more interactive
way, perhaps via IRC.


Sounds good to me.


Regarding the roles, I am sure other important roles
can be individuated as well (e.g. GSoC coordinator/mentors).


It is a draft wiki page which could be extended.
Regarding the GSoC mentors, I think that this works ok. If we really
need a designated GRASS GIS GSoC coordinator, I don't know.


At the same
time, I'm not sure that these roles must be necessarily found withing the
PSC.


As I wrote in the trac wiki page

"Note: a PSC member with a certain role can also delegate another
community member to share the workload "


Besides the activities that clearly fall currently on the shoulders of
Markus and few others, I don't understand why we need a coordinator at all,
since some activities seem to flow well without a designated coordinator, as
Moritz pointed out. But I'm sure that to propose this, Markus, you must have
your reasons.


Yes: I want a more active PSC. Not sporadically but constantly.


Could we make a quick check of the situation, individuate the
current issues and what are we trying to achieve (or which problems are we
trying to solve) with this proposal? Thanks


Here you go - the current situation (of course my completely biased
private view):

* treasurer: done by Martin Landa and Markus Neteler
* release manager: done by Markus Neteler
* translation manager: done by Markus Neteler
* education manager: vacant
* press and marketing manager: : done by Markus Neteler
* documentation manager: : mainly done by Markus Neteler, with
contributions by Vero, Vaclav and others
* designer: Vincent Bain for flyer, Web site mainly done by Markus
Neteler lacking the migration to a new CMS
* trac bug report manager: mainly done by Markus Neteler with major
support by core developers
* testing manager: vacant? major efforts done by Sören and Vaclav
* GUI design manager: vacant? major efforts done by Anna, Vaclav, Martin

This and that name appears too often :-)



We suggest 'working groups' instead of managers, for some tasks it
fits better and might put the pressure off if people want to join. I
also added additional groups, which would be focused on specific
tasks, such as Python 3.


I also added the task of moving from svn to git.

However, as sorry as I am about this, at this stage, I would not want to 
take on any of these responsibilities, as I'm afraid I wouldn't do them 
any justice currently. Obviously, I'll continue to work on the code, 
and, as always, am available for short term support on any issue. I hope 
this will change by the end of next year. Or maybe Anna's suggestion of 
collectivizing responsibilities on 2-3 developers per task could be a way.


I would strongly plead for some of the power-users to take over some of 
the non-coding responsibilities (i.e. translation, education, marketing, 
documentation, designer) !


Maybe we could send the list around on grass-dev/grass-user and invite 
non-PSC members to take over some these jobs ?


Moritz
___
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc

Re: [GRASS-PSC] Introducing DOI for software, documentation and data in the GRASS project

[Helmut Kudrnovsky]

Michael Barton wrote
> Markus and Co.
> 
> This is something CoMSES Net (Network for Computational Modeling in Social
> and Ecological Sciences: http://www.comses.net) has been working with for
> some years now. We maintain a software code library, where researchers can
> publish model code. We also provide for the option of code peer review,
> which can happen when code is submitted to the library for review along
> with a paper sent to a journal, or independent of any paper review. Code
> that has passed peer review is currently assigned a “handle” from
> handle.nethttp://handle.net;. Handle.nethttp://handle.net;
> is the organization that oversees the digital identifier ecosystem. DOI’s
> are commercial instances and handles are open source instances, but both
> are ultimately under the purview of handle.nethttp://handle.net;.
> With a new grant from NSF, CoMSES Net is now part of a new national data
> infrastructure network in the US. One of our plans is to transition from
> handles to DOI’s because these are more widely recognized.
> 
> Given all this, we’ve had to think quite a bit about how to ‘publish’
> model code and assign identifiers. As Vaclav points out there are
> significant issues with versioning. What happens with a new version? We’ve
> adopted a conceptual position that we are not a versioning repository
> primarily, but a place where authors can publish ‘finished’ code used in a
> research project or product. We are trying to treat this like a library
> and journal environment in that sense. We allow for minor revisions to
> correct errors (including as a response to reviews). But if a new product
> (e.g., a research paper) uses a new version of model code, we consider
> that a new digital object published, which could get a new handle/DOI
> distinct from a version of a model used for an earlier product. This
> remains something that is complicated to implement in practice. But the
> concept involves the reason for giving out the handle/DOI in the first
> place.
> 
> Currently, only about 10% of published model based science makes code
> available for review or reuse. We think it is increasingly important that
> researchers share the code that is an important component to scientific
> practice in the same way they share research protocols and results—and are
> increasingly encouraged to share data. But sharing code takes effort, and
> even researchers with the best intentions may find it difficult to find
> the time or energy to make code available. So we are trying to create
> incentives that will have some value in the academic/research world,
> including citable products. All models published in the CoMSES Net library
> have automatically generated citations. Those that have passed peer
> review, verifying some degree of software quality, are also given
> permanent identifiers (handles/DOIs), with the idea that researchers can
> put them on their CVs where they at least have the possibility of gaining
> them some recognition for the work carried out. That is, we consider a DOI
> as an incentive for sharing code and a bit of a lever to get others to
> cite that code if they use it.
> 
> We are still trying to work out how best to handle improvements (bug
> fixes) to a model vs. new models. We are moving our library to a Git
> environment, but are still working out how to implement our concept of
> “published” snapshots of code in a library/journal in versions and
> releases in Git. We do have a roadmap and are working on it, but we don’t
> yet have a solution in place.
> 
> Where is all this leading? We need to ask what is the value to assigning
> DOIs to GRASS code, how might they benefit GRASS developers, and how might
> they be used by GRASS software users? I don’t see that they provide the
> kind of incentives that CoMSES Net is envisioning for computational model
> developers. Most DOIs are assigned to finished products as digital
> objects. From that perspective, GRASS could get a DOI, but not its
> component modules. But what about each version of GRASS?  GRASS has formal
> releases, but not its components. Some code is in the released code base
> and other is in addons. There is ongoing development in the SVN. GRASS is
> a digital object of course, as are its component code modules, but it is a
> dynamic, living one and not a static one. Perhaps there are other benefits
> to working out the complications of where and when to assign DOIs in the
> GRASS ecosystem. But it will be good to start with a discussion of why and
> for whom we would do it.
> 
> (I’m copying Allen Lee from the CoMSES Net leadership team as he has
> thought a lot about this and might have other things to add.)
> 
> Cheers
> Michael

some kind of related:

http://ivory.idyll.org/blog/2016-using-zenodo-to-archive-github.html
https://zenodo.org/






-
best regards
Helmut
--
View this message in context: