Add latest changes from gitlab-org/gitlab@master

1 files changed, 87 insertions, 15 deletions

diff --git a/doc/architecture/blueprints/cells/impacted_features/personal-namespaces.md b/doc/architecture/blueprints/cells/impacted_features/personal-namespaces.md
index 55d974bb351..757f83c32d3 100644
--- a/doc/architecture/blueprints/cells/impacted_features/personal-namespaces.md
+++ b/doc/architecture/blueprints/cells/impacted_features/personal-namespaces.md
@@ -13,14 +13,14 @@ This documentation will be kept even if we decide not to implement this so that
 
 # Cells: Personal Namespaces
 
-Personal Namespaces do not easily fit with our overall architecture in Cells because the Cells architecture depends on all data belonging to a single Organization.
+Personal Namespaces do not easily fit with our overall architecture in Cells, because the Cells architecture depends on all data belonging to a single Organization.
 When Users are allowed to work across multiple Organizations there is no natural fit for picking a single Organization to store personal Namespaces and their Projects.
 
-One important engineering constraint in Cells will be that data belonging to some Organization should not be linked to data belonging to another Organization.
-And specifically that functionality in GitLab can be scoped to a single Organization at a time.
+One important engineering constraint in Cells will be that data belonging to one Organization should not be linked to data belonging to another Organization.
+Specifically, functionality in GitLab should be scoped to a single Organization at a time.
 This presents a challenge for personal Namespaces as forking is one of the important workloads for personal Namespaces.
 Functionality related to forking and the UI that presents forked MRs to users will often require data from both the downstream and upstream Projects at the same time.
-Implementing such functionality would be very difficult if that data belonged in different Organizations stored on different
+Implementing such functionality would be very difficult if that data belonged to different Organizations stored on different
 Cells.
 This is especially the case with the merge request, as it is one of the most complicated and performance critical features in GitLab.
 
@@ -46,26 +46,98 @@ As described above, personal Namespaces serve two purposes today:
 1. A place for users to store forks when they want to contribute to a Project where they don't have permission to push a branch.
 
 In this proposal we will only focus on (1) and assume that (2) will be replaced by suitable workflows described in [Cells: Contributions: Forks](../impacted_features/contributions-forks.md).
-
 Since we plan to move away from using personal Namespaces as a home for storing forks, we can assume that the main remaining use case does not need to support cross-Organization linking.
-In this case the easiest thing to do is to keep all personal Namespaces in the default Organization.
-Depending on the amount of workloads happening in personal Namespaces we may be required in the future to migrate them to different Cells.
-This may necessitate that they all get moved to some Organization created just for the user.
+
+### 3.1. One personal Namespace that can move between Organizations
+
+For existing Users personal Namespaces will exist within the default Organization in the short term.
+This implies that all Users will, at first, have an association to the default Organization via their personal Namespace.
+When a new Organization is created, new Users can be created in that Organization as well.
+A new User's personal Namespace will be associated with that new Organization, rather than the default.
+Also, Users can become members of Organizations other than the default Organization.
+In this case, they will have to switch to the default Organization to access their personal Namespace until we have defined a way for them to move their personal Namespace into a different Home Organization.
+Doing so may necessitate that personal Namespaces are converted to Groups before being moved.
+When an Organization is deleted, we will need to decide what should happen with the personal Namespaces associated with it.
 If we go this route, there may be breakage similar to what will happen to when we move Groups or Projects into their own Organization, though the full impact may need further investigation.
 
 This decision, however, means that existing personal Namespaces that were used as forks to contribute to some upstream Project will become disconnected from the upstream as soon as the upstream moves into an Organization.
 On GitLab.com 10% of all projects in personal Namespaces are forks.
 This may be a slightly disruptive workflow but as long as the forks are mainly just storing branches used in merge requests then it may be reasonable to ask the affected users to recreate the fork in the context of the Organization.
 
-For existing Users, we suggest to keep their existing personal Namespaces in the default Organization.
-New Users joining an Organization other than the default Organization will also have their personal Namespace hosted on the default Organization. Having all personal Namespaces in the default Organization means we don't need to worry about deletion of the parent organization and the impact of that on personal Namespaces, which would be the case if they existed in other organizations.
-This implies that all Users will have an association to the default Organization via their personal Namespace, requiring them to switch to the default Organization to access their personal Namespace.
-
 We will further explore the idea of a `contribution space` to give Users a place to store forks when they want to contribute to a Project where they don't have permission to push a branch.
 That discussion will be handled as part of the larger discussion of the [Cells impact on forks](../impacted_features/contributions-forks.md).
 
