BAMOS
Dec 2017
time you change your code, to make sure you haven’t broken
anything. Many people add a little code coverage badge to the
README file in their code repository using Coveralls, to indicate
how much of the code is covered by the tests.
Academic publishing
To make sure you get the academic credit you deserve for the
hard work associated with releasing and maintaining scientific
software, it’s important to publish an academic article about your
software (i.e. so that people can cite it in the methods sections
of their papers). If there isn’t an existing journal dedicated to
the type of software you’ve written (e.g. Geoscientific Model
Development), then the Journal of Open Research Software or
Journal of Open Source Software are good options.
This is obviously a very broad overview of what’s involved
in packaging and releasing scientific software. Depending
on where you sit on the scientific code/scientific software
spectrum, not all of the things listed above will be necessary.
For instance, if you’re writing code that only needs to be used by
a group of five people working on the same computer system,
hosting on GitHub, testing using Travis CI and the use of GitHub
issues and gitter for discussion might be useful, but perhaps not
packaging with PyPI or a journal paper with the Journal of Open
Research Software.
A great resource for more detailed advice is the Software
Sustainability Institute (their online guides are particularly
useful). It’s also worth checking out the gold standards in
the weather/ocean/climate space. In terms of individual
researchers releasing their own software, this would be the eofs
and windspharm packages from Andrew Dawson. Packages
like MetPy (University Corporation for Atmospheric Research/
Unidata), Py-ART (Atmospheric Radiation Measurement Climate
Research Facility) and Iris/Cartopy (UK Met Office) are good
examples of what can be achieved with some institutional
support.
37