Skip to content
Snippets Groups Projects
Commit 9cb966aa authored by Cynthia "Arty" Ng's avatar Cynthia "Arty" Ng :speech_balloon:
Browse files

Update experiment-beta path

parent f83d9d68
No related branches found
No related tags found
1 merge request!10229Update experiment-beta path
Showing
with 22 additions and 22 deletions
...@@ -406,9 +406,9 @@ or dedicated installations could then start getting better ...@@ -406,9 +406,9 @@ or dedicated installations could then start getting better
AI-supported features without having to upgrade their GitLab instance. AI-supported features without having to upgrade their GitLab instance.
Features that are currently Features that are currently
[experimental](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#experiment) [experimental](https://docs.gitlab.com/ee/policy/development_stages_support.html#experiment)
can use these generic APIs, but we should aim to convert to a single can use these generic APIs, but we should aim to convert to a single
purpose API endpoint before we make the feature [generally available](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#generally-available-ga) purpose API endpoint before we make the feature [generally available](https://docs.gitlab.com/ee/policy/development_stages_support.html#generally-available-ga)
for self-managed installations. This makes it easier for us to support for self-managed installations. This makes it easier for us to support
features long-term even if the landscape of AI providers change. features long-term even if the landscape of AI providers change.
......
...@@ -9,7 +9,7 @@ toc_hide: true ...@@ -9,7 +9,7 @@ toc_hide: true
[GitLab Steps](../index.md) is a new feature that does not have any prior usage at GitLab. [GitLab Steps](../index.md) is a new feature that does not have any prior usage at GitLab.
We decided that there are two important objectives at this stage of the project: We decided that there are two important objectives at this stage of the project:
- Integrate the project into existing CI pipelines for the purpose of user evaluation as part of an [experiment](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#experiment) phase. - Integrate the project into existing CI pipelines for the purpose of user evaluation as part of an [experiment](https://docs.gitlab.com/ee/policy/development_stages_support.html#experiment) phase.
- Provide a contribution framework for other developers in the form of a project with contribution guidelines. - Provide a contribution framework for other developers in the form of a project with contribution guidelines.
## Decision ## Decision
......
...@@ -6,7 +6,7 @@ This guide provides guidelines and best practices for how to properly position a ...@@ -6,7 +6,7 @@ This guide provides guidelines and best practices for how to properly position a
## Establish an Experiment ## Establish an Experiment
The first step when releasing the first iteration for an Incubation Engineering project is to establish the experiment. See the [documentation](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#experiment) for more details on what makes a GitLab Experiment. The first step when releasing the first iteration for an Incubation Engineering project is to establish the experiment. See the [documentation](https://docs.gitlab.com/ee/policy/development_stages_support.html#experiment) for more details on what makes a GitLab Experiment.
To establish an experiment, ensure that the feature being released has: To establish an experiment, ensure that the feature being released has:
...@@ -19,7 +19,7 @@ Be sure not to include this feature in a release post until it is mature enough ...@@ -19,7 +19,7 @@ Be sure not to include this feature in a release post until it is mature enough
## Graduate from Experiment to Beta ## Graduate from Experiment to Beta
Once an experiment has matured sufficiently and the SEG is confident the feature is stable, unlikely to cause data loss, and the interface is unlikely to drastically change, the feature should be moved to Beta. See the [documentation](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#beta) for expectations of a Beta feature. Once an experiment has matured sufficiently and the SEG is confident the feature is stable, unlikely to cause data loss, and the interface is unlikely to drastically change, the feature should be moved to Beta. See the [documentation](https://docs.gitlab.com/ee/policy/development_stages_support.html#beta) for expectations of a Beta feature.
To move an experiment to Beta, the following items should be in place: To move an experiment to Beta, the following items should be in place:
...@@ -34,7 +34,7 @@ To move an experiment to Beta, the following items should be in place: ...@@ -34,7 +34,7 @@ To move an experiment to Beta, the following items should be in place:
## Graduate from Beta to Generally Available (GA) ## Graduate from Beta to Generally Available (GA)
The final maturity step for a feature is to move to Generally Available (GA). See the [documentation](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#generally-available-ga) for expectations of a GA feature. The final maturity step for a feature is to move to Generally Available (GA). See the [documentation](https://docs.gitlab.com/ee/policy/development_stages_support.html#generally-available-ga) for expectations of a GA feature.
A feature that is ready for GA will have: A feature that is ready for GA will have:
......
...@@ -18,7 +18,7 @@ We will assume that the [recommended approach](https://docs.gitlab.com/ee/develo ...@@ -18,7 +18,7 @@ We will assume that the [recommended approach](https://docs.gitlab.com/ee/develo
- A [feature flag](https://docs.gitlab.com/ee/development/feature_flags/index.html) is used. - A [feature flag](https://docs.gitlab.com/ee/development/feature_flags/index.html) is used.
- The minimum amount of API endpoints has been implemented for the project level only. - The minimum amount of API endpoints has been implemented for the project level only.
The recommended way to release the new Package Registry is using the support [statuses](https://docs.gitlab.com/ee/policy/experiment-beta-support.html). The recommended way to release the new Package Registry is using the support [statuses](https://docs.gitlab.com/ee/policy/development_stages_support.html).
Each update on the status should be documented on the [list of supported package formats](https://docs.gitlab.com/ee/user/packages/package_registry/#supported-package-managers). Each update on the status should be documented on the [list of supported package formats](https://docs.gitlab.com/ee/user/packages/package_registry/#supported-package-managers).
......
...@@ -273,7 +273,7 @@ Exit Criteria: ...@@ -273,7 +273,7 @@ Exit Criteria:
- PreQA Cell configured to generate `_gitlab_session` with prefix using rails config. - PreQA Cell configured to generate `_gitlab_session` with prefix using rails config.
- Route `_gitlab_session` with matching prefix to PreQA Cell using TopologyService::Classify (REST only) with static config file. - Route `_gitlab_session` with matching prefix to PreQA Cell using TopologyService::Classify (REST only) with static config file.
- Continuous Delivery on Ring 0 with no rollback capabilities and doesn't block production deployments. - Continuous Delivery on Ring 0 with no rollback capabilities and doesn't block production deployments.
- Topology Service [Readiness Review](../production/readiness.md) for [Experiment](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#experiment) - Topology Service [Readiness Review](../production/readiness.md) for [Experiment](https://docs.gitlab.com/ee/policy/development_stages_support.html#experiment)
- Topology Service gRPC endpoint not implemented. - Topology Service gRPC endpoint not implemented.
Unblocks: Unblocks:
......
...@@ -6,7 +6,7 @@ description: "How the Infrastructure Department supports shipping features to Pr ...@@ -6,7 +6,7 @@ description: "How the Infrastructure Department supports shipping features to Pr
## Getting started ## Getting started
When a GitLab feature is released to Production, it can be released at one of these levels: Experiment, Beta, Generally Available. When a GitLab feature is released to Production, it can be released at one of these levels: Experiment, Beta, Generally Available.
(See the [product documentation](https://docs.gitlab.com/ee/policy/experiment-beta-support.html) for further details.) (See the [product documentation](https://docs.gitlab.com/ee/policy/development_stages_support.html) for further details.)
The availability of a feature is closely related with our ability to support the feature on our SaaS Platforms. The availability of a feature is closely related with our ability to support the feature on our SaaS Platforms.
......
...@@ -8,7 +8,7 @@ The Production Readiness Review is a process that helps identify the reliability ...@@ -8,7 +8,7 @@ The Production Readiness Review is a process that helps identify the reliability
It loosely follows the [production readiness review](https://sre.google/sre-book/evolving-sre-engagement-model/) from the SRE book. It loosely follows the [production readiness review](https://sre.google/sre-book/evolving-sre-engagement-model/) from the SRE book.
The goal of the readiness review is to make sure we have enough documentation, observability, and reliability for the feature, change, or service to run at GitLab.com production scale. The goal of the readiness review is to make sure we have enough documentation, observability, and reliability for the feature, change, or service to run at GitLab.com production scale.
The readiness review process should be started as early as possible as features progress through our [product maturity levels](https://docs.gitlab.com/ee/policy/experiment-beta-support.html). The readiness review process should be started as early as possible as features progress through our [product maturity levels](https://docs.gitlab.com/ee/policy/development_stages_support.html).
**Completing a readiness review doesn't necessarily mean that the Infrastructure teams will take over on-call responsibilities or ownership from the service team. If required, this should be discussed in the merge request.** **Completing a readiness review doesn't necessarily mean that the Infrastructure teams will take over on-call responsibilities or ownership from the service team. If required, this should be discussed in the merge request.**
...@@ -16,7 +16,7 @@ This review is meant to facilitate collaboration between Service Owners, Securit ...@@ -16,7 +16,7 @@ This review is meant to facilitate collaboration between Service Owners, Securit
The review document will serve as a snapshot of what is being deployed and the discussions that surround it. The review document will serve as a snapshot of what is being deployed and the discussions that surround it.
It is not intended to be constantly updated. It is not intended to be constantly updated.
The **readiness review MR** will go through a single review for every [maturity level](https://docs.gitlab.com/ee/policy/experiment-beta-support.html). The **readiness review MR** will go through a single review for every [maturity level](https://docs.gitlab.com/ee/policy/development_stages_support.html).
We require an MR because it allows for inline comments, threaded discussions and explicit approval. We require an MR because it allows for inline comments, threaded discussions and explicit approval.
Once an MR has been approved by the stakeholders and merged it is considered approved for corresponding level. Once an MR has been approved by the stakeholders and merged it is considered approved for corresponding level.
...@@ -30,7 +30,7 @@ The **readiness review issue** is used to coordinate among stakeholders who will ...@@ -30,7 +30,7 @@ The **readiness review issue** is used to coordinate among stakeholders who will
## Criteria for starting a Production Readiness Review ## Criteria for starting a Production Readiness Review
Production Readiness should start as early as possible and is required for all [product maturity levels](https://docs.gitlab.com/ee/policy/experiment-beta-support.html) that meet any of the following criteria: Production Readiness should start as early as possible and is required for all [product maturity levels](https://docs.gitlab.com/ee/policy/development_stages_support.html) that meet any of the following criteria:
- New infrastructure components, or significant changes to existing components that have dependencies on the GitLab application. - New infrastructure components, or significant changes to existing components that have dependencies on the GitLab application.
- Changes to our application architecture that change how the infrastructure scales, or how data is processed or stored. - Changes to our application architecture that change how the infrastructure scales, or how data is processed or stored.
......
...@@ -5,7 +5,7 @@ description: "How to mature an AI-assisted feature from a UX perspective." ...@@ -5,7 +5,7 @@ description: "How to mature an AI-assisted feature from a UX perspective."
## Summary ## Summary
The following guidelines focus on the **UX** aspect of the maturity of AI-assisted features. [Other aspects](https://docs.gitlab.com/ee/policy/experiment-beta-support.html), like stability or documentation, should also be taken into account to determine the appropriate feature maturity. The following guidelines focus on the **UX** aspect of the maturity of AI-assisted features. [Other aspects](https://docs.gitlab.com/ee/policy/development_stages_support.html), like stability or documentation, should also be taken into account to determine the appropriate feature maturity.
To evaluate the UX maturity of AI-assisted features, use three criteria from the [Product Development Flow](/handbook/product-development-flow/): To evaluate the UX maturity of AI-assisted features, use three criteria from the [Product Development Flow](/handbook/product-development-flow/):
...@@ -65,7 +65,7 @@ Note: For Duo Enterprise, the [Definition of Done](https://gitlab.com/gitlab-org ...@@ -65,7 +65,7 @@ Note: For Duo Enterprise, the [Definition of Done](https://gitlab.com/gitlab-org
#### High Confidence & Low Risk #### High Confidence & Low Risk
When an AI-powered feature has high confidence in the output quality and low risk of producing harmful or incorrect results, the feature can rely primarily on the standard [feature maturity](https://docs.gitlab.com/ee/policy/experiment-beta-support.html) definitions. In this case an evaluation dataset is not required, however the feature should have basic guardrails like unit tests and can rely mainly on the existing AI Framework and AI Gateway. When an AI-powered feature has high confidence in the output quality and low risk of producing harmful or incorrect results, the feature can rely primarily on the standard [feature maturity](https://docs.gitlab.com/ee/policy/development_stages_support.html) definitions. In this case an evaluation dataset is not required, however the feature should have basic guardrails like unit tests and can rely mainly on the existing AI Framework and AI Gateway.
Consider running a UX Bash with at least 10 external users validating the quality of the output. We have a framework for how to run them to evaluate output quality. Consider running a UX Bash with at least 10 external users validating the quality of the output. We have a framework for how to run them to evaluate output quality.
......
...@@ -63,12 +63,12 @@ Our approach requires four pillars: ...@@ -63,12 +63,12 @@ Our approach requires four pillars:
- Relentless customer focus and commitment to understanding their workflows, using research and validation - Relentless customer focus and commitment to understanding their workflows, using research and validation
- Measurable outcomes that use established metrics for success in tracking adoption, usage, or other business outcomes. - Measurable outcomes that use established metrics for success in tracking adoption, usage, or other business outcomes.
- Product functionality that adheres to GA criteria listed in [the levels of support](https://docs.gitlab.com/ee/policy/experiment-beta-support.html) - Product functionality that adheres to GA criteria listed in [the levels of support](https://docs.gitlab.com/ee/policy/development_stages_support.html)
- Future vision to expand the MVC beyond the initial release - Future vision to expand the MVC beyond the initial release
When considering how to scope a feature for a release, remember that it is not ok to ship an "incomplete" feature to customers (see the [definition of done](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#definition-of-done)). Consider the use of Pajamas components for UI in your MVCs. When introducing a new component or pattern not found within Pajamas, it is the responsibility of that team to follow our [component lifecycle guidelines](https://design.gitlab.com/get-started/lifecycle) to [determine whether it should be added](https://design.gitlab.com/get-started/lifecycle#determining-whether-a-component-should-be-included-in-pajamas) and, if so, contribute the addition/update back to Pajamas. When considering how to scope a feature for a release, remember that it is not ok to ship an "incomplete" feature to customers (see the [definition of done](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#definition-of-done)). Consider the use of Pajamas components for UI in your MVCs. When introducing a new component or pattern not found within Pajamas, it is the responsibility of that team to follow our [component lifecycle guidelines](https://design.gitlab.com/get-started/lifecycle) to [determine whether it should be added](https://design.gitlab.com/get-started/lifecycle#determining-whether-a-component-should-be-included-in-pajamas) and, if so, contribute the addition/update back to Pajamas.
MVC means reducing the scope so we can ship quickly. It doesn't mean shipping something that hurts the usability of GitLab. First impressions are important. A feature that does not offer enough value or hinders the user experience may have a negative effect that discourages users from trying that feature again in the future. If there are obvious gaps in your MVC or you can anticipate follow-up requests, consider whether your feature is complete enough to be released to users. If you are unsure whether your feature is complete enough to be an MVC (or if you know your feature is not complete enough to be an MVC and you want to gather additional feedback), you can use approaches such as dogfooding, [beta programs](https://docs.gitlab.com/ee/policy/experiment-beta-support.html), feature flags, and/or user research to help build confidence in your decision. In terms of talking about your feature, it's ok to add a release post item that announces your incomplete feature (making clear that it is an early iteration, and points to the direction for the feature) and follow up in a later release post with a new item when you've completed more of the functionality. As long as you call it cookie dough, not a cookie, it manages user expectations. MVC means reducing the scope so we can ship quickly. It doesn't mean shipping something that hurts the usability of GitLab. First impressions are important. A feature that does not offer enough value or hinders the user experience may have a negative effect that discourages users from trying that feature again in the future. If there are obvious gaps in your MVC or you can anticipate follow-up requests, consider whether your feature is complete enough to be released to users. If you are unsure whether your feature is complete enough to be an MVC (or if you know your feature is not complete enough to be an MVC and you want to gather additional feedback), you can use approaches such as dogfooding, [beta programs](https://docs.gitlab.com/ee/policy/development_stages_support.html), feature flags, and/or user research to help build confidence in your decision. In terms of talking about your feature, it's ok to add a release post item that announces your incomplete feature (making clear that it is an early iteration, and points to the direction for the feature) and follow up in a later release post with a new item when you've completed more of the functionality. As long as you call it cookie dough, not a cookie, it manages user expectations.
Examples: Examples:
......
...@@ -21,7 +21,7 @@ In a secondary priority, this helps to [cultivate contributions from the Wider C ...@@ -21,7 +21,7 @@ In a secondary priority, this helps to [cultivate contributions from the Wider C
1. There are multiple categorizations of how customers and users access features: 1. There are multiple categorizations of how customers and users access features:
1. 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 1. 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
1. 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](https://docs.gitlab.com/ee/policy/experiment-beta-support.html) page. 1. 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](https://docs.gitlab.com/ee/policy/development_stages_support.html) page.
1. 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. 1. 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.
1. The existing process of accepting the terms & conditions of our testing agreement will be followed. 1. The existing process of accepting the terms & conditions of our testing agreement will be followed.
1. Guidance from UX & Product should be followed how this gets implemented for a consistent user experience. We should avoid adding friction. 1. Guidance from UX & Product should be followed how this gets implemented for a consistent user experience. We should avoid adding friction.
...@@ -29,7 +29,7 @@ In a secondary priority, this helps to [cultivate contributions from the Wider C ...@@ -29,7 +29,7 @@ In a secondary priority, this helps to [cultivate contributions from the Wider C
### FYI ### 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 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 ## Program nurturing activities
......
...@@ -30,7 +30,7 @@ To help maintain this balance, we ask for everyone to use this process when prop ...@@ -30,7 +30,7 @@ To help maintain this balance, we ask for everyone to use this process when prop
* Removing a navigation item * Removing a navigation item
* Changing the sort order of navigation items * Changing the sort order of navigation items
* Changing navigation functionality or features * Changing navigation functionality or features
* Launching an [Experiment](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#experiment) or [Beta](https://docs.gitlab.com/ee/policy/experiment-beta-support.html) feature * Launching an [Experiment](https://docs.gitlab.com/ee/policy/development_stages_support.html#experiment) or [Beta](https://docs.gitlab.com/ee/policy/development_stages_support.html) feature
* Changing the viewership of a navigation item (e.g. moving from disabled by default to enabled by default) * Changing the viewership of a navigation item (e.g. moving from disabled by default to enabled by default)
## When to change the navigation ## When to change the navigation
......
...@@ -78,7 +78,7 @@ Here are some resources to help you contribute to the design of AI-assisted feat ...@@ -78,7 +78,7 @@ Here are some resources to help you contribute to the design of AI-assisted feat
- [AI-human interaction in Pajamas](https://design.gitlab.com/usability/ai-human-interaction): Documentation on best practices for AI-human interaction. - [AI-human interaction in Pajamas](https://design.gitlab.com/usability/ai-human-interaction): Documentation on best practices for AI-human interaction.
- [AI Integration Effort FAQ](https://internal.gitlab.com/handbook/product/ai-strategy/ai-integration-effort/faq/): Internal handbook with frequently asked questions about AI integration efforts. **Internal handbook 🔒** - [AI Integration Effort FAQ](https://internal.gitlab.com/handbook/product/ai-strategy/ai-integration-effort/faq/): Internal handbook with frequently asked questions about AI integration efforts. **Internal handbook 🔒**
- [UX maturity requirements](/handbook/product/ai/ux-maturity/): Documentation on the UX maturity requirements to move AI features from Experiment to Beta to Generally Available (GA). - [UX maturity requirements](/handbook/product/ai/ux-maturity/): Documentation on the UX maturity requirements to move AI features from Experiment to Beta to Generally Available (GA).
- [Experiment, Beta, and Generally Available features](https://docs.gitlab.com/ee/policy/experiment-beta-support.html): Guidelines on the different stages of feature availability. - [Experiment, Beta, and Generally Available features](https://docs.gitlab.com/ee/policy/development_stages_support.html): Guidelines on the different stages of feature availability.
- [UX research in the AI space](/handbook/product/ux/ux-research/research-in-the-AI-space/): Documentation on conducting UX research in the AI domain. - [UX research in the AI space](/handbook/product/ux/ux-research/research-in-the-AI-space/): Documentation on conducting UX research in the AI domain.
- [Epic: UX of AI Integration](https://gitlab.com/groups/gitlab-org/-/epics/10269): A GitLab epic tracking the UX of AI integration. - [Epic: UX of AI Integration](https://gitlab.com/groups/gitlab-org/-/epics/10269): A GitLab epic tracking the UX of AI integration.
- [AI prototypes in Figma](https://www.figma.com/file/s4TP1i2Akd1VTh4jhbg234/AI-prioritized-prototypes?type=design&node-id=1%3A79&t=SNUCGun6HHxi9LaY-1): Access AI prototypes in Figma. - [AI prototypes in Figma](https://www.figma.com/file/s4TP1i2Akd1VTh4jhbg234/AI-prioritized-prototypes?type=design&node-id=1%3A79&t=SNUCGun6HHxi9LaY-1): Access AI prototypes in Figma.
......
...@@ -83,7 +83,7 @@ To get robust feedback during solution validation, it's recommended to collect a ...@@ -83,7 +83,7 @@ To get robust feedback during solution validation, it's recommended to collect a
**Tip:** Avoid asking the tempting "Would you use this?" question. **Tip:** Avoid asking the tempting "Would you use this?" question.
If you are maturing your AI feature towards [Generally Available](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#generally-available-ga), take a look at the [UX maturity requirements](/handbook/product/ai/ux-maturity/) for further guidance on metrics and success criteria. If you are maturing your AI feature towards [Generally Available](https://docs.gitlab.com/ee/policy/development_stages_support.html#generally-available-ga), take a look at the [UX maturity requirements](/handbook/product/ai/ux-maturity/) for further guidance on metrics and success criteria.
### Guideline 4: Learn about the cost of errors that AI will make ### Guideline 4: Learn about the cost of errors that AI will make
......
...@@ -73,7 +73,7 @@ This section describes the ownership, maintenance, and transition of product con ...@@ -73,7 +73,7 @@ This section describes the ownership, maintenance, and transition of product con
- The requirement needs to incubated by the GitLab Product Security team for other reasons - The requirement needs to incubated by the GitLab Product Security team for other reasons
- The Planning process will require that stakeholders from the requesting Product Security team, the Product Security Engineering team, and the relevant Product and Engineering teams discuss and collectively make a decision with regards to the need to put the feature or functionality behind a Product Security specific feature flag - The Planning process will require that stakeholders from the requesting Product Security team, the Product Security Engineering team, and the relevant Product and Engineering teams discuss and collectively make a decision with regards to the need to put the feature or functionality behind a Product Security specific feature flag
- As features and functionality become enabled for and available to users outside of the GitLab Product Security team, an agreed-upon transition will happen to handover ownership and maintenance - As features and functionality become enabled for and available to users outside of the GitLab Product Security team, an agreed-upon transition will happen to handover ownership and maintenance
- Standard GitLab processes and expectations around [support for expertiment, beta, and generally available features](https://docs.gitlab.com/ee/policy/experiment-beta-support.html) will be followed - Standard GitLab processes and expectations around [support for expertiment, beta, and generally available features](https://docs.gitlab.com/ee/policy/development_stages_support.html) will be followed
- General availability will constitute a complete transfer of ownership responsibilities, although handovers may occur earlier - General availability will constitute a complete transfer of ownership responsibilities, although handovers may occur earlier
## Build vs. Wait vs. Buy ## Build vs. Wait vs. Buy
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment