Sounds good -- I'd be up for committee work. Definitely +1 on a paper for time justification, etc.

On 20 January 2018 at 14:03, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi all,

TL;DR, let's write the long journal paper on SciPy that we've wanted for a while, let's form a small committee to coordinate, and get it out the door in 2-3 months.


Motivation
---------------
(credits for most of this text: Evgeni)

Many scipy contributors' day jobs are in academia. Bibliometry -- papers in
refereed journals and citations of papers by other papers -- is one of the main
performance indicators in most academic establishments. Since we do not
generate papers, scipy contributions are all but invisible for the purposes of a
contributor's annual report. Of course, details vary wildly; in many cases a
contributor manages to balance their time, or to argue common sense with their
superiors, or get an approval for scipy work, or just ignores the issue
altogether -- but sooner or later there is a form to be filled or boxes to be
checked, and scipy contributions simply do not fit in. A peer-reviewed journal paper on scipy will help contributors get the academic credit they deserve.

We can write *the* paper for SciPy 1.0, with overall project structure, goals, etc., and for specific features/modules a focus on say the last 3 years.


History
----------
For SciPy 1.0 we had three targets on the publicity/credits front: an interesting release announcement, interesting blogs/stories (NumFOCUS blog, Hacker News, etc.) and a paper. We didn't have the bandwidth for a paper in the end, the rest was successful.

[1] is a previous announcement on this list about writing (a) paper(s) on SciPy. We wanted both "short papers" to cover one or two releases (target journal JOSS) and a full paper as the authoritative reference for SciPy.

We had an earlier attempt for a "short paper", it's mostly written but has stalled (see [2]). We ran out of steam on that one. To avoid that this time around, it would be good to have a clear public plan, target dates, and a small committee rather than one person to drive things forward.


Proposal
------------
Here's a proposal for all aspects of this exercise that I can think about now. Some parts stolen from the AstroPy paper [3] (because their process worked quite well).

Form a small coordination committee of 3-5 people that set up the paper structure, move things along when parts stall, propose/take decisions as needed, invite co-authors, and organise paper submission/rework.

Paper writing to be done by whoever volunteers for a section, not just the coordination committee. First outline/structure to be done by committee, which then asks for review of structure and volunteers for section writing.

Scope: a 6-10 page paper, covering history, package scope and structure, community/organisational aspects, key features and recent enhancements per module, and roadmap.

Authorship: anyone who made a substantial contribution in the history of the project. Here "substantial" is interpreted as anything beyond a one-line doc fix. Rationale: better to be too inclusive than exclusive. Sign-up via a web form, we send the link to that form to all email addresses in the commit history till v1.0.

Author order (details tbd by committee):
1. The SciPy Developers
2. Maintainers, paper writers, other key contributors - in order of contribution level
3. All other authors - alphabetically ordered

Submission target: mid-April, to either PeerJ Computer Science or Journal of Open Research Software (tbd by committee).

Comments? Volunteers for committee?


References
----------------
Cheers,
Ralf



_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@python.org
https://mail.python.org/mailman/listinfo/scipy-dev