So we currently have toplevel groups in gitlab labelled dev, client, accounting, documentation. One of the reasons is that all members have access to the dev group, only core members, have access to client, etc.
I’m thinking that it may be a good idea to create newcomers, core, etc. groups, and use them like we do for our github teams. It would add a nice symmetry with github, and make the groups user management clearer. Then for the dev, client, etc. groups, we can add group access - eg. opencraft/newcomers would have maintainer access to opencraft/dev, but not to opencraft/client.
@swalladge Good idea, now that we move more and more to gitlab, it does make sense to have a better approach for newcomers vs core.
Not sure what you mean by semantics, but that’s pretty much the equivalent of “admin access” currently. The people in that group are the “general” managers (Braden and me), plus the recruitment cell managers who need the right to onboard newcomers.
@swalladge If we would have one and we can assign the relevant people there, that would make the PR reviews and other stuff easier in the future if we start actively working on that (I think, but I may be wrong).
Thanks for this @swalladge. I think that when we started with GitLab, it didn’t let you assign Groups as members of groups, so we were kind of forced to set things up this way. I was annoyed by always having to add and remove users from multiple groups. I guess at some point they implemented the feature of adding groups to groups, so now we can do it this way which makes way more sense
I would even suggest we go further and now remove the dev and docs groups, and just combine their repositories into the top level opencraft project, but it’s probably too late / inconvenient to do that at this point.
@antoviaque created it recently, so I guess he wanted to keep it separate from the dev group and grant access only to people who will work on it. @antoviaque, could you confirm?
In addition there were discussions and a code draft to move the deployment to GitLab CI, so that the software be automatically deployed to production after successfully merging a MR. This happens in some of the accelerated projects. If this is done for the accounting project, then the GitLab accounting group would decide who has the right to deploy to production. But I personally think we don’t need to deploy the billing system automatically; it would be safer if we deploy it manually (ansible, SSH). That’s another discussion.
For now I’d leave the accounting group as it is, to limit push access, as mentioned in the first paragraph.