-## 4. Evaluation
+Pros:
+
+- Easy access to personal Namespace via a User's Home Organization. We expect most Users to work in only a single Organization.
+- Contribution graph would remain intact for Users that only work in one Organization, because their personal and organizational activity would be aggregated as part of the same Organization.
+
+Cons:
+
+- A transfer mechanism to move personal Namespaces between Organizations would need to be built, which is extremely complex. This would be in violation of the current Cells architecture, because Organizations can be located on different Cells. To make this possible, we would need to break Organization isolation.
+- High risk that transfer between Organizations would lead to breaking connections and data loss.
+- [Converting personal Namespaces to Groups](../../../../tutorials/convert_personal_namespace_to_group/index.md) before transfer is not a straightforward process.
+
+### 3.2. One personal Namespace that remains in the default Organization
+
+For existing Users personal Namespaces will exist within the default Organization in the short term.
+This implies that all Users will, at first, have an association to the default Organization via their personal Namespace.
+New Users joining GitLab as part of an Organization other than the default Organization would also receive a personal Namespace in the default Organization.
+Organization other than the default Organization would not contain personal Namespaces.
+
+Pros:
+
+- No transfer mechanism necessary.
+
+Cons:
+
+- Users that are part of multiple Organizations need to remember that their personal content is stored in the default Organization. To access it, they would have to switch back to the default Organization.
+- New Users might not understand why they are part of the default Organization.
+- Some impact on the User Profile page. No personal Projects would be shown in Organizations other than the default Organization. This would result in a lot of whitespace on the page. The `Personal projects` list would need to be reworked as well.
 
-## 4.1. Pros
+### 3.3. One personal Namespace in each Organization
+
+For existing Users personal Namespaces will exist within the default Organization in the short term.
+As new Organizations are created, Users receive additional personal Namespaces for each Organization they interact with.
+For instance, when a User views a Group or Project in an Organization, a personal Namespace is created.
+This is necessary to ensure that community contributors will be able to continue contributing to Organizations without becoming a member.
+
+Pros:
+
+- Content of personal Projects is owned by the Organization. Low risk for enterprises to leak content outside of their organizational boundaries.
+- No transfer mechanism necessary.
+- No changes to the User Profile page are necessary.
+- Users can keep personal Projects in each Organization they work in.
+- No contribution space for [forking](../impacted_features/contributions-forks.md) necessary.
+- No need to make the default Organization function differently than other Organizations.
+
+Cons:
+
+- Users have to remember which personal content they store in each Organization.
+- Personal content would be owned by the Organization. However, this would be similar to how self-managed operates today and might be desired by enterprises.
+
+### 3.4. Discontinue personal Namespaces
+
+All existing personal Namespaces are converted into Groups.
+The Group path is identical to the current username.
+Upon Organization release, these Groups would be part of the default Organization.
+We disconnect Users from the requirement of having personal Namespaces, making the User a truly global entity.
+
+Pros:
+
+- Users would receive the ability to organize personal Projects into Groups, which is a highly requested feature.
+- No need to create personal Namespaces upon User creation.
+- No path changes necessary for existing personal Projects.
+
+Cons:
+
+- A concept of personal Groups would need to be established.
+- It is unclear how @-mentions would work. Currently it is possible to tag individual Users and Groups. Following the existing logic all group members belonging to a personal Group would be tagged.
+- Significant impact on the User Profile page. Personal Projects would be disconnected from the User Profile page and possibly replaced by new functionality to highlight specific Projects selected by the User (via starring or pinning).
+- It is unclear whether Groups could be migrated between Organizations using the same mechanism as needed to migrate top-level Groups. We expect this functionality to be highly limited at least in the mid-term. Similar transfer limitations as described in [section 3.1.](#31-one-personal-namespace-that-can-move-between-organizations) are expected.
+
+## 4. Evaluation
 
-## 4.2. Cons
+The most straightforward solution requiring the least engineering effort is to create [one personal Namespace in each Organization](#33-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.