馃帹 Design: Transition to Organization for self-managed users
Overview
The goal of creating the Organization on GitLab.com is to move functionality that currently exists in the Admin Area there and thus make it available to admins of an organization on GitLab.com. We would like to have as much feature parity as possible between the currently existing Admin Area on GitLab self-managed and Organization on GitLab.com. However, as the Organization will be attached to top-level groups, this means that the functionality would also have to move away from the Admin Area to top-level groups on GitLab self-managed. Organization will be built in iterations over several milestones, which means that parity would only be the end goal. We need to create an experience for users of the Admin Area that makes this transition to Organization level features as easy as possible for them. Current users of the Admin Area should never use functionality during this transition.
Proposal
There are several options we could pursue to create a Organization on self-managed:
1. Feature flag everything and only switch over once the Organization on GitLab.com is fully functioning.
For Admin Area users, this would mean that their current experience remains as is for a prolonged period of time, until Organization on GitLab.com contains all the same functionality.
The disadvantages of this approach are:
- Users of GitLab self-managed would see a large set of changes very suddenly. This could confuse them.
- Entirely new functionality added to the Organization level on GitLab.com would not be readily available to self-managed users.
2. Move out select features
In this scenario, both an Admin Area and a Organization would coexist for GitLab self-managed users. When moving a feature or setting from into the Organization, it would disappear from the Admin Area.
The disadvantages of this approach are:
- Users would have to go to two different places to manage their current GitLab implementation
3. Duplicate select features in Organization
In this scenario, both an Admin Area and a Organization would coexist for GitLab self-managed users. When moving a feature or setting into the Organization, it would still appear in the Admin Area. Users would be able to choose from what section they would like to manage the setting or feature. Taking an action in one section would duplicate it in the other section. The advantage of this scenario would be that users could already get a feel for the Organization while it is being built, and would not face a drastic change away from the Admin Area upon completion of the Organization.