Discussion: Dig into teams concept and see if it's viable

Problem

As part of #336022 (closed), we started digging into the problem of access to specific features in GitLab, specifically within the context of incident/vulnerability management.

Right now, access to features is tied to role. If you're a Developer, you can see specific features, and perform certain actions. Maintainers have a higher level of access, and a greater number of actions available to them. Feature permissions are then tied to those pre-defined roles. So, for example, only Developers+ can change the status of an alert. Only Maintainers can create an on-call schedule.

But, what if you only want some Developers to have access to certain features, and have those features be read-only for others? Or, what if you want a group of people to have a Maintainer role for some features only, while keeping their role for other features unchanged?

How can we allow for this kind of access granularity given the current roles we have within GitLab?

Intended users

We started discussing this problem in Monitor and Secure, because it impacts the Incident Management and Vulnerability Management feature sets. But, this idea could certainly impact many teams, and apply across multiple persona groups.

User experience goal

Stepping towards more granular, user-defined feature-access within Gitlab.

WIP Proposal

While it might be nice to introduce a fully flexible way for people to define permissions by role or by feature, introducing that concept within GitLab would likely require a very large re-working of our current model for handling roles/permissions.

With that in mind, we're exploring more of a MVC way of tying access to specific features to targeted groups of users, called Teams. That could look like this:

Team page	Editing team members	Adding new team members

For the MVC:

• We would introduce the concept of teams. People can add members to these pre-defined teams. Team members would have the ability to interact at a pre-defined role level with a designated feature set. (For example, the incident responders team would have a default role of Developer and they would have that role for the incident management features only).
• We would also introduce the ability to restrict access to those features to that team only (ie, everyone who isn't a team member would have read-only access to those features only).
• The "Teams" would initially be defined by us, not by the users. That would allow us to tie the teams to specific feature sets more easily for a first pass. In the future, we could allow people to create their own teams, and tie those teams to specific features.
• The role level assigned to team members would also not be editable for the first pass. But, in future, we could allow those roles to be editable, as well. (Which could, perhaps, look like this.)
• The functionality would live at the group level, and would cascade down to all projects within the group.

Goals for this issue

We've come up with this idea for teams. We need to dig into the idea a bit more to see if it's something worth pursuing. Here are a few questions worth exploring:

• How do we evaluate the idea to see if it's a good fit?
• Is it technically feasible?
• Does it solve the problems we need it to in the short-term?
• Is this idea flexible enough to expand in the ways we need it to expand down the line?

Conclusions

We had initially proposed the teams idea as a way to start stepping towards more granular permissions without having to build out role based access control in GitLab. As discussion in this issue progressed however, we realized that, in order to have the granularity of control we'll likely need in terms of allowing/limiting access to specific features, we probably will need go the RBAC route.

To future investigate RBAC in GitLab, we've created a design pod. Designers in Monitor, Secure and Manage will work together to outline what RBAC could look like in GitLab. As part of this effort, we'll do some competitive analysis, and come up with some initial concepts that we can start sharing with everyone more broadly, and that we can start testing with users.

We'll ensure that the plans we come up with align with the move towards Namespaces/Workspaces, and with the consolidation of projects and groups, efforts that are otherwise already in progress. It's possible that the teams idea might be useful for differentiating the different kinds of groups available in GitLab (groups of projects and groups of people). But, as that's a separate issue from the access control we need more immediately in Monitor and Secure, we'll focus on that first, by working to define what RBAC would look like in GitLab.