Consolidate Organization problem statements
Goal
As the ~"group::workspace" team works toward realizing its vision it is important to keep the perspective of the problems we are trying to solve. As a supplemental perspective to the goals and JTBD, looking through the lens of the problems we are trying to solve can generate inspiration, be used as a tool for investigation, serve as an anchor in discussions, and ultimately be used as criteria for evaluating the success of design/solutions. The goal of this issue is to collect, organize, discuss, and document the problems we are trying to solve.
Proposed approach
-
Gather problems to solve -
Consolidate problems, triage, find duplicates, look for themes, determine whether problems are root cause or symptoms of root cause problems -
Get to a list of root cause problems (Current phase 👷 )
Use this list as a tool during the design development process
Consolidated problems
Engineering efficiency
- Engineering efficiency is reduced by building things at multiple levels
- Production code can be reduced by 1/3 by removing duplication (this is not really a problem, but a significant outcome in terms of cost savings and reliability)
Access/Permissions to features
- Access to instance-level features is limited to admins only
- Permission inheritance needs more flexibility and clarity
Feature parity
- There is a lack of parity between self-managed and .com
- Some features are not available at all the levels they are needed
Hierarchy
- Assets being tied to a single namespace limit the ability to leverage them
- Optimizing an organization hierarchy for one use case make it suboptimal for other use cases
Navigation
- Inadvertent context switching causes the user to feel lost
- Wayfinding tool cues are not discoverable
- Sorting/filter tools are not delivering the correct results
- There is no good starting point for an instance to get an overview of their workspace
Detailed collection of problems to solve
-
----- Engineering efficiency -----
-
3 ways to build a feature leads to follow-on requests to build a feature at some other level (see meta issues like group level things) and additional engineering effort.
-
Removing friction and duplication among Groups, Projects, and the Instance. Source
-
Having multiple containers (
Groups
andProjects
) makes it harder to handle the growing demand for making features available on multiple levels. Source -
----- Access/Permissions to features -----
-
Restricts the audience, especially with instance-level features. Many of these features are admin-only, which is a tiny percentage of most users on an instance. If we make a feature instance level, we're locking ourselves into a few thousand self-managed users and locking out GitLab.com users. Source, Source
-
Because of the elevated permissions that users with an admin role have, only select GitLab, Inc. employees are admins on the GitLab.com instance. This means that any settings built in the admin panel are not accessible to customers on GitLab.com. Source
-
Membership inheritance would cause instance-level group members to be present in all subgroups. Source
-
Members would be inherited from the instance group to all groups. We would need special logic to hide them. Source
-
I would improve the user access management to groups subgroups and projects. Current method dows not allow to create limited people access to sub groups if the people is user of an ancestor group. Source
-
Authentication and permission inheritance when integrating with an external user management system like AD or Okta is a bit cumbersome. Mapping with authgroups at the root level sometimes gives people access to subgroup projects that they shouldn't have access to. Source
-
One problem I have with is the ACL. We have a dev team and a QA team. We host both issues and code in the same repository. However, we can only give guest access to our QA users as we do not want them to have access to code. However, they cannot change labels, close issues created by others and more. This hurts the user experience a lot. If we could have a role that allows full access to issue management but not to code, that would help a lot. Source
-
Permissions for different people and groups are unclear from the UI. The documentation about permissions is not very complete. Source
-
Please enable user accounts and permissions for controlling access to sub projects! Source
-
Your enterprise user management seems to be the weakest point in your ecosystem. Source
-
I wish to disable signup in general, but if i invite external guest for issue reporting with email, they should be able to sign up then. Allow/Show sign up only if user is invited (#15059)
-
As a company we must prevent users from inviting other users, especially those that do not even have accounts on the server. Unfortunately I could not find a way to disable this feature. Ability to disable user invitations (#19618)
-
----- Feature parity -----
-
Poor UX for instance-level things. We don't have a place to put instance level features, so cool features like the Operations Dashboard and the Security Dashboard get relegated to the "More" dropdown in the top navbar. Source, Source
-
From a security perspective, customers want to be able to set up a CI pipeline (custom or auto devops, either way) and ensure that everyone must use it (so they can't circumvent security scans) Source
-
Things that are configurable at the instance level but should belong in a top-level group so we have more parity between SaaS and self-managed. Source
-
Organisations might need to be able to define approval settings on a group or sub-group level, as certain people/teams may be granted rights on a different level than projects. approval settings at group or sub-group level (#9595 - closed)
-
There is an alignment problem between .com and self-managed Source
-
We have a logic today that hinges on whether a group is top-level or not. Billing is one of the things that depends on the top level designation for a group. Source
-
There's no way to apply settings to multiple top-level groups at once outside of the admin panel. Only system administrators have access to the admin panel and essentially get sudo access to the entire instance. Source
-
The admin panel is the only place we can build settings that cascade down to multiple projects/top-level groups. Source
-
Building settings that are configurable in top-level groups solve the problem for GitLab.com customers but self-managed customers now have to manage settings in multiple places. They also lose the ability to configure all groups/projects according to their best practices or regulatory mandates. Source
-
IF we could make the administration of self-managed and SaaS the same, that would be a win Source
-
Same disable/enable feature for all projects of a group Source
-
Same boards for all projects of a group Source
-
It would be nice to be able to define certain rules (e.g. approval rules) on group level. Also, more fine-grained user permissions would be handy. Source
-
My main gripe as a owner of a Org space in Gitlab is Member management. Its lacking massive features like the ability to easily audit users last login dates/activity. Seeing what groups the user is a member of natively in the UI. Everything from auditing and reporting is lacking in Gitlab.com and has to be built from scratch using API's which is not ideal. Source
-
There are lots of project level features that rely on repos, but because a repo doesn’t exist at group, when we need to make those things available at the group, we have a hard time reaching feature parity (ex: group wiki). Source 1 Source 2
-
There are several PMs that have had conversations with customers about needing/wanting repos at the group level. Source 1 Source 2
-
There is an ability to archive a project within a group, but there is no ability to archive an entire group with GitLab today. Create an option to archive/unarchive Groups (#15967)
-
I find that git lab roles and permission control is hard to understand Source
-
We actually don't know anything about that user or that group besides the short description below its name. README or "About" for groups - backend (#15041 - closed)
-
----- Hierarchy -----
-
Interacting with and/or sharing Resources across top-level groups/sibling hierarchies. Source
-
Won't we have the same problem of rolling up multiple workspaces Source
-
If move settings from the instance to the group, it doesn't solve the problem of applying settings across groups Source
-
No matter where you are in the hierarchy, how do you connect resources Source
-
I can't use labels because I am not in the right project Source
-
Not all settings of the (sub)group can be inherited by the projects Source
-
We currently have to “pick a repo” at the group (or instance) level in order to cascade down compliance pipelines, file templates, insights.yml, description templates, and more. If a repo was in a workspace for example, you could define all of your configuration files in the highest parent and cascade them down. If we don’t ever plan on implementing repos at the group level, we need to invest a lot more in Source
-
Manage labels in as few places at possible Source
-
Right now, to hierarchically organize multiple personal projects you either have to create groups or use some sort of hierarchical naming scheme for your user projects. Both approaches are not ideal: With groups, you only have one additional hierarchy level. Add support for subgroups in personal namespace (#16734)
-
Orgs are jamming a square peg in to a round hole with the current architecture. So they get by, but don’t love it.
-
----- Migration pitfalls -----
-
The path for all groups/projects would change or we would need special logic to exclude the instance group. Source
-
Personal namespaces would need to move under the instance group. We don’t have a way to tie a personal namespace to a group today. Source
-
All GitLab instances would need to go through a one-time migration to introduce the instance group. Source
-
Enforcing the existence of an instance group for self-managed instances would be difficult. Source
-
----- Navigation -----
-
Overall, there is a high potential for end-users to find this hidden group in different parts of the experience and be confused by it. Source
-
It's a bit confusing to navigate through "Groups". For instance, to get to see the Members in my groups I need to go through at least 3-clicks. Source
-
Are there general patterns of cross-feature navigation behaviour? (e.g. some users stick to use most features, some users use a small subset) Source
-
What are other ways of optimizing cross-feature navigation? Source
-
How might we cluster together certain features or merge certain pages to consolidate the navigation options? Source
-
Need to look at administrating but also using (workspaces/namespaces) Source
-
A bit more transparency when it comes down to context menus of projects and groups. Took me a while to find how (and get used) to adding new users to projects & groups. And this is an issue, to me, with most of these sorts of context menus on GitLab - in that they are not readily available or apparent. Source
-
Get "Members" button always visible while the user is in the project/group Source
-
I often find it hard to know where to go to access something. I find user management can be a bit tough to understand at first but am getting better at it. Source
-
Sometimes, I find it difficult to navigate between projects. I think that it should be easier or perhaps more intuitive to jump between projects that you are part of, or even have starred. Source
-
In some of my groups, I use several projects for common resources needed in all other projects of the group. Usually I have to search for these resource projects every time I need them because other projects are updated more commonly and move them down in the project list. The current sorting options provide no reliable way of keeping these projects at the top of the list other than creating these resource projects before all other projects and then sorting by "Oldest created". Pinned projects/subgroups in groups (#17363)
-
When loading a project group in GitLab, the "sort by" dropdown is always set to "Last Created", which feels okay after creating projects for the first time, but seems odd as a default "sort by" on a day to day basis. When viewing a group, remember the last user-ch... (#23888)
-
----- Groups vs project -----
-
Will we keep the naming and mental model for users for groups and subgroups Source
-
From a new user perspective (in testing) there is no difference between a group and subgroup Source
-
Do we need containers for things and containers for containers Source
-
----- Other -----
-
Settings are too complex to find what you need. PR review UX is much better on github Source
-
Improve the billing settings Source
-
Improve team management Source
-
I find the approvers / code owners / maintainers / etc groups and eligibility confusing and the rules governing how they work to be overly complex. That needed several explanations and trial runs to get right... Source
-
I only really use GL as a repo mirror, so it's kind of annoying to have to turn off all the bells and whistles (issues, PRs, CD etc) manually every time I create a repository. Would be nice to have a way to set default options for new repos or something. Also, I do mainly trunk-based/straight-to-master workflows even when collaborating so the protected branch thing is something I always have to dig through settings to disable (and I always forget exactly where the setting is). It strikes me as a bad default that should just be removed, or again something that could be made settable per account. Oh, and the fact that the protection status doesn't show up until after you push makes setting up repos unnecessarily cumbersome, because you have to do two trips into the web browser instead of just one. Source
-
The only thing I'd improve a bit is the member/sits tracking Source
-
I think that the function of copy a full group content to another will be very useful Source
-
----- Uncategorized -----
-
I have multiple GitLab groups which are not subgroups of each other. I now can register a runner at the group level for one specific group. I now would like to be able to share this runner with another group. Allow a group runner to be shared between multi... (#23722)
-
The problem with the current licensing model is that for projects with tens of thousands of public users, it is impossible to use
EE
. By supporting a mixed user licensing model, more projects could afford to adopt GitLabEE
and still serve their public community. Mixed Public User Basic Features + Private User... (#4382) -
The CI badge / checkmark (build status) has been removed from the group details page in a recent update. It is there on the 'Your projects' view. CI status on group details page (#20450)
-
Add a page to the group settings (or separate item in the sidebar) to show all custom emoji and later also add and remove. Custom emoji group settings: Overview page (#23137 - closed)