Consider supporting arbitrary nesting of groups

For consideration...

As I understand it, GitLab supports arbitrarily nested groups.

Our standard practice is allocate resources "flat", independent of project structure. My observation is that with GitLub, "flat" means that we're creating a group for each project under the "eclipse" group, e.g., "/eclipse/dash", and all repositories associated with the corresponding project are created in that group.

We adopted the "flat" notion quite some time ago to mitigate the amount of work and negative effects of having to move resources following project restructuring (e.g., when projects move from one TLP to another).

That GitLab provides support for arbitrary nesting of groups, sets up automatic redirects for moved repositories, and otherwise provides what I assume are reasonably good management tools, presents an opportunity to reconsider the policy.

I'm thinking that a default position is to have a distinct group for each project to mitigate the risk of confusion regarding which project owns which repository (and by extension which developer has commit rights on which repository), but allow that project groups can themselves be arbitrarily organized into groups.

From the @webmaster workload perspective, I believe that we'll have to manage expectations that the webmaster will not be able to continuously tweak and move groups around.

Would allowing arbitrary nesting introduce significant work in the provisioning process? Are there scenarios that are particularly onerous?

For one, at very least, keeping track of arbitrary nesting and what goes where will require some additional thought/management/tracking.

@cguindon are permissions assigned at the group level or the repository level? Does the script that manages committer and project leads care about the group nesting?