Repository forks and authoritative project ?

[jcfr]

@ilwoolyu

To streamline the maintenance, one option would be to:

1. delete the fork in the NIRALUser organization
2. transfer this repository to the NIRALUser organization
3. have you (@ilwoolyu) re-fork the transferred project

This would have the advantage of having the project maintained under the umbrella of an organization and would help manage access right et al.

Alternatively, if you intend to be fairly active on the project, we would create pull-request against your current project.

Let us know what you think,

cc: @juanprietob @Connor-Bowley @bpaniagua @vicory

For reference, here is the fork graph associated with this project:

[ilwoolyu]

Thanks for the suggestions. I guess the current issue is the package dependency on this toolbox in GROUPS and some other tools. MeshLib is designed for quick prototyping in my research and has been used in my other projects. I would suggest to keep this project from reforking and get rid of the MeshLib dependency in GROUPS for several reasons:

• Many of my projects depend on MeshLib that has been maintained until now albeit not very often.
• MeshLib has its own implementation of mesh handling, most functionalities of which very likely exist already in the VTK library. This could be redundant and inconsistent.
• The dependency in GROUPS is mostly on file I/O and mesh traverse. I think a transition to the VTK library would not be that knotty.