MarcoHannemann
commented
1 year ago I think this covers two aspects - Internal documentation i.e. code documentation and public documentation.
For internal documentation I would suggest as first steps:
1) Update the README.txt with minimal explanations how to use this program. This will be also useful for collaborators.
- Requirements & installation (python3.9, clone repo, set up venv etc.)
- How to run (run sbat.py from console or IDE) For now this should be enough, more details could be added later
2) Code documentation. Before setting up a public doc, #10 should be addressed for internal development. This is crucial for potential refactoring of the code.
Forms of public documentation could be discussed later evolving from there. I guess a lot of things can change until release/publication, so this should not be done to soon.
The methodological and scientifical aspects will be covered by the the publication of an article I assume. The module documentation should cover especially the technical aspects, such as input data requirement, preprocessing, parameter explanation etc.
Until now, documentation is very poor. Some issues need to be discussed, e.g a github.io page On the other hand we want to publish the code, which is somehow also a documentation
Just for the beginning I drop the talk I gave at BGR at the beginning of February
internes_seminar_01032023.pptx