Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Workspace

The Workspaces group

Content last reviewed on 2021-10-18

This is the direction page for the Workspaces group which is part of the Manage stage of the DevOps lifecycle and is responsible for the following categories:

Category Direction Description Maturity
Subgroups Direction Page Groups represent collections of users or projects. Complete
Projects   Projects are containers of resources used to host your codebase, track issues, plan work, and continuously build, test, and use built-in CI/CD to deploy your app. Not Applicable
Users Directon Page Users represent individuals using GitLab. Not Applicable

Introduction and how you can help

Thanks for visiting this category page on Workspace in GitLab. This vision and direction is a work in progress and sharing your feedback directly on issues and epics on GitLab.com is the best way to contribute.

Overview

The Workspace group is responsible for rationalizing the data model for containers of resources within GitLab. In order to do this, we will introduce the concept of a Workspace.

A workspace will be above the top-level namespace for you to manage everything GitLab, including:

Vision

The video below contains a discussion with Sid on this topic outlining the problem and the concept of an "instance group". We have since moved away from the term "instance group" and are instead using the term "workspace".

Today, GitLab's features exist at 3 levels:

Level Description Example
Instance Features for the entire instance. These are generally admin features (restricted to the admin panel or via a config like gitlab.rb), but not always (Operations Dashboard). LDAP, admin-level push rules
Group Features configured and used at the group-level. These generally inherit behavior or objects down into subgroups (like epics, settings, or memberships). Epics
Project Features used at the project level. Requirements Management

This leads to a few problems:

While it would be ideal to have one way to build a new feature, most GitLab functionality should exist at the group level rather than the instance level at a minimum.

We should extract features from the admin panel into a new object called a Workspace that cascades behavior to all the projects and groups that are owned by the same user or organization.

What's next and why

Demo of introducing the new hierarchy concept for groups and projects for epics

What is Not Planned Right Now

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license