compare with https://github.com/tonic-team/Tonic-Research-Project-Template

[jcolomb]

Slightly different objective, it would be great if we could combine the two approaches.

[jdeplaa]

Thanks a lot for the suggestion and your great talk yesterday! I will have a look at your template and see which aspects we could combine to create a template that is useful for a broader range of research fields with more guidance than we currently have in this template. There is certainly a lot of synergy possible :)!

[jcolomb]

I would also be good to go the other way around, what part of our template may be used for publication. So far our hypothesis was that data and code would be published separately.
It makes sense to separate the two when one is working, as data and code often needs different version control system. On the other hand, it may be interesting to publish it together, to facilitate reproduction of the results and things like codecheck...

[jdeplaa]

Yes, separating data and code is an interesting issue, and depends largely on the situation.

If you have a very simple code, let's say a script that reads in a data table and creates a plot, separating the table from the script would not make sense. If the script is meant to create one specific plot, then it is best to keep the data table close to the script in your directory structure.

On the other hand, if you have a piece of software that can do a particular analysis on multiple (similar) datasets, it is best to separate the two. Maybe the researcher could even consider publishing the code separately as a tool on Github (or elsewhere).

Between the two options above, there is a gray area. Sometimes a researcher writes a script with the intention to process one particular dataset (similar to option 1), but with a bit of effort, this script could be converted into a tool capable to process other data as well (option 2). This could lead to some discussion what to do.

Also, there is another class. We have, for example, a spectral modelling tool that needs an atomic database. In this case, the database is an integral part of the software package and are distributed together.

On Tuesday, I actually saw a classification scheme for software with 4 different classes in another RDM meeting. And even there, I thought 1 class was missing... It definitely requires more thought. I will see if I can dig up the definition of the 4 classes from the presentation.

[jdeplaa]

To follow-up on my previous post, this is the reference that I saw on Tuesday to the software engineering guidelines of DLR (https://doi.org/10.5281/zenodo.1344612). They identify four classes of software to which they associate different quality standards. These are the classes:

Class 0: Scripts to process data for a publication
Class 1: Software that students develop during studies
Class 2: Large research frameworks which are developed by a majority of a department
Class 3: Mission critical software, for example, in context of aircraft, autonomous vehicles or space missions

I wonder whether there should be a class 1.5 in this list for software developed by one or a few staff members. But anyway, this could be an interesting read how to deal with different types of software.