Registration Features
## Background
The overall goal of Registration Features is to convert more GitLab free (EE) instances to paid, we're doing this by moving features down to a new unpaid "tier". Instance admins will activate Registration features gaining access to this tier and sharing Service Ping data with GitLab Inc.
In FY22 we [first launched Registration Features](https://about.gitlab.com/releases/2021/07/22/gitlab-14-1-released/#registration-features), and have ambitious plans to continue to iterate on this offer. You can read more details in the internal handbook: https://internal-handbook.gitlab.io/handbook/product/pricing/registration-features/
## Feature Tracking
This epic is tracking which features we plan to move down next (in future milestones) and be able to easily track that work across groups.
If you have questions about Registration Features please reach out to @justinfarris either on this Epic or in [#product-monetization](https://gitlab.slack.com/archives/C035TQZ9L8L) in Slack.
| Feature | Target Milestone |
| ------ | ------ |
| [Email from GitLab](https://docs.gitlab.com/ee/user/admin_area/email_from_gitlab.html) | Launched |
| [Repository Size Limit](https://docs.gitlab.com/ee/user/admin_area/settings/account_and_limit_settings.html#repository-size-limit) | Launched |
| [Restrict group access by IP address](https://docs.gitlab.com/ee/user/group/access_and_permissions.html#restrict-group-access-by-ip-address) | Launched |
| [Password Complexity Policy](https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#password-complexity-requirements)) | 16.0 |
|[Track description changes](https://docs.gitlab.com/ee/user/discussions/index.html#view-description-change-history)|16.0|
|[Issue board configuration](https://docs.gitlab.com/ee/user/project/issue_board.html#configurable-issue-boards)|16.0|
|[Maintenance Mode](https://docs.gitlab.com/ee/administration/maintenance_mode/index.html)|16.0|
| [Coverage Guided Fuzz Testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/#coverage-guided-fuzz-testing) | 16.0 |
## Helpers
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/70912 - example of how repo size limit and group ip restriction were implemented <br>
https://gitlab.com/gitlab-org/gitlab/-/issues/341442 - last issue to implement new reg features
## Messaging Pitch for involving PMs
We would like to move {insert feature} to "registration features". [You can read more about the initiative here](https://about.gitlab.com/direction/registration-initiatives). The TL;DR is:
Today GitLab lacks visibility into who our free self-managed users are. Users can simply follow the self managed install steps and be up and running with GitLab in minutes. This open-core model is a huge strategic advantage as it lowers the barrier to entry for our product. The downside is that users are not required to register or "sync" their instance with GitLab preventing us from knowing who they are, providing better support and GTM motions, and offering services that may enable them to get even more value out of GitLab. The problems are:
1. Product lacks visibility into feature usage, adoption, usability issues, and defects.
2. Inefficent GTM motions from outreach and lead generation to sales and support motions upgrading a free self-managed instance to a paid plan.
3. Inefficent upgrade experience if that user intends to start a trial or upgrade their instance to a paid tier.
4. Poor customer experience if they run into issues or struggle with adoption and configuration.
We aim to (try) and solve this problem by allowing free self-managed EE instances that register with GitLab and activate Service Ping to access otherwise paid features. These features would add value to the customer's installation and give them a "preview" of what features they could access at a paid tier.
#### How was this feature selected?
[You can read more about the research here.](https://internal-handbook.gitlab.io/handbook/product/pricing/registration-features/) The TL;DR is that it was chosen based on a low PPS score and therefore we are making the assumption moving it to Free will have not a negative impact on conversion.
#### What is being asked of you?
We want to add Group-level permissions for protected environments to registration features. We believe (based on doing this with previous features) that the LOE is relatively low. Would you be able to schedule this in the next couple milestones? If you feel strongly that this should not be moved down, please share why. Thank you!
## Additional resources
1. [Handbook: Registration Features](https://about.gitlab.com/direction/registration-initiatives/#registration-features)
1. [Docs: Registration Features Program](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#registration-features-program)
1. [Release Note: Additional Registration Features available to Free users](https://about.gitlab.com/releases/2023/05/22/gitlab-16-0-released/#additional-registration-features-available-to-free-users)
1. [Internal Handbook: Registration Features Research and Recommendations](https://internal.gitlab.com/handbook/product/pricing/archived-projects/registration-features/)
1. [Issue: Registration Features - SoftServe Engagement](https://gitlab.com/gitlab-com/Product/-/issues/11282)
1. [Sheets: Registration Features List Feasible View](https://docs.google.com/spreadsheets/d/1yrHcyLXL46wfM3AZKHlzL4yZSwzzCCUuDnReGN0Acao/edit#gid=0&fvid=505477650)
1. [Periscope: Service Ping - Registration Features Program](https://app.periscopedata.com/app/gitlab/1142915/Service-Ping---Registration-Features-Program)
1. [Issue Board](https://gitlab.com/groups/gitlab-org/-/boards/5975681?label_name%5B%5D=Registration%20Features%20-%20SoftServe)
1. [SoftServe Orientation issue](https://gitlab.com/gitlab-com/temporary-service-providers/lifecycle/-/issues/1385)
epic