To keep our research well-organized and impactful, in the 3D geoinformation group we follow some simple shared practices for handling our code and data. These practices help ensure that our work is accessible, understandable, and useful to others — both in and outside the group. As a research group, we’re committed to open science, and as part of that, all research-related code and data should be made open-source whenever possible.
We also follow the FAIR principles for managing research outputs, which means we should aim to keep our code and data:
- Findable: Easy for others to locate.
- Accessible: Shared openly (unless the related project requires otherwise).
- Interoperable: Using well-documented open formats and standards so your work plays well with others.
- Reusable: Properly documented and licensed so it’s simple for others to build on.
It is important to keep in mind that the TU Delft Research Data Management Policy recommends that any research output should align with these principles for at least 10 years after the end of the research project.
Taking the above into consideration, the following guidelines aim to make your work smoother and help you contribute to open and responsible science. Let’s dive in!
1. Code Management
- Storage: Store all the research- and project-related code under the 3D geoinformation GitHub organization. If you are collaborating with a company or other organization you may also store your code under their repositories, provided that they are publicly accessible. Do not use personal GitHub accounts to store code related to group projects.
- Public or Private: Preferably all code should be publicly available. However, you can keep your repositories private within the group if there are privacy concerns or other reasons (e.g. unpublished research).
- Version Control: Always use version control (e.g. Git) for individual and collaborative work to keep track of changes.
- Documentation: Properly document your code with sufficient comments that explain how things work and why specific decisions were made. Always include a README file in your project that describes:
- What the project is about.
- How to set it up.
- How to use it (with examples if possible).
- Reproducibility: Always include a List of Dependencies to ensure others can easily replicate your computational setup. Depending on your programming language and system consider virtual environments or docker images.
- Findability: Add a webpage for your project at the 3D geoinformation website with a description of your project and a link to your code. Additionally you can publish your code and data via the 4TU.ResearchData repository. By doing that, you obtain a DOI for that dataset/software which you can then cite. Please have a look at the section "Connecting with Git" specifically for getting a DOI badge on your Git repository. Additionally, you can even “reserve” the DOI before you officially publish the dataset/code (if, for instance, you want to mention the DOI in a publication but you are not yet fully ready to share the dataset/code). Please have a look at the ‘Reserve a DOI’ section.
- Good Practices: Have a look at these guidelines about how to maintain a healthy repository but more importantly make sure that you read the TU Delft Research Software Policy.
2. Data Management
- Storage: Store all important data and code on the university’s secure servers or other backup systems offered by ICT. Do not rely solely on your personal device or personal hard drives.
- Findability: If specific data are critical for reproducing your results, ensure they’re publicly accessible and that they remain accessible after you finish your project or leave. Same as with the code, you should create a DOI for your data. Please have a look at these guidelines for instructions on how to create a DOI for your data and how to cite it.
- Documentation: Include a metadata file that explains what each variable means, how the data were collected, and any preprocessing steps.