Ecography is a well-known outlet for software tools in spatiotemporal ecology. Authors submitting manuscripts describing new software for ecological analyses must follow the below guidelines. Manuscripts not conforming to these formatting requirements will be returned without review.

 

Software Availability and Licensing

Only non-commercial and free software is eligible for software notes (SN), and open source software is strongly encouraged. The same applies to all external third-party software (e.g. packages, libraries, platforms) required to run the proposed software. The software should follow an established licensing type, and the license should be clearly stated in the software and SN. If the software runs on a modular system (e.g., R), novel functions that are implemented in the software should be clearly distinguished (e.g. bold typeface) from functions that are dependent on external software (e.g. packages and libraries).

 

Structure of Software Notes

Ecography does not enforce a specific format for software notes. However, all SNs should describe the software's background and its application in the field. In addition, the SN should detail the main methods and features of the software, and provide a short applied example. The requirements for each element are laid out below.

 

Background. The SN should clearly describe the relationship of the software to existing software in the field. Does it supplement, supercede, or compete with existing software packages? What new features does it provide to users (e.g., a coherent analytical framework, novel functions or methods, increases in speed and stability)? If the software is part of a modular system (e.g., R, Python, Julia, Matlab packages), it should describe which packages (and their versions) are used by the software, what functionality is used from them, and the specific contribution of the package. Imported packages, and their versions, should be cited using the appropriate references.

 

Methods and features. If the software uses methods that are tested and well-described in the literature, a short well-referenced discussion of the relevance and use of the methods is sufficient. If the software implements new methods, the SN should be expanded to include a rationale and description of these methods, preferably including simulation analyses, a comparison to existing methods, and possibly a small empirical analysis.

 

Example. The SN should contain an example of the most common uses of the software. In addition, the software should be distributed with an example to be run "out of the box", so reviewers and readers can run the example themselves, without having to acquire extra data. If data are needed to run the example, it should be provided as supplementary material. The example results should be presented graphically. If the software has graphical functions, default settings are preferred.

 

Peer Review

SN reviewers must have full access to the software, its documentation and source code if the software is opensource. Authors should expect the software to be fully tested by reviewers, using the provided example data and possibly additional datasets. Reviewers’ comments, suggestions and issues will be taken into account for editorial decision on the SN. Critical bugs and major software flaws will cause the SN to be rejected for publication.

Details for obtaining the software and/or source code upon submission (such as a download link or github/SVN repository) should be stated clearly in the software note, along with directions for obtaining the existing software documentation (technical description, help file, etc), and compiled binaries where applicable. If the final version is not publicly available for use at the time of submission, the submission files should include the newest version of the software, so that reviewers can run the example code. In this case, the cover letter should also indicate an approximate date for when the software will become public available, so publication of the SN can be delayed until that date.

 

Versioning

All software published in SN should have a version number, and the major version number should be listed in the SN (i.e., "EcoSoft 1", if the full version number is "EcoSoft 1.3.4-2"). The version number must be at least 1.0 for consideration as a SN.

We suggest semantic versioning, where incrementing a major version number indicates breaking backwards compatibility, meaning the SN example codes may break for higher version numbers.

 

File formats

Files for peer review can be uploaded as a Word document with embedded figures, or as a pdf. However, accepted manuscripts should be uploaded for editorial production as a .docx file with figures as separate image files.