While we have moved to the [cross-functional prioritization process](/handbook/product/cross-functional-prioritization/) to empower teams to determine the optimal balance of all types of issues, we will keep Engineering Allocations as a way to allow teams to quickly shift to a critical priority, designating the EM as the DRI to drive the effort.
While we have moved to the [cross-functional prioritization process](/handbook/product/product-processes/cross-functional-prioritization/) to empower teams to determine the optimal balance of all types of issues, we will keep Engineering Allocations as a way to allow teams to quickly shift to a critical priority, designating the EM as the DRI to drive the effort.
Engineering is the DRI for mid/long term team efficiency, performance, security (incident response and anti-abuse capabilities), availability, and scalability. The expertise to proactively identify and iterate on these is squarely in the Engineering team. Whereas Product can support in performance issues as identified from customers. In some ways these efforts can be viewed as risk-mitigation or revenue protection. They also have the characteristic of being larger than one group at the stage level. Development would like to conduct an experiment to focus on initiatives that should help the organization scale appropriately in the long term. We are treating these as a percent investment of time associated with a stage or category. The percent of investment time can be viewed as a prioritization budget outside normal Product/Development assignments.
@@ -37,7 +37,7 @@ One of the most frequent questions we get as part of this experiment is "How doe
To help with getting items that on the list for consideration, we will be performing a survey periodically. The survey will consist of the following questions:
1. If you were given a % of engineering development per release to work on something, what would it be?
1. How would you justify it? Have you tried leveraging [cross-functional prioritization process](/handbook/product/cross-functional-prioritization/) before considering an engineering allocation?
1. How would you justify it? Have you tried leveraging [cross-functional prioritization process](/handbook/product/product-processes/cross-functional-prioritization/) before considering an engineering allocation?
We will keep the list of questions short to solicit the most input. The survey will go out to members of the Development, Quality, Security. After we get the results, we will consider items for potential adding as an Engineering Allocation.
@@ -18,4 +18,4 @@ Any of the items with a "*" are considered issues driven by the attached [SLO or
1. Security Issues labeled with `bug::vulnerability` must be delivered according to the stated [SLO](/handbook/security/#severity-and-priority-labels-on-security-issues)
1. Issues supporting our product's scale which include `bug::availability` with [specific SLOs](/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#availability) as well as `infradev`, `Corrective Action`, `ci-decomposition::phase*` that follow the stated [`type::bug` SLO](/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#severity-slos)
Any issues outside of these labels are to be prioritized using [cross-functional prioritization](/handbook/product/cross-functional-prioritization/). Auto-scheduling issues based on automation or triage policies are not forced prioritization. These issues can be renegotiated for milestone delivery and reassigned by the DRI.
Any issues outside of these labels are to be prioritized using [cross-functional prioritization](/handbook/product/product-processes/cross-functional-prioritization/). Auto-scheduling issues based on automation or triage policies are not forced prioritization. These issues can be renegotiated for milestone delivery and reassigned by the DRI.
@@ -18,4 +18,4 @@ Any of the items with a "*" are considered issues driven by the attached [SLO or
1. Security Issues labeled with `bug::vulnerability` must be delivered according to the stated [SLO](/handbook/security/engaging-with-security/#severity-and-priority-labels-on-security-issues)
1. Issues supporting our product's scale which include `bug::availability` with [specific SLOs](/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#availability) as well as `infradev`, `Corrective Action`, `ci-decomposition::phase*` that follow the stated [`type::bug` SLO](/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#severity-slos)
Any issues outside of these labels are to be prioritized using [cross-functional prioritization](/handbook/product/cross-functional-prioritization/). Auto-scheduling issues based on automation or triage policies are not forced prioritization. These issues can be renegotiated for milestone delivery and reassigned by the DRI.
Any issues outside of these labels are to be prioritized using [cross-functional prioritization](/handbook/product/product-processes/cross-functional-prioritization/). Auto-scheduling issues based on automation or triage policies are not forced prioritization. These issues can be renegotiated for milestone delivery and reassigned by the DRI.
Our CI syntax keeps evolving. We cannot support all keywords indefinitely, so deprecating and removing keywords is inevitable.
GitLab does not have a versioning system for CI/CD configuration. Therefore, it is critical to over-communicate our deprecation purposes to our users and take the necessary precautions to reduce the impact on their projects. Deprecating a keyword is risky because it will break all pipelines using it, and in some cases, users are not aware of the keyword they use in their pipeline. The deprecation process described below is similar to the [deprecating and removing features](/handbook/product/gitlab-the-product/#process-for-deprecating-and-removing-a-feature) process, with additional steps to reduce the risks which involved with removing a CI/CD keyword.
GitLab does not have a versioning system for CI/CD configuration. Therefore, it is critical to over-communicate our deprecation purposes to our users and take the necessary precautions to reduce the impact on their projects. Deprecating a keyword is risky because it will break all pipelines using it, and in some cases, users are not aware of the keyword they use in their pipeline. The deprecation process described below is similar to the [deprecating and removing features](/handbook/product/categories/gitlab-the-product/#process-for-deprecating-and-removing-a-feature) process, with additional steps to reduce the risks which involved with removing a CI/CD keyword.
1. Deprecation notice - Syntax removal introduces a breaking change, as outlined in our deprecation process, we must notify the community and customers, which means including a deprecation notice in the monthly release post.
