Activate GitLab.com Pricing Plans

added license label

added Deliverable label

changed milestone to %9.5

assigned to @rdavila

made the issue visible to everyone

I'm going to do a quick call with @oswaldo about it in order to plan a good strategy to tackle it.

@rdavila A few things to have in mind:

Set all users who have purchased plans onto their appropriate plan via the API

We'll need to map each namespace_id of the users/groups of this list
Using an admin GitLab API private-token, send a request to /api/v4/namespaces/:namespace_id for each namespace_id with:
according plan and shared_runners_minutes_limit
Still in doubt about the expiration flow of these subscriptions, but your suggestion sounds reasonable on https://gitlab.com/gitlab-org/gitlab-ee/issues/2391#note_30964118

A couple of questions/suggestions:

Could we save this as an expires_at on the customers-app?
Could we trigger the update from customers-app then update the expires_at if the update succeeds?

created branch 2392-activate-gitlab-com-pricing-plans

changed the description

@joe.s @courtlandia FYI.

Do we want to email all users or put something in the newsletter?

Generally, I favor a "less is more" approach to marketing communications. Better to receive few marketing communications that are very relevant and useful than get bombarded with too much communications. However, when it comes to pricing and packaging changes, I am an advocate for a well thought through communications plan.

Given this, from gitlab-com/customers-gitlab-com#147:

Grandfathering all existing users & groups

To avoid taking all existing features away from existing users, users & groups created before the 9.4 roll-out will be put on a special plan that will allow them to continue to use those features for at least 1 year. New paid features will not be made available to these users and they will have to upgrade to a paid plan to get these features.

We really need to make sure this information is clear to those who may believe that change would represent a loss of functionality. As such, this would be an ideal time to ensure we communicate completely, and understand the various groups of people we're communicating with.

We don't want a communication absence or insufficient communication leading to confused or irate customers thinking their current plan is going away without warning.
We want to make sure to the extent possible we communicate in the best possible way. Is someone on a dotcom plan a heavy user of EE features, and might they be especially anxious about a change like this? What about people who have never used EE features on their dotcom plan? I'm sure there are additional ways to segment our customer data to ensure a communications plan is worthwhile for them to read and addresses what they need to know.
It might also be worth giving some context into why we are making this change, and what it means for the future of our SaaS plans. Maybe we can get our users excited about what's to come, while keeping them informed on how they'll be impacted by our plan changes.

I'd like to invite product and content marketers extraordinaire @amara and @erica to the thread. The three of us will also be huddling on a comms plan and how we can best plug in to support this effort and our customers, and will update this issue following that meeting.

thanks @courtlandia will you follow up, perhaps we can discuss on a call next week once you've all had some time to digest?

@mydigitalself absolutely. I'll find some time for us early next week

Courtland, Erica, and I just met to discuss the communications plan for the pricing updates. I'll create a marketing issue on the comms plan and share it will you all by tomorrow. Once that is created @mydigitalself it would be great to meet to firm up timing and to make sure we have all of the details around feature set per plan and grandfathering.

@mydigitalself one thing that would greatly improve the rollout of this news is the ability to segment our existing .com users by their current usage. (i.e. is someone is a heavy user of EES features today we should send that person different message than someone who is only use a smaller subset of what we offer). Do we have the data on .com users to be able to get to that level of information?

marked the checklist item Execute query to set all users who purchased plans before 9.4 rollout onto their current plan with a SQL query as completed

Execute query to set all users who purchased plans before 9.4 rollout onto their current plan with a SQL query

All customers who purchased a GL.com plan before 9.4 have a complete Namespace record on GL.com now:

# Before sync
irb(main):087:0> Namespace.where('plan IS NOT NULL AND shared_runners_minutes_limit IS NOT NULL').count
=> 26

# After syncing user namespaces
irb(main):088:0> Namespace.where('plan IS NOT NULL AND shared_runners_minutes_limit IS NOT NULL').count
=> 83

# After syncing group namespaces
irb(main):089:0> Namespace.where('plan IS NOT NULL AND shared_runners_minutes_limit IS NOT NULL').count
=> 167

