Epic: Turn Teams into Organizations #15980
Labels
meta: stale
This issue/PR is stale and will be closed soon
team: webapp
Issue belongs to the WebApp team
type: epic
Context
Last year we introduced an entity "Team" to act as a container for "Project". The term has caused quite some confusion as teams are usually considered something more similar to what a team is on GitHub (a handle for a bunch of users).
Gitpod Team semantics are much closer to GitHub orgs and also to what orgs are in other applications.
This epic is not only about renaming the entity (at least externally UI/API) but also about sharpening the semantics and responsibilities.
Current Iteration
Organizations
Organizations, or “orgs”, represent a tenant or company in Gitpod.
Gitpod Dedicated as well as [gitpod.io](http://gitpod.io) can host many orgs, although in dedicated it might be typical to only have one org.
Customers use their Gitpod organization to:
What changes for teams?
Teams will be replaced by organizations in the UI, documentation, and website.
All existing teams become organizations.
Team owners will become org owners (admins) with the same permissions. They can configure SSO identity providers, git providers, see usage, configure billing, and manage org membership.
What changes for users?
When you use Gitpod, you will see your org in the dashboard at the top right, next to your user icon.
If you joined Gitpod by invitation to an existing org, or by logging in through the SSO identity provider of an org, that will be your org. If you joined Gitpod without the context of an org (invite-link or SSO), you will get your own personal org, auto-created (see #15665).
Users may be members of multiple orgs and may switch between them, but there is always a current org.
Workspaces
Workspaces live under an org.
The workspaces list will show only the workspaces for the current org.
New workspaces will live under the current org of the user who started the workspace.
Workspace usage will count against the credits of the org in which the workspace was created. If the org has no available credits, no new workspace will be created but the user will see a “pay wall”.
Restarting an existing workspace after switching orgs will not require switching back to original org.
Projects
Projects live under an org.
Users starting workspaces on repos with a project are not required to switch to the project org, and the existence of the project will not affect where their usage lands. That usage will land on their current org.
Orgs which have projects but no credits will require switching to a different org before starting workspaces
All prebuild usage will count against org credits, and will only work on orgs with credits.
Project settings and prebuilds will work (just like today) for anyone who can start workspaces on the project repo. Workspaces on public repos will have public prebuilds and settings.
What changes for usage and billing?
There will be no more personal usage or billing. All usage and billing will go through orgs. (see #15665)
Individual users can continue to use Gitpod for free, with a 500 credit free allowance on the first organization they create.
There will be a 500 credit free tier and a 1000 credit paid tier for organzations matching the current free and paid plans for individuals. The current pay-as-you-go plan on teams (with zero included credits) will no longer be offered.
Existing teams which have no credits, but were being actively used for prebuilds prior to the introduction of orgs, will be granted a free tier so that prebuilds are not blocked.
The text was updated successfully, but these errors were encountered: