I tried to create the group Slicer on gitbab.com and realized it was not available.
Background
While working on addressing issues related to use of Plastimatch in the SlicerRt extension, I realized a fork of plastimatch was currently used (see here)
I plan on consolidating the change and submit a merge request to the upstream repository.
That said, waiting these are integrated, I would like to have a staging area on Gitlab for the changes. Similarly to what we already do with VTK, ITK, … in the Slicer · GitHub organization.
Follow up questions
Generally speaking, should we create fork of Gitlab project on GitHub ? I think we should as it streamline integration of changes in the upstream project.
In this particular case, since Plastimatch is made available in Slicer through SlicerRt, should we create the SlicerRt group on Gitlab ?
I understand github forks, because it is very convenient to find all the projects in the world in one place. It is not clear to me how gitlab fork can be useful. Developers do not expect to find projects on gitlab, we do not want to get pull requests or bug reports from gitlab, we would not want any discussions to take place there, etc. Having a placeholder Slicer organization could make sense (to avoid any confusion by someone else taking that organization name and maintaining an official-looking fork, then not taking care of it properly), but other than that I would not bother much with gitlab.
Having a placeholder Slicer organization could make sense
I created one for SlicerRt and added you as owner. I also updated the description to indicate development is happen on GitHub and added a link to it. See SlicerRT · GitLab
Since the Slicer one is not available, I couldn’t create one.
plastimatch
I will create a placeholder for plastimatch organization on GitHub along with a plastimatch project, and will fork it into the SlicerRt organization.
These have explicit descriptions indicating that GitLab is where all development is happening.
In https://github.com/plastimatch/plastimatch I also provided guidance on how to name branches in forks (aka “staging area” waiting changes are integrated in upstream project)