Organization roadmap
Overview
This issue tracks the roadmap and status of the Organization project.
Target Persona
For Category:Organization, we are targeting the following personas (in priority order):
- Group Owners
- System Admins
- Team Leaders, Directors, Managers
- Individual Contributors
Benefits
Why is this good for GitLab?
- More alignment between GitLab self-managed and SaaS, making it easier for customers to move to SaaS if that is an option for them (for some of them it is not due to GDPR).
- Organizations are isolated. The isolation enables us to move Organizations between Cells, a more scalable architecture that is currently in development.
Why is this good for customers?
- More alignment between GitLab self-managed and GitLab.com, making it easier for customers to move to SaaS if that is an option for them (for some of them it is not due to GDPR).
- Same user experience when moving from GitLab self-managed to GitLab.com.
- More isolation of entities belonging to one enterprise, allowing customers to better protect their content.
- Organizations will form the basis of organization-scoped features moving forward.
- Improved availability due to better load distribution amongst Cells.
Vision/Options
We want to introduce an Organization to GitLab.com to make it easier to manage the instance setup with regard to the organisation of groups and projects, setting management and inheritance, and navigation.
High-level goals
In order to achieve this, we are aspiring to the following high-level goals:
- Organizations are built on top of the namespaces model.
- Admin capabilities will be moved to Organizations. Admins decide at the Organization level whether settings can be overwritten or not.
- Certain functionality such as billing or provisioning of users will move the Organization level.
- Organizations form an umbrella for multiple top-level groups.
- Organizations offer an aggregated view of data across all their subgroups and projects, for instance on activity and members.
Focus areas
To achieve these high-level goals, we will tackle a couple of focus areas systematically. The areas are divided into:
-
improvements
: outlining planned changes to existing functionality -
research
: outlining possible additions to existing functionality -
problem areas
: outlining areas where new functionality needs to be designed and introduced, or existing functionality has shown to be problematic and requires a redesign
Move admin functionality to Organization
Improvements
-
Existing admin functionality will be made available in Organization. -
~15 new screens will be introduced to namespace (settings, overviews). These screens are currently already available on the admin level for self-managed instances and need to be made available on SaaS. -
~10 existing screens will be combined between the group and admin level. They currently exist on both levels and can be merged to simplify the user experience.
Research
-
New screens for projects.
Problem areas
-
New navigation is needed to house these features. -
Setting inheritance needs to be defined and aligned.
Self-managed admin functionality
Improvements
-
The current admin area will be reduced to hardware specific instance level settings. -
Other admin functionality will move to Organizations.
&8487
Groups/subgroups/projects improvements:Improvements
-
The group design will be improved to better accommodate the jobs-to-be-done. -
The current dashboard view will be improved to highlight areas that have the most relevance for users, e.g. to view newest projects first, projects with most recent activity, etc. -
Filtering and sorting will be modernized -
Group and project pages are made Pajamas compliant -
List pages will be reviewed -
Activity pages will be reviewed -
Explore is modernized -
Your Work is modernized
Research
-
Namespace templates will be introduced to guide users through standard use cases, e.g. using groups to host users versus content. -
The naming convention will be reworked. Naming the Organization aids in promoting a mental model. Groups and projects might be renamed as a consequence. -
Barriers to transferring namespaces need to be identified. -
Migration challenges need to be addressed. -
Particularly on self-managed, where the existing admin functionality would change significantly. -
SaaS users would need to migrate groups and projects to their own Organization.
-
Group sharing improvements
Improvements
-
The current invitation flow will be overhauled and improved. -
Users can see who sent an invitation. -
Information about groups/projects will be added to an invitation.
-
Problem areas
-
Top-level members always inherit to all subgroups. This behaviour is not desired by many customers. -
Indirect inheritance is unclear and needs to be improved. -
Assets are not shared, e.g. labels, issues. -
Multiple sharing models exist. -
Sharing beyond the second node is currently not possible. -
Users need to be able to manage invitations and shared groups, and navigate between group projects and member pages.
Navigation improvements
Improvements
-
Landmarks will be improved so that users can orient themselves easier. -
Admin navigation will be accounted for. -
Changes will be aligned in context with jobs-to-be-done.
Settings improvements
Improvements
-
Admins decide in the Organization whether to cascade settings or not. The UI clearly indicates that this decision defines whether the functionality will be available at lower levels than the Organization. When applying cascading settings they have the control they need and understand the effects of the choices. -
Both admins and non-admins can understand when settings are affected by those further up the hierarchy.
Edited by Christina Lohr