All existing users and groups to be grandfathered using a query such as

@mydigitalself one question regarding this task, what should we do for namespaces related to @gitlab.com account?

@DouweM @oswaldo thinking again about the expiration of the subscriptions I think a pragmatic approach can be to add a new plan_expires_at column to the namespaces table. This will be very useful for the Early Adopter plans and we can use the same mechanism for the other plans as well, WDYT?

Update:

Given we basically need it for the Early Adopter plan, an even more simpler but manual solution can be to mark the desired date on the calendar so we can run a script to reset all the Early Adopter plans. For the other plans we can handle it through an API call from the subscription portal.

Given we basically need it for the Early Adopter plan, an even more simpler but manual solution can be to mark the desired date on the calendar so we can run a script to reset all the Early Adopter plans. For the other plans we can handle it through an API call from the subscription portal.

@rdavila I think that's what we decided on in the call :)

@rdavila

one question regarding this task, what should we do for namespaces related to @gitlab.com account?

Do you mean gitlab-org and gitlab-com groups? We can probably just manually set those to Gold, right?

Here is the issue we can use coordinate the marketing communications of the pricing update: https://gitlab.com/gitlab-com/marketing/issues/1296

Please comment in the issue if anything is missing or if items on the to do list have already been resolved.

For posterity, we agreed @amara would be on point for marketing deliverables related to this, including coordinating across other marketing functions.

@amara per https://gitlab.com/gitlab-org/gitlab-ee/issues/2392#note_36667929 can you get something on the calendar next week for prod and marketing to sync?

created branch 2392-activate-gitlab-com-pricing-plans

changed the description

Do you mean gitlab-org and gitlab-com groups? We can probably just manually set those to Gold, right?

@mydigitalself I'm not sure if the gold plan will be enough for us (50,000 CI minutes), WDYT @DouweM @ayufan?

mentioned in merge request !2609 (merged)

@ayufan @DouweM @mydigitalself I forgot that we can use 0 as the unlimited value so we should be good using it along with the gold plan :)

changed the description

I wonder if we can somehow define actual limits within the plan? Currently, we store limits on per-namespace/per-project basis. Having plans which define the limit would make actually way easier to do.

This would basically apply for all limits, not only CI minutes. This actually makes it good, as we have a single place where we edit all limits, and we have a single place that we have to extend.

mentioned in merge request !2750 (merged)

marked the checklist item Manually set gitlab-org and gitlab-com to Gold plan and unlimited minutes. as completed

marked the checklist item All existing users and groups to be grandfathered using a query such as UPDATE namespaces SET plan = 'early_adopter' WHERE plan IS NULL AND created_at < :some_date https://gitlab.com/gitlab-org/gitlab-ee/issues/2391 this should be done early and re-executed again once the namespace level licensing is turned on. This should be done using a batch query so that we don't lock up the database. (https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2609) as completed

marked the checklist item All existing users and groups to be grandfathered using a query such as UPDATE namespaces SET plan = 'early_adopter' WHERE plan IS NULL AND created_at < :some_date https://gitlab.com/gitlab-org/gitlab-ee/issues/2391 this should be done early and re-executed again once the namespace level licensing is turned on. This should be done using a batch query so that we don't lock up the database. (https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2609) as incomplete

marked the checklist item All of the above should be tested on staging prior to touching the production environment as completed

marked the checklist item All existing users and groups to be grandfathered using a query such as UPDATE namespaces SET plan = 'early_adopter' WHERE plan IS NULL AND created_at < :some_date https://gitlab.com/gitlab-org/gitlab-ee/issues/2391 this should be done early and re-executed again once the namespace level licensing is turned on. This should be done using a batch query so that we don't lock up the database. (https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2609) as completed

changed the description

Activate GitLab.com Pricing Plans

Background

Todo

Marketing plan

Designs

Child items ...

Activity

Grandfathering all existing users & groups

Admin message

Admin message

Activate GitLab.com Pricing Plans

Background

Todo

Marketing plan

Activity

Grandfathering all existing users & groups