BAMOS Vol 30 No. 4 2017 | Page 37

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