Workspaces Initial UXR issue

What’s this issue all about?

It's not enough to use groups to manage enterprise activity on GitLab.com; instead, we should consider how we might create a sub-instance level namespace within a GitLab instance. We can call this a GitLab Space.

The benefit to a customer would be removing the need to operate within the confines of a group. Instead, an enterprise could operate in a dedicated workspace, creating users (including admin users) scoped specifically to that workspace, isolated from the rest of the instance. This mechanism could also remove the need for group-level things and remove the barrier between self-managed and GitLab.com.

This is particularly valuable for GitLab.com but also valuable for self-managed instances seeking a barrier of separation between departments (for example, a large tech company might want a separate workspace for highly sensitive projects).

Some further discussion here: gitlab#12098 (closed)

Who is the target user of the feature?

Team leaders/Group Owners & System Administrators

Competitors:

What questions are you trying to answer?

  • How are our competitors solving this problem?
  • Are customers using competitors instead of GitLab because our current solution is not good enough?
  • What current functionality and features from an administration standpoint would we want to include in a Space?
  • What permission and role changes/additions (if any) would we need to consider?
  • In addition to administrative functionality and features, what other needs do customers have?
Core questions
  • Which customers decided to go with Self-Managed instead of .Com? I'd like to know what made them make that decision.
  • How should we take the first step towards this concept?
  • What might an MVC look like?
  • How can we ensure an easy path forward for follow on concepts like Teams and a better experience for Enterprise customers.
Additional questions
  • Should we discuss further with customers what their thoughts are on naming conventions and possible ways we could make our structure clearer? Renaming is a fragile road to travel so this would need to be well-founded with research if we were to do this, but it may make sense to consider asking what our customers think and feel in order to potentially align with our competitors.
    • GitHub's structure is: Instance > Space > Teams & Projects > Sub/child-Teams & Sub/child-Projects > Repos etc. The concept of a group does not exist on GitHub and GitHub Teams are essentially how we currently use Groups.
    • It's important to note that customers have communicated in the past that it's not clear to them what a Group is (when signing up and handling billing)
    • Typically, Groups are referred to as a permission-based group of people (think LDAP groups).

What hypotheses and/or assumptions do you have?

Currently, the assumption that we have is that Groups are not a good enough solution for enterprise customers on GitLab.com, and do not provide enough control or autonomy over their projects and users. Additionally, some of our larger self-managed customers have multiple child or sister companies under the main parent company (who have their own budgets and control requirements) and would potentially benefit from this feature.

See also: #572 (closed)

What decisions will you make based on the research findings?

These findings will help direct the initial MVC for GitLab Spaces.

What's the latest milestone that the research will still be useful to you?

The ~"group::spaces" is not due to begin any engineering work until Feb 2020. It would be good to understand what a potential MVC for this concept would look like by %12.9 if possible.

Edited by Daniel Mora