GitLab Early Access Program Direction
Purpose
The GitLab Early Access Program aims to increase engagement with early adopters, create brand ambassadors while also increasing the level of feedback received on non-GA high-priority features.
In a secondary priority, this helps to cultivate contributions from the Wider Community in alignment with GitLab’s dual-flywheel strategy & GitLab’s Developer Relations strategy
Key group that formed alignment on product direction
- Emilio Salvador
- Justin Farris
- Nick Veenhof
- Steve Evangelista
- Valerie Karnes
Alignments
- All customers who agree with the terms & conditions should gain access to available non GA-features. Otherwise said, we will not gate features to a subset of customers.
- The existing process of accepting the terms & conditions of our testing agreement will be followed.
- There must be an optional opt-in to receive marketing communications regarding beta or experimental features.
- Guidance from UX & Product should be followed how this gets implemented for a consistent user experience. We should avoid adding friction.
Potential UX solutions discussed
- A generic modal that pops up anytime you hit a beta feature toggle vs creating a new place to go opt in before you can toggle the actual feature.
FYI
For guidelines on how features are marked as Beta or Experimental, along with their legal and support status please refer to the following pages: https://docs.gitlab.com/ee/policy/experiment-beta-support.html
Program nurturing activities
The following list is not complete and up for iteration. It serves as an example of activities that could be executed once we are able to communicate with our users is in place.
- We aim to obtain quotes & feedback from customers that use pre-GA features in press releases, blog & release posts.
- Incentive is joint-publicity.
- Through engaging and building a specific early-access community, we can re-use existing recognition & incentive mechanisms built by Developer Relations.
- Incentive is swag or donating trees when X testing activities are performed, when Y feedback items were created, leaderboards etc..
- Through nurturing campaigns of active members we guide them to becoming a contributor.
- Wider Community Contribution licenses can be granted for those that want to fix bugs or iterate on the features.
Traffic Drivers
The following list is not complete and up for iteration. It serves as an example of traffic drivers that could be executed once we are able to communicate with our users is in place.
- Contributor Events such as GitLab Hackatons can be tuned to test pre-GA features and reward participants
- Inclusion in our Community Office Hours
- Increased social presence, blogs & social media campaigns
- Customer outreach
9a329cb0)
