=Paper=
{{Paper
|id=Vol-1686/LightningTalkPaper18
|storemode=property
|title=None
|pdfUrl=https://ceur-ws.org/Vol-1686/WSSSPE4_paper_15.pdf
|volume=Vol-1686
}}
==None==
https://ceur-ws.org/Vol-1686/WSSSPE4_paper_15.pdf
Lightning Talk: “I solemnly pledge”
A Manifesto for Personal Responsibility in the Engineering of Academic Software
Alice Allen1, Cecilia Aragon2, Christophe Becker3, Jeffrey C. Carver4, Andrei Chis5, Benoit Combemale6, Mike Croucher7,
Kevin Crowston8, Daniel Garijo9, Ashish Gehani10, Carole Goble11, Robert Haines11, Robert Hirschfeld12, James Howison13,
Kathryn Huff14, Caroline Jay11, Daniel S. Katz15, Claude Kirchner16, Kateryna Kuksenok2, Ralf Lämmel17, Oscar Nierstrasz5,
Matthew Turk15, Rob V. van Nieuwpoort18, Matthew Vaughn13, Jurgen Vinju19
1
University of Maryland, USA
2
University of Washington, Seattle, USA
3
University of Toronto, Canada
4
University of Alabama, USA
5
University of Bern Switzerland
6
IRISA, Rennes, France
7
University of Sheffield, UK
8
Syracuse University, USA
9
Technical University of Madrid, Spain
10
SRI, Menlo Park, USA
11
The University of Manchester, UK
12
Hasso-Plattner-Institut, Potsdam, Germany
13
University of Texas, Austin, USA
14
University of California, Berkeley, USA
15
University of Illinois, Urbana-Champaign, USA
16
INRIA, Le Chesnay, France
17
Universität Koblenz-Landau, Germany
18
Netherlands eScience Center, Amsterdam, The Netherlands
19
CWI Amsterdam, The Netherlands
Abstract— Software is fundamental to academic research work, used in an academic context (i.e., for research, not administra-
both as part of the method and as the result of research. In June tion). The group was carefully picked to be broad in its range
2016 25 people gathered at Schloss Dagstuhl for a week-long Per- of disciplines (including Astronomy, Social Sciences, Biology,
spectives Workshop and began to develop a manifesto which Chemistry, Computer Science, Physics, and Humanities), roles
places emphasis on the scholarly value of academic software and
(including computer science researchers, general and specialist
on personal responsibility. Twenty pledges cover the recognition
of academic software, the academic software process and the research software engineers and systems administrators) and
intellectual content of academic software. This is still work in career stages (from PIs and institute heads to PhD students and
progress. Through this lightning talk, we aim to get feedback and postdocs). Despite its ambiguous title, “Engineering Academic
hone these further, as well as to inspire the WSSSPE audience to Software,” the workshop was on the Engineering of Academic
think about actions they can take themselves rather than actions Software (not software for engineers).
they want others to take. We aim to publish a more fully devel- A Dagstuhl Perspectives Workshop results in a Manifesto.
oped Dagstuhl Manifesto by December 2016. The open science and research software communities have
Index Terms—software, manifesto. been very active in creating manifestos: the Science Code Man-
I. INTRODUCTION ifesto [2], Karlskrona Manifesto for Sustainability Design [3],
the Reproducibility Manifesto [4], and Principles for Software
Software is fundamental to academic research work, both as Citation [5], FAIR data [6], and so on. Why do we need anoth-
part of the method and as the result of research. With the ad- er Manifesto?
vent of artifact evaluation committees of conferences, journals First, our manifesto is to be less about what others should
that include source code and running systems as part of the do, and more about what we, as individuals, should do. That is,
published artifacts, as well as the increasing push to reproduci- it is more in the style of a personal responsibility pledge like
bility, we foresee that software will only increase in importance those on open access [7] and open peer review [8]. It is easy for
as part of the academic process. us to declare “the community should do X”, “funding panels
In June 2016, 25 people gathered at Schloss Dagstuhl for a should do Y” and “promotion committees should do Z”, while
weeklong Perspectives Workshop [1] to produce a roadmap conveniently forgetting that we are the community, we are the
towards future professional software engineering for software- panelists, we are the committee members.
based research instruments and other software produced and Second, our manifesto places emphasis on the scholarly
value of academic software. For some of our group, engineer-
This work is licensed under a CC-BY-4.0 license. ing academic software is chiefly a means to an end – to pro-
duce robust and reliable software as an instrument as part of a focused on developers. Pledges to recognize software are self-
wider research investigation. For others the software is the end evidently responsibilities to be borne by users. Perhaps more
in itself – the software is the research. In both cases the soft- implicit are the benefits to users embedded in the software de-
ware has scholarly merit. velopment processes. Open source (10) and documentation
(11) enables feedback and potential community engagement
II. THE DRAFT PERSONAL MANIFESTO during critical design stages, and examples and instructions by
Currently at 20 there are too many pledges so we are active- their definition must embed an understanding of use cases and
ly working on reducing the number and simplifying the mes- usability pitfall. Improving transparency of process, and analyt-
sage. At the WSSSPE4 meeting, through this lightning talk, we ic consideration of future use cases (12, 13, 14) are valid user-
aim to get feedback and contribute to this process. centered approaches and (15, 16) directly speak to assessing
Table I presents our pledge list organized into three broad user needs and crafting appropriate interventions.
areas: (1) recognition of academic software, (2) academic soft-
ware development processes and (3) the intellectual content of III. NEXT STEPS
academic software. Each pledge should be actionable by an This is still work in progress. We recognize that 20 pledges
individual. Each pledge has a story that will be developed in is roughly twice as many as desirable, and that the pledges need
the full manifesto. to be succinct and easy to understand and adopt, more in the
style of the Reproducibility Manifesto [4]. We are currently (1)
TABLE I. MANIFESTO DRAFT PLEDGES looking to merge pledges where feasible and (2) exploring the
use of roles to structure them; for example “When I develop
A. Recognition of academic software software ...When I write research papers ...When I evaluate
1 I will properly cite software used to produce my research results colleagues ...” and so on. At WSSSPE we intend to run an
2 I will point out improper or missing citations to software when I am online vote on the pledges structured on roles.
reviewing publications. We aim to develop the full manifesto by December 2016
3 I will make explicit how to cite the software I make available. and publish it as a Dagstuhl Manifesto [9]. We intend that
4 I will recommend software experts for funding agencies to include in
their review processes.
community groups promote its contents among researchers and
5 I will invite developers of software that enables my research to be co- research software engineers, and we use it to influence decision
authors on my papers. makers to enable our respective communities to execute these
6 I will recognize software contributions in hiring and promotion within pledges with moral and financial support.
my institution.
7 I will recognize software contributions at conferences, e.g. dedicated ACKNOWLEDGMENT
sessions, and prizes.
8 I will support and publish in journals that recognise software contribu- We thank Schloss Dagstuhl – Leibniz-Zentrum für Informatik
tions. GmbH for supporting and hosting Workshop 16252.
9 I will contribute to sustaining the software I rely on for my research.
REFERENCES
B. Academic software development processes
[1] Engineering Academic Software, Dagstuhl Perspectives
10 I will develop software as open source right from the start whenever Workshop 16252, 19–24 June 2016,
possible.
http://www.dagstuhl.de/16252 last accessed 07-Jul-2016
11 I will document my academic software for users with instructions and
examples. [2] Science code manifesto http://sciencecodemanifesto.org/
12 I will package, release and archive versions of my software [3] Karlskrona Manifesto for Sustainability Design
13 I will consider and document the sustainability of my research software. http://sustainabilitydesign.org/
14 I will publish how I organize and run my software projects
[4] Reproducibility manifesto
15 I will match software engineering practices I recommend to the needs
http://lorenabarba.com/gallery/reproducibility-pi-manifesto/
and resources of projects.
16 I will help scientists improve the quality of their software without passing [5] A.M. Smith, D.S. Katz, K.E. Niemeyer, FORCE11 Software
judgment. Citation Working Group. (2016) Software citation principles.
PeerJ Preprints 4:e2169v3
C. The intellectual content of academic software https://doi.org/10.7287/peerj.preprints.2169v3
17 I will acknowledge that source code is a legitimate part of the academic [6] M.D. Wilkinson et al. The FAIR guiding principles for scientific
discourse. data management and stewardship (2016) Scientific Data 3,
18 I will publish the intellectual contributions of my research software. Article number: 160018 (2016) doi:10.1038/sdata.2016.18
19 I will distinguish the intellectual contribution of my software from its
service contribution. [7] Open access pledge http://www.openaccesspledge.com/
20 I will examine the source code of academic software contributions and [8] Open science peer review oath
encourage others to do so as well. http://f1000research.com/articles/3-271/v2
[9] Dagstuhl manifestos
The pledges A and B (1-16) are targeted at both developers http://www.dagstuhl.de/en/publications/dagstuhl-manifestos
and users of academic software; pledges C (17-20) are more