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
- There are multiple categorizations of how customers and users access features:
- Generally Available: These are features that are widely available to all customers and users, they may be only available via a paid subscription but otherwise won’t be designed with any tag. We will offer full customer support for these features aligned with our support policy.0
- Experiment, Beta: These are features any user can opt in and test independent of the Early Access Program; more detail on what distinguishes Experiment & Beta is included in our Feature Support page.
- Early Access Program Features: PMs & Product Leadership might select features to require an opt-in to the Early Access Program. Guidance is that this feature must be behind a feature flag so it can be rolled out to a select group of interested customers.
- The existing process of accepting the terms & conditions of our testing agreement will be followed.
- Guidance from UX & Product should be followed how this gets implemented for a consistent user experience. We should avoid adding friction.
- Guidance from Legal should be followed to help decide on appropriate risks.
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/development_stages_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
9cb966aa)
