Both if we do the transfer to the vetmed organization (#124) or not, I recommend the following strategy to keep a sane repository with proper versioning and license/copyright/authorship assignation:
Discuss with Christian and Ram (original authors) if we can take over the project (either in vetmeduni organization or as a @robmaz project). Otherwise, maybe this should live in a private repository for use at the Institute (e.g., @robmaz can transfer it to gitlab and keep it private) - or another option is to rename the project and say that it is a fork from the distmap version (e.g., mapdist - a mapping-pipeline distributed based on distmap).
If we can take over, we should assign an open-source license (MIT or BSD is my recommendation), an AUTHORS/CONTRIBUTORS file (including Christian/Ram, @robmaz and myself), and a MAINTAINERS file (that should have an entry with original maintainer, Ram, and the current ones, @robmaz and myself). If we rename the project as a fork, we should do the same but with a different authorship assignation for the previous developers/maintainers/authors.
If we can take over, create two frozen branches for the linux/macos versions and tag them as the original code. We should add a LICENSE file with the original license (if any) and an AUTHORS file with Christian/Ram. And we should specify in the README that the versions are historical code for comparison purposes. If we rename the project as a fork, we shouldn't do this as we cannot distribute it as our project.
Both if we transfer the repo to vetmeduni or keep it here, we should clean the history by using git-squash - I can do that as I am familiar with the pipeline. We should give proper description to commits, join some of them and keep everything as explanatory as possible. Once this is done, we should setup guidelines for PR naming and merging, and we should follow them: and if someone mess it up, then we can have a beer to the other maintainers as a fine! 🤣
Once this is done, we should tag the clean version as 3.0.0-${state} where ${state} should be alpha/beta/rc (depending on how much testing @robmaz has done). In case we do not take over and start as a fork, we can either have it as 0.1.0 (and keep increasing the minor/patch version until the code is highly tested and mature enough) or 1.0.0-${state} if we want to release right away.
We can also invite Ram to become a maintainer in both cases, if he is interested in such a thing. What do you think, @robmaz? I would like to have this as a way to introduce good practices here and in other projects!
Both if we do the transfer to the vetmed organization (#124) or not, I recommend the following strategy to keep a sane repository with proper versioning and license/copyright/authorship assignation:
3.0.0-${state}where${state}should be alpha/beta/rc (depending on how much testing @robmaz has done). In case we do not take over and start as a fork, we can either have it as0.1.0(and keep increasing the minor/patch version until the code is highly tested and mature enough) or1.0.0-${state}if we want to release right away.We can also invite Ram to become a maintainer in both cases, if he is interested in such a thing. What do you think, @robmaz? I would like to have this as a way to introduce good practices here and in other projects!