<div dir="ltr">Hi Ariel,<div>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 <a href="https://zenodo.org/">Zenodo</a> 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).</div><div><br></div><div>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:</div><div>- Everyone contributing to nipype gets credit in the form of citations</div><div>- There is one publication which makes citing easy (compare to Freesurfer <a href="https://surfer.nmr.mgh.harvard.edu/fswiki/FreeSurferMethodsCitation">https://surfer.nmr.mgh.harvard.edu/fswiki/FreeSurferMethodsCitation</a>, also consider that some journals limit the number of references)</div><div>- There is no overhead of writing, submitting, and revising a manuscript on top of developing and revising code</div><div><br></div><div>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 <a href="http://f1000research.com/articles/2-192/v2">http://f1000research.com/articles/2-192/v2</a> 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.</div><div><br></div><div>I hope this helps!</div><div><br></div><div>Best,</div><div>Chris</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 12, 2016 at 8:26 AM, Ariel Rokem <span dir="ltr"><<a href="mailto:arokem@gmail.com" target="_blank">arokem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi everyone, <div><br></div><div>In a conversation I had with Rafael recently, he mentioned to me the Journal of Open Research Software (<a href="http://openresearchsoftware.metajnl.com/" target="_blank">http://openresearchsoftware.metajnl.com/</a>) 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.</div><div><br></div><div>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:</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div><div>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.</div></div><div><br></div><div>I'd be happy to hear what people think about this idea. </div><div><br></div><div>Cheers, </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Ariel</div></font></span></div>
<br>_______________________________________________<br>
Neuroimaging mailing list<br>
<a href="mailto:Neuroimaging@python.org">Neuroimaging@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/neuroimaging" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/neuroimaging</a><br>
<br></blockquote></div><br></div>