馃帹 Design: How will the Organization impact Personal Namespaces?
Problem
Personal Namespaces will be impacted by the creation of Organizations, and we'll need to solve several user experience questions relating to them (see more below).
Currently, personal namespaces serve 2 primary purposes:
- Giving users a place to keep their personal projects
- Giving people a way to contribute to a project where they don't have permissions to push a branch in that project
Outcomes will be documented in !127619 (merged) and !131810 (merged).
Proposals that were considered
- A personal namespace in each Organization. Users would need to remember which Organization their content is in. However, we are expecting most users to work in a single Organization, so the impact might be less severe.
- A personal namespace in one Organization that can be migrated between Organizations. This would require us to build a migration path for personal namespaces and raises many questions relating to ownership of the content. It would also increase the risk that users migrate content out of the Organization that should remain in it, which is the number one reason why many Enterprise Users do not want to allow personal namespaces to begin with.
- A personal namespace only in the default Organization. This works for existing users and immediately becomes a problem for new users in different Organizations, as they have to remember that their personal content is stored in the default Organization.
- No more personal namespaces at all. This would require us to review how @-mentions work.
Final proposal
Option 1, a personal namespace in each organization. This decision means:
- Personal namespaces of existing users will remain in the default Organization.
- Users will have personal namespaces in both the default org and in whatever orgs they become members of, which is essentially how self-managed already works.
- If an organization other than the default is deleted, the personal namespaces contained within it would be deleted, which is also what happens if a self-managed instance were to be shut down.
Edited by Amelia Bauerly