[Neuroimaging] Journal articles based on PRs

Tue Apr 12 17:49:17 EDT 2016

Hi Chris,

Very helpful points.

Full disclosure up-front: I have now also volunteered to serve as an
associate editor on JORS. Mostly because I realize that in advocating for
this, I am pushing the burden further down the stack to the people who will
now need to edit/review our papers... This is not a paid position, so I
really don't feel like I have a very strong conflict of interest here, but
it's worth mentioning. They also might not take me, making this even less
relevant.

On Tue, Apr 12, 2016 at 1:47 PM, 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
>

Yep - I like the Zenodo solution. We should consider going that route for
Dipy as well.

I think it's a good idea, on top of writing more papers.

For large-ish contributions to Dipy, much of the paper will already get
written during the PR process - we usually require rather well fleshed-out
examples, so there are already Figures to include in the paper, and some
explanations of the methods and their specific benefits and issues. A lot
of that can be redirected into the potential software contribution paper.

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.
>

Agreed! I don't think any one here can effectively endorse, let alone
enforce, choice of any journal, and authors should definitely choose
according to their needs and interests. Here's a more complete list to
choose from compiled by Neil Chue Hong, who happens to be the
editor-in=chief of JORS, but is also the founding director of the UK-based
Software Sustainability Institute :
http://www.software.ac.uk/resources/guides/which-journals-should-i-publish-my-software

We should publish in all of these! :-)

That said, I don't mind discussing the merits and drawbacks of different
journals. For example, there have been recent discussions about this topic
among the vision science community (on email lists that do not have public
archives, and contact me off-list if you have). One of the things that
emerged is that publishers respond when researchers can agree what they
want. Ultimately, if we need to, and no publisher from that list responds
to our specific needs as s community, why not start our own journal?

But you're right that this is a discussion that authors of specific
contributions (the authors of the code in the PR, and the code reviewers
that reviewed the PR) should have for each contribution. We would want to
make sure before we submit that the journal is willing to review and
publish a paper that covers a part of an existing software (JORS would -- I
checked).

Cheers,

Ariel

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20160412/95a78281/attachment.html>