Through working with scientific code, we agree that scientific code needs to be treated as a genuine research output.
Code is science. Historically, science has been reviewed by its peers to validate it before being published. In modern times, computer code forms part of scientific analysis, but it is rarely shared and reviewed.
This manifesto is for anyone who deals with code in a scientific setting, including publishers, researchers, research software engineers, and administrators.
Ideally scientific code should be released by the time of publication, under an open source licence, such that anyone may download, review, re-use and expand upon it.
Follow good practices from the start of the project; don’t build up technical debts that are hard to fix later. This generally means testing, writing documentation, instructions on how to run and maintain your code, and following modern development practices.
Code published in journals should be peer reviewed. Ensure that at least one reviewer understands code well enough to evaluate it critically, as well as domain experts who can comment on the specific scientific area.
You don’t have to be a computer scientist or professional software developer to write code, and your code doesn’t have to be perfect in order to be published. If code produces paper-ready results, the code too is paper-ready.
There is always room to improve your skills — some intensive training courses such as Software Carpentry only take a day or two.
Be nice and provide constructive criticism, when reviewing recognise that people make mistakes in good faith.
Software should be [cited](You don’t have to be a computer scientist or professional software developer to write code, and your code doesn’t have to be perfect in order to be published. If code produces paper-ready results, the code too is paper-re) and acknowledged as scientific output. This means you should cite your sources as well as ask to be cited yourself.