[Neuroimaging] Journal articles based on PRs

Thu Apr 14 08:17:12 EDT 2016

Hi, Chris,

Xiangzhen shares the mail, and I like the Zenodo solution very much.
I don't know what information should I provide (my GitHub ID is sealhuang).

Best,
Lijie Huang

On Wed, Apr 13, 2016 at 8:46 PM, Xiangzhen Kong <bnucon at gmail.com> wrote:

> Hi, Chris.
> The Zenodo solution is so cool.
> I have not received the email about the this event. Please help me to
> check it. My GitHub ID is Conxz. Thank you!
>
>
> Best,
> Xiangzhen
>
> On Wed, Apr 13, 2016 at 4:47 AM, Chris Filo Gorgolewski <
> krzysztof.gorgolewski at gmail.com> wrote:
>
>> Hi Ariel,
>> I have been recently thinking about the problem of giving academic credit
>> to contributors. In Nipype we are facing exactly the same problem - people
>> joining the project after the paper was published do not benefit from
>> citations. The project is as strong as its community so we wanted to give
>> people credit for their hard work. After some deliberations we have decided
>> to go with a different approach then you are proposing. Beginning from the
>> next release we will switch the main recommended citation from the
>> Frontiers paper to a Zenodo <https://zenodo.org/> handle. In the past
>> weeks we have been reaching out to Nipype contributors to get their
>> permission and details to become coauthors of this Zenodo entry (please get
>> in touch if you have contributed to Nipype and did not receive an email
>> about this).
>>
>> Zenodo is a non profit organisation that provides citable DOIs for
>> software (free of charge). It is indexed by Google scholar and is easy to
>> set up and update. Thanks to this feature, with each release we will keep
>> adding new contributors as coauthors. This solution has the following
>> advantages:
>> - Everyone contributing to nipype gets credit in the form of citations
>> - There is one publication which makes citing easy (compare to Freesurfer
>> https://surfer.nmr.mgh.harvard.edu/fswiki/FreeSurferMethodsCitation,
>> also consider that some journals limit the number of references)
>> - There is no overhead of writing, submitting, and revising a manuscript
>> on top of developing and revising code
>>
>> There is, however, one big drawback - there is only one first and one
>> senior author on the Zenodo handle. I think this calls for a hybrid
>> solution: an always up to date Zenodo entry combined with individual papers
>> written by developers who feel they need such publication and are willing
>> to put the extra effort of writing the manuscript. I would stay away from
>> making a "deal" or explicitly recommending one particular commercial
>> publisher. There are many outlets which publish software or software
>> extensions (for example F1000Research has "Software Tool" category that
>> often publishes small contributions: see
>> http://f1000research.com/articles/2-192/v2 for example). I would leave
>> it open to the developers to choose the venue where they want to publish
>> using their best judgement. Why is it important? Most publishers are
>> commercial entities and strongly recommending one over another benefits
>> them financially. I think that as an open community, we should stay away
>> from such decisions to avoid being accused of some shady internal deals.
>> Let developers (and potential authors of such papers) decide by themselves.
>>
>> I hope this helps!
>>
>> Best,
>> Chris
>>
>>
>>
>> On Tue, Apr 12, 2016 at 8:26 AM, Ariel Rokem <arokem at gmail.com> wrote:
>>
>>> Hi everyone,
>>>
>>> In a conversation I had with Rafael recently, he mentioned to me the
>>> Journal of Open Research Software (
>>> http://openresearchsoftware.metajnl.com/) that publishes articles about
>>> open-source research software, and proposed this as a good place to publish
>>> software contributions in our community. This is a good thing because it
>>> provides a venue for articles specifically focused on software
>>> implementations, even in cases where the methods have previously been
>>> published as scientific articles. This provides a standard reference for
>>> the software, and an opportunity for researchers who spend time writing
>>> open-source software to get credit for the work they are doing.
>>>
>>> I propose to submit articles to JORS, based on newer additions to
>>> libraries (particularly Dipy, but maybe others as well?), a PR, or series
>>> of PRs that contribute substantial new features, or a substantial upgrade
>>> to previous features. This addresses two major challenges:
>>>
>>> The first is the challenge we face in incentivizing new contributors to
>>> join us. This is because if a standard reference article has already been
>>> published for the software, their newer contributions might not get them
>>> credit when this standard reference is cited. For example, Dipy
>>> contributors who joined the project after 2014 get no credit when that
>>> paper is cited.
>>>
>>> Two recent examples from Dipy are the work that Stephan Meesters has
>>> done on contextual enhancement and fiber-to-bundle coherence measures
>>> (still in progress in #828), and the work Rutger Fick is doing implementing
>>> Laplacian regularization for MAP (#740). These are both implementations of
>>> previously published scientific work (in these cases, work that these
>>> contributors have been involved in). As you can all appreciate, the effort
>>> of implementing these methods in Dipy is substantial, and we want to
>>> incentivize these efforts and reward them. A journal article that other
>>> researchers can cite is common currency for that.
>>>
>>> Another challenge we face is incentivizing code review. This is a
>>> serious bottle-neck for progress. I propose to add code reviewers as
>>> authors to these papers. This will incentivize the substantial effort that
>>> goes into reviewing code. JORS allows author contributions to be specified
>>> and we would clearly designate these kinds of contributions, so as to not
>>> diminish from the effort made by the primary author of the code. But I
>>> would like to include the people doing code review (if only because I have
>>> spent a lot my own time in code review...). I hope that this will allow
>>> people to justify spending time doing this crucial part of the work, and
>>> energize our code review process a bit.
>>>
>>> I'd be happy to hear what people think about this idea.
>>>
>>> Cheers,
>>>
>>> Ariel
>>>
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>
>>>
>>
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>>
>>
>
>
> --
>
> -----------------------------------------------------------------------------------------
> Kong Xiangzhen
> State Key Laboratory of Cognitive Neuroscience and Learning,
> Beijing Normal University,
> Beijing, China, 100875.
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20160414/76d65b01/attachment.html>