Epic: Simplify team plans and align with project teams

[jldec]

[Updated 2022-01-28 by @JanKoehnlein]
[Updated 2022-02-01 by @JanKoehnlein]
[Updated 2022-05-13 by @jldec]

Summary
The goal of this epic is to simplify the administration of team plans by making team plans behave like the new teams introduced with teams and projects. There's a detailed discussion in this RFC (internal)

Challenges

• There are now 2 kinds of teams in Gitpod, one for team plan subscriptions, one for projects. This is confusing for users.
• Managing the subscription slots (members) in a Team Plan can be annoying.
• Team plans are owned by a single user. Administration of team plans cannot be delegated.
• Team plan owners do not need to be a member of the team plan themselves. This capability needs to be preserved.
• Team plan members cannot remove themselves from a team.
• There is no API for managing team plan members.

Task breakdown

• Extend the DB schema and entities to support team subscriptions in teams #9652
• Implement a new Team Billing where Owners can conveniently manage a paid plan for their Team #8041
  • Allow subscribing via Chargebee directly from your team Settings
  • Create a "synthetic" user subscription when you're a member of a paid Team Plan
  • Transparently update the Team Plan quantity in Chargebee when users join or leave a team
  • Pro-rate charge for new members joining in the middle of a billing cycle
  • Allow managing your Billing in team Settings via a "Team Chargebee Portal"
  • Align the new UI with [Design] Team Plans v2 #8352
  • Ship without new 'Billing' menu in team settings
• Only allow team owners to invite new users to a team with a paid plan
• Add a membership flag for non-billed members
• Add new 'Billing' menu into team settings
• https://github.com/gitpod-io/ops/issues/2543
• https://github.com/gitpod-io/website/issues/2216
• Add links from dashboard to new team billing docs #10741

Related work
Usage-based Billing will provide an alternative billing mechanism which is independent of user-count or plan-selection.

[jankeromnes]

• Team plan owners do not need to be a member of the team plan themselves. This capability needs to be preserved.

Does it really? The fact that you can be part or not part of a team plan has always created ambiguity and confusion -- as a team lead, should I purchase an individual plan for me and a team plan for my team mates, or invite myself to my team plan? What happens if I accidentally do both of these?

(See the numerous support emails we received saying "I accidentally created a plan for myself and a plan for my team, please re-unify.)

I think it's a common pattern in SaaS team plans that you're automatically part of a team that you manage. I'd vote for just dropping the capability to "manage a team without really being part of it" in the new implementation.

• Support unbilled team members

This seems like a lot of complexity and risk for almost no value (i.e. shooting ourselves in the foot). I'd vote for removing this from "future tasks", and maybe revisiting later if this is a crucial customer request.

[JanKoehnlein]

Completely agree. That was a remnant from prior versions. We are not going to support unbilled members until we feel some commercial pressure.

[gtsiolis]

Team plan owners do not need to be a member of the team plan themselves. This capability needs to be preserved.

Agree with @jankeromnes in #7759 (comment). I see no negative reason attached to changing this. In contrast, not including the team owner can create confusion when browsing team members and sounds logical to include them in the members list but also count their membership as part of the plan. 🗳️

Team plan members cannot remove themselves from a team.

Sounds ok to allow this to happen as this is supported in teams. Team members can always come back and join the team if they have the invitation URL.

Completely migrate to new team subscriptions and remove old implementation

❓ question: Not sure how this would affect UX of the dashboard. If we're not migrating the old team plans to new teams, does this mean users will still see both when they have an active team plan subscription?

❓ question: One question that was brought up earlier this morning while meeting with @jankeromnes: In the old team plans users could start using the product for every repository they wanted and usage was counted against the old team plan. Now that teams include projects it could make sense to count only usage (workspaces, etc) for projects within that team. Food for thought. 🍔

[jankeromnes]

Thank you for sharing your thoughts @gtsiolis!

❓ question: Not sure how this would affect UX of the dashboard. If we're not migrating the old team plans to new teams, does this mean users will still see both when they have an active team plan subscription?

I think it's best to do this in two steps, in order to avoid "surprizing" users too much:

1. Implement the new "Paid Plans" feature under Team Settings (and observe initial adoption / handle initial feedback)
2. Later (once we've built confidence in the new UI), migrate older Team Plans over to new UI, and remove the old UI

At no time will you see the same paid plan in two locations though:

• Current (legacy) Team Plans have no associated teamId, thus they show up under your personal Settings (under Teams) because we don't know which Team they belong to (if any)
• New Team paid plans have an associated teamId, thus they show up under that Team's Settings (under Paid Plans) and not in your personal settings
• In between the two steps, we could potentially build a "voluntary migration flow" where owners of (legacy) Team Plans can select which Team the plan should move under, or if a new Team should be created specifically for that plan

❓ question: One question that was brought up earlier this morning while meeting with @jankeromnes: In the old team plans users could start using the product for every repository they wanted and usage was counted against the old team plan. Now that teams include projects it could make sense to count only usage (workspaces, etc) for projects within that team. Food for thought. 🍔

I think this will remain unchanged for now: In essence, we are just moving the current Team Plans to a different part of the UI (by "linking" them to a Team), but the plans' features stay the same -- i.e., if you're part of such a paid team plan (whether legacy or new), you get unlimited Gitpod hours regardless of which repository you use (just like today).

At a later point in time, we might think about implement usage-based pricing, and this will potentially change how the team plans work. But this is out of scope for now.

[gtsiolis]

Thanks, @jankeromnes!

The plan breadkdown makes sense as long as we don't push the next steps including migration too much below.

🍊 🍊 🍊 🍊

Re-posting from a relevant discussion (internal) for visibility and future reference:

For the first iteration of Teams & Projects we’re keeping both Teams and we’re adding a deprecation notice in #5121.

💭 thought: This could be re-used as an information notice rather than a deprecation notice.

In the future we could migrate teams by creating a new team to replace the old ones and automatically associating all users with it.

We could be able to create new teams for old teams with the name of the tier like Team Professional and use a url like team-professional-gzf7wf33, so that every user allocated a (old) team seat sees a new team also available in the new top navigation.

💭 thought: I'd be interested in your thoughts on this. I guess it would be best to first allow users to rename teams, see #5067.

🍋 🍋 🍋 🍋

At a later point in time, we might think about implement usage-based pricing, and this will potentially change how the team plans work. But this is out of scope for now.

Although out of the scope of this issue, moving usage-based pricing to capture usage for workspaces that have an associated project could push for adding more project and making projects more useful here, no?

🥝 🥝 🥝 🥝

❓ question: Should this be part of the roadmap? Cc @jldec

[jldec]

not quite done - see remaining tasks in description.

[jankeromnes]

@jldec I've removed my assignment to the Epic, but please feel free to directly assign remaining/sub-issues to me that you'd like to schedule next.

[jldec]

Linked to docs issue https://github.com/gitpod-io/website/issues/2216

[jldec]

Thanks for all the care and attention you put into this @jankeromnes and @gtsiolis.
🙏