NA

There are several ways to contribute to oce. These range from making bug reports and suggesting new features, through proposing code/documentation changes, all the way to providing patches or pull requests for new code/documentation. It is important to note that contributions nearer the start of this spectrum are more common than those nearer the end, and that they can be just as valuable. Oce is meant to be a tool to help oceanographers in their work, and so the oce developers are always interested to hear about areas for improvement. Not all ideas will be taken up, of course, since practicality is at the heart of oce. The developers weigh benefits against costs, and they are busy with their own science, so they tend to focus their time on important things that can be handled easily.

In the history of oce, very few users have suggested gratuitous or bad code changes, so there seems to be little reason to describe here the usual sort of suggestions, beyond the obvious: (a) communicate with the developers before suggesting a large code change; (b) use github resources such as pull requests to submit suggested changes; (c) test any suggested code not just on your data but also by running the ‘check’ procedures in R; and (d) pattern your code on that used in oce, with respect to variable names, spacing, etc.

The oce developers are scientists, not programmers, and this means that they are quite aware of the need to keep data private until publication. For this reason, users who report bugs or request the support of a new type can be sure that emailing (or otherwise providing) data to the oce developers will not put their data in jeopardy. An issue reporter should upload data to github only if they are sure that the data are public, for once something goes into github, it is likely open forever.