Policies discovery
Problem Statement
Organizations typically rely on GitLab's roles and permissions controls to maintain acceptable controls. However, GitLab's role system is typically considered too broad; for many customers - especially those operating in regulated environments - "they often resort to setting everyone to Master and trusting their colleagues to not make mistakes" (see research). In almost all cases, instances want to further constrain existing roles, instead of permit their users to do more.
In order for large organizations, especially regulated and security-minded enterprises, to thrive in GitLab we need more granular per-user permissioning.
Current status
We're currently trying to better understand the problem space before converging on a solution and are exploring and testing early stage wireframes.
- If you're interested in the solution to this problem, please share more details on your needs as a comment.
- How are you working around this problem now?
- What specific controls would you like introduced?
- Do you have any comments on the solutions we're exploring?
We conducted an Opportunity Canvas review on October 10th, which was approved. You can see the canvas here (public URL, anyone can comment):
Possible approach
Please see #7626 (closed) for the latest on the MVC.
Reach
This is primarily a problem for sysadmins (Sidney), team leads (Delaney) and Compliance/Security departments.
In terms of reach, I believe (based on the 48% of users encountering limitations) that the current role system in GitLab is sufficient for most but there's significant reach for improvements.
- 3.0 = Significant reach (~25% to ~50%).
Impact
Among enterprises, especially those operating in regulated spaces, this can be a hard requirement for use of GitLab. Some existing enterprises have built complex workarounds/automation to manage around this problem, and it's one of Customer Success' most requested features.
- 3.0 = Massive impact
Confidence
TODO: Add supporting information (issues, TAM toplist, etc).
- 100% = High confidence
Effort
Based on nothing terribly substantive, I estimate:
- Design/Research effort: High. We'll need to do a lot of discovery to make sure we get the new system right, since it will be hard to revert.
- Product effort: Medium.
- Engineering effort: Medium/High. Roles/permissions are a very mature part of the GitLab application and hard to make substantive changes to. If the solution we pursue involves ripping out the existing system, it will be incredibly expensive.
For the sake of t-shirt sizing, I'll estimate 3 person-months to get to the MVC.
Score
(3.0 Reach * 3.0 Impact * 100%) / 3.0 Effort = 3.0
Note: Maybe Impact scale should be the same as Reach
Links / references (GitLab internal)
- User feedback: https://docs.google.com/document/d/1HyJa6JZG3KqHHlAOwfkrKlSEyzSqatkCQwkpfb-Ic9c/edit (GitLab internal)
- Other customer feedback collected from issues: https://docs.google.com/document/d/1-MZItci-Uxn4m-uEh5wR5VnC2sTeR_8UYdgaZmO6Yik/edit#