Discussion: Rollout for Organizations
Problem
What should the rollout strategy look like for Organizations? I assume that in order for Cells to work, we will need Organizations for all existing top-level groups eventually. The decisions we need to take are:
- Whether we allow users to opt into an Organization for a transitionary period of time
- If we allow an opt-in, what is the time frame in which we will allow this before rolling Organizations out to everyone. This is most likely the time-frame between the Organization MVC release and the first Cell(s) going into production.
Why is this important?
This will inform design decisions. If we allow a transition period, designs need to focus on handling a temporary dual state, essentially a higher level of complexity. If we do a "forced" rollout, designs can focus on migrations and merges of Organizations. It would reduce design scope.
Options
1. All existing top-level groups get an Organization built on top of it at once
No opt-in for users, the Organization is created on behalf of the user. The current top-level group owner would be assigned as an admin by default. We would give the organization a generic name that the admin can change.
Advantages
- No transition state needed
- Quick
- A clear starting point for each customer
- Focus can be on managing merging Organizations in case users would like to combine top-level groups under one umbrella
Disadvantages
- Sudden breaking change for all users with no opt-out option
- Data loss for any cross-group links that cannot be recovered. For example all of the links between
gitlab-org
andgitlab-com
would disappear immediately and we'd personally take a big productivity hit.
2. Slow transition, opt-in, force later
We would dogfood the Organization, and allow select customers to opt in. New customers would only be able to create an Organization. After a transition period, all customers would get an Organization assigned. Those that did not opt in voluntarily will get an Organization created on their behalf.
Advantages
- Users get to decide on a time when this change would be suitable for them
Disadvantages
- Too slow for Cells to be able to move into Staging?
- Transition state needed
- Top-level groups will exist in two different states
- Org covered top-level groups will have billing at the Org level
- Non-Org top-level groups will have billing at the top-level group level
- Higher design complexity
3. Opt-in, no force, accepting duality potentially forever
Similar to (2), we would allow for a slow transition and focus on providing incentives for users to create an Organization. If users choose not to create an Organization, the Org-less top-level groups will remain on a Cell of our choice.
Advantages
Disadvantages
- Higher design and technical complexity
4. One Organization to start with that users can bud off from into their own Organization
- Every namespace on GitLab.com today gets assigned to a legacy "GitLab.com Public" organization (this requires UX consideration to decide how visible or not this organization actually is to users or admins)
- Anyone that wants to opt into an organization needs to explicitly transfer their groups and is aware that it means isolation and possibly losing inbound/outbound links for any data that is not being transferred into the organization
- Once a user is a member of an organization (separate to moving groups into an organization but the user needs to be added as a member) then they get a different user experience. They no longer see a global "TODOs" list (and other dashboard pages) but instead they only have the option to view the TODO list for their organization. They may be able to also view a legacy TODO list for the "GitLab.com Public" organization (requires UX consideration) but this would not show them any data from their new organization because it's isolated.
Advantages
- Users can opt into isolation
Disadvantages
- Potentially differing user experiences based on the Organization the user belongs to.
Open questions
- If we let users opt-in to an Organization, should we let them revert?
- If not reversible, how do we communicate to users that this is a final decision?
Proposal
Using the options outlined above, the best rollout strategy might look as such:
- Organizations will be rolled out using the concept of a
default Organization
. All existing top-level groups on GitLab.com will become part of thisdefault Organization
. This way, users will already become familiar with the concept of an Organization and the Organization UI. - GitLab, the organization, will be the first one to bud off into a separate Organization. We move all top-level groups that belong to GitLab into the new Organization GitLab, including GitLab.org and GitLab.com.
- New customers will only have the option to start their journey by creating an Organization.
- We motivate existing customers to create their own Organization, e.g. via a banner message, targeted conversations with large customers via the CSMs. Creating a separate Organization will remain a voluntary action.
- We increase the value proposition of the Organization, for instance by moving billing to the Organization level to provide incentives for more customers to move to a separate Organization. Adoption will be monitored.
- A force-option will only be considered if the we do not achieve the load distribution we are aiming for with Cells.
Initial value proposition
- Improved performance: faster membership queries
- Organization Group overview that every User of an Organization can access
- Organization Project overview that every User of an Organization can access
- Increased isolation
Enhanced value proposition
- Billing at the Organization level: a User does not have to be paid for twice when they are present in multiple top-level groups
- Enterprise Users at the Organization level
- User management for Organization Owners at the Organization level
... see also Organization post-MVC iterations
Advantages
- Allows us to dogfood the experience to spin off into a separate Organization
- No existing links between top-level groups are broken
- Slow rollout allows us to learn and fix issues as we go along
Disadvantages
- Impact on open source projects needs to be mitigated