Delay the `One personal Namespace in each Organization` path

Problem

As part of the Updating personal namespace we merged the Evaluation change that reads:

The most straightforward solution requiring the least engineering effort is to create one personal Namespace in each Organization. We recognize that this solution is not ideal for users working across multiple Organizations, but find this acceptable due to our expectation that most users will mainly work in one Organization. At a later point, this concept will be reviewed and possibly replaced with a better solution.

This was evaluated in a context of the need to solve the following problems:

• Support open-source / forking workflow as described in:
  • https://docs.gitlab.com/ee/architecture/blueprints/cells/impacted_features/contributions-forks.html#3-proposal---forks-are-created-in-a-dedicated-contribution-space-of-the-current-organization
• Fix bugs noticed while working on Cells - Iteration 2
  • 2nd Cell tries to create another UserNamespace ... (#421597 - closed)
  • New project form errors out on Cell 2 (#427660 - closed)
• TBD

This decision likely requires significant amount of development and consideration how to handle many edge cases. Some of those discussion can be seen:

• Discussion: Reconfigure personal namespace URLs (#427367)

Proposal

I would propose the amendment to the path that delays the need to support the personal namespace per-organization to a later point:

Do not create personal namespaces in new organizations, unless requested by the organization.

This means:

1. Today, fix the application to not create of personal namespaces in context of the new organizations. Unblock Organizations MVC. Focus (effectively) on solving only the above mentioned bugs.

Later:

1. We would introduce in Organization > Settings > General > Allow users to create personal namespaces in this Organization.
2. Extend the application to support this new flag, with all associated flows when the personal namespaces should be created, ex.: when user tries to fork repository.

Reasons

1. I think it is essential to have the MVC of Organization concept working as soon as possible.
2. Personal namespaces is an answer mostly to support seamless user-forking workflow in open-source Organizations.
   • We need this supported sooner rather than later, but Organization scope of work is big on its own.
3. The Enterprise (private Organization) mostly do not want to use personal namespaces in their Organizations.
   • This makes Enterprises to fully control who can create groups and projects, and how it interacts with the Organization.
4. We can delay heavy work related to creation of personal namespaces to later time, first focusing on creating Organizations, exposing Settings, and building all isolation features that provide tremendous value today.
5. We would provide Organizations MVC today that are fine without personal namespaces.
6. This (not creating personal namespaces in each organization) is not one-way door decision.

Ask

1. @alexpooley
   • Is this correct to say: "NOT creating personal namespaces is easier than having to create for each organization?"
   • If you are unsure, can you do time-boxed proof of concept?
   • If this statement is not true, how much time the Personal Namespaces per-Organization will add to the timeline?
2. @lohrc @mnichols1
   • Is this correct to say: "Enterprise customers would be fine without personal namespaces initially and this is acceptable tradeoff to speed-up Organization MVC?"
   • If this statement is not true, are there any other tradeoff that can reduce that scope?