Planning for %"16.0" (when this will be a breaking change): ## Premise: Earlier, the role of `OWNER` was only available at the group level and not available at the project level. Anyone who was an `OWNER` at the group level naturally became an `OWNER` in projects within the group, but we did not support adding a member as `OWNER` directly to a project. `OWNERS` were the highest possible access level in a group, and `MAINTAINERS` were supposed to be the highest possible access level in a Project. `OWNERS` from ancestral groups were of course treated as `Owners` at the Project level, and hence they had some "destructive" permissions in Projects that `MAINTAINERS` did not have. (For example, only `OWNERS` in a project can delete the project, `MAINTAINERS` can not. See the screenshot below for a full list of permissions.)  Recently, we have introduced changes to support directly adding members as `OWNER` in a project. Hence, the next action item we want to pursue is to bring parity between group `OWNERS` and project `OWNERS`, ie, we want their permissions of `OWNERS` in both entities to be more or less the same. For instance, today, group `OWNERS` can add/delete/update members in a group. However, in a project, even `MAINTAINERS` can do the same function. This brings discrepancy in permissions, when you consider the overall picture. We want to avoid this discrepancy. Now, there are 2 ways to accomplish this. ~"group::workspace" has decided to make use of both of them depending on the permission. Each comes with its own sets of pros and cons: * We will move some permissions from group `OWNERS` and give it to group `MAINTAINERS`. For instance, we will bring about a breaking change such that group `MAINTAINERS` can now add/delete/update members in groups, and this is in line with how project `MAINTAINERS` currently behave. * We will remove some permissions from project `MAINTAINERS` and give it to project `OWNERS`. For instance, we will bring about a breaking change such that only project `OWNERS` will be able to create deploy tokens for projects from now on, and this is in line with how group `OWNERS` currently behave. Both these approaches are breaking changes, and will have consequences, but if we want to achieve parity in how `OWNERS` behave across these 2 entities, this is the only possible way. And hence, we will make use of the following plan: - From %"15.0" to %"16.0" - within a project, both `MAINTAINERS` and `OWNERS` will have similar permissions. The only exception is - `MAINTAINERS` won't have any permissions regarding creating, deleting or updating other members to `OWNER` access, as this would a security issue. - Before %"16.0", we announce to customers along the lines of `From GitLab 16.0, the OWNER and MAINTAINER roles will be aligned between groups and projects. This means that MAINTAINERS in a project would no longer have the <following permissions> in a project, starting from 16.0 and they will only be available to OWNERS. At the same time, the <following permissions> will move from group OWNERS to group MAINTAINERS. We advise you to promote those MAINTAINERS who would continue to require access to any of the following permissions to OWNER before GitLab 16.0`. ## What are the permissions that are going to be affected? We should make a list of this. As a general rule of thumb, we want to ensure that destructive actions (such as deleting a project/group) are controlled well by limiting it to the OWNER role. Constructive actions, such as maintaining membership, can be expanded to be performed by both OWNERS and MAINTAINERS in either groups or projects. A non exhaustive list: - creation/modification/deletion of group access tokens should be allowed to group MAINTAINERS as well. - creation/modification/deletion of group members should be allowed to group MAINTAINERS as well. - permission to accept member access requests in groups should be allowed to group MAINTAINERS as well. - `< Add more >`