- Followup: [Align on the Performance Indicator for Disaster Recovery capabilities for GitLab.com and GitLab Dedicated](https://gitlab.com/gitlab-com/gl-infra/mstaff/-/issues/397)
-[Top-Level Initiative Epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/479)(only accessible from within the company)
-[Limited Availability Epic - main project epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/484)(only accessible from within the company)
-[Cross-Functional Limited Availability Requirements](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/866)(only accessible from within the company)
@@ -41,15 +41,15 @@ The exit criteria for GitLab Dedicated Top Cross-Functional Initiative are the s
### How We Work
The GitLab Dedicated Initiative Working Group follows the [same processes as the GitLab Dedicated Engineering team](/handbook/engineering/infrastructure/team/gitlab-dedicated/#how-we-work) from the Dedicated Engineering team page. This includes:
The GitLab Dedicated Initiative Working Group follows the [same processes as the GitLab Dedicated Engineering team](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#how-we-work) from the Dedicated Engineering team page. This includes:
-[Labels and usage](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#labels)
### Epic Management
See [epic management and hierarchy on Dedicated Team Page](/handbook/engineering/infrastructure/team/gitlab-dedicated/#epic-hierarchy).
See [epic management and hierarchy on Dedicated Team Page](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#epic-hierarchy).
The [Cross-Functional LA Requirements epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/866) is a child epic of the GitLab Dedicated [Top Level epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/479). This cross-functional epic is comprised of function-specific child epics managed by the DRI for that functional area. These functional child epics have sub-epics and/or issues representing groups of related tasks that are delivered in a specific phase from [Limited Availability Roadmap](https://about.gitlab.com/direction/gitlab_dedicated/#limited-availability-roadmap).
@@ -75,9 +75,9 @@ Milestones for functional work from the [Cross-Functional LA Requirements epic](
## Status Updates
The GitLab Dedicated Initiative Working Group follows the [status update process](/handbook/engineering/infrastructure/team/gitlab-dedicated/#status-updates) from Dedicated Engineering team page. The status updates that Functional DRIs make in their respective Functional Epics will incorporated in the [status update cadence](/handbook/engineering/infrastructure/team/gitlab-dedicated/#status-updates) and used to update the status of the [Cross-Functional epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/866) and the [Top-Level Initiative Epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/479).
The GitLab Dedicated Initiative Working Group follows the [status update process](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#status-updates) from Dedicated Engineering team page. The status updates that Functional DRIs make in their respective Functional Epics will incorporated in the [status update cadence](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#status-updates) and used to update the status of the [Cross-Functional epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/866) and the [Top-Level Initiative Epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/479).
In addition to the [status process from Dedicated team page](/handbook/engineering/infrastructure/team/gitlab-dedicated/#status-updates), the Dedicated initiative has additional status update requirements as a Top Cross-Functional initiative that the Initiative DRI is responsible for:
In addition to the [status process from Dedicated team page](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#status-updates), the Dedicated initiative has additional status update requirements as a Top Cross-Functional initiative that the Initiative DRI is responsible for:
- Key Reviews
- Top Initiative Quarterly Meeting
@@ -124,13 +124,13 @@ Below are the functional areas involved in this Cross-Functional Initiative as w
| Member | Josh Lambert | Director of Product, Enablement |
Functional DRIs are also mentioned at the top of the description of their function's child epics in the [Cross-Functional LA Requirements epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/866) per [epic structure](/handbook/engineering/infrastructure/team/gitlab-dedicated/#epic-structure).
Functional DRIs are also mentioned at the top of the description of their function's child epics in the [Cross-Functional LA Requirements epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/866) per [epic structure](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#epic-structure).
### Function DRI Responsibilities
Please see [Functional Lead on Working Group page](/handbook/company/working-groups#required-roles).
Functional DRIs are responsible for maintaining their function's epics by following process mentioned in [Epic Owner Responsibilities](/handbook/engineering/infrastructure/team/gitlab-dedicated/#epic-owner-responsibilities) and [Epic Structure](/handbook/engineering/infrastructure/team/gitlab-dedicated/#epic-structure).
Functional DRIs are responsible for maintaining their function's epics by following process mentioned in [Epic Owner Responsibilities](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#epic-owner-responsibilities) and [Epic Structure](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#epic-structure).
Each epic has a single DRI who is responsible for delivering the project. DRIs for each epic are listed at the top of the description of each epic per Epic Structure. Epic DRI responsibilities are in [https://handbook.gitlab.com/handbook/engineering/infrastructure/team/gitlab-dedicated/#epic-owner-responsibilities](/handbook/engineering/infrastructure/team/gitlab-dedicated/#epic-owner-responsibilities)
Each epic has a single DRI who is responsible for delivering the project. DRIs for each epic are listed at the top of the description of each epic per Epic Structure. Epic DRI responsibilities are in [https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#epic-owner-responsibilities](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#epic-owner-responsibilities)
1. Engineering epic DRIs can be found within children epics of [GitLab Dedicated epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/479).
@@ -311,8 +311,8 @@ Each epic has a single DRI who is responsible for delivering the project. DRIs f
The DRI needs to:
1. Work with others to move issues through the boards
1. Ensure epic meets criteria outlined in [Epic Structure](/handbook/engineering/infrastructure/team/gitlab-dedicated/#epic-structure)
1. Provide updates on DRI's epic in epic description according to process outlined in [Status Update Process](/handbook/engineering/infrastructure/team/gitlab-dedicated/#status-update-process) below.
1. Ensure epic meets criteria outlined in [Epic Structure](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#epic-structure)
1. Provide updates on DRI's epic in epic description according to process outlined in [Status Update Process](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#status-update-process) below.
Throughout the project, the DRI should continue to adjust the epic description and structure to keep it current with the project status.
@@ -412,15 +412,15 @@ Both Engineering Cross-Functional DRIs should provide weekly updates for the DRI
1.**By Wednesday at 21:00 UTC** the DRI for a project is expected to update the status block in the epic description to:
1. Format for weekly update: **Date of Update** (YYYY-MM-DD)
1. Brief update for each of these four areas:
1. Indicate project [Health Status by label](/handbook/engineering/infrastructure/team/gitlab-dedicated/#workflow-labels).
1. Indicate project [Health Status by label](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#workflow-labels).
1. Briefly highlight project status.
1. Indicate progress items since the last update.
1. Indicate any project blockers.
1. Indicate planned next steps, or mitigations required to progress. This enables other engineers and other managers to have good information about projects in an asynchronous fashion.
1. If the DRI for a sub-epic is different than the epic DRI, the epic DRI is responsible for getting updates from the sub-epic DRI.
1.**Update Workflow and Health label** - After each status update, the Workflow label and Health label should be updated. See [Epic labels criteria](/handbook/engineering/infrastructure/team/gitlab-dedicated/#workflow-labels)
1.**Update Workflow and Health label** - After each status update, the Workflow label and Health label should be updated. See [Epic labels criteria](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#workflow-labels)
1.**Top-Level Epic Status Update**[automation synthesizes updates from status section](/handbook/engineering/infrastructure/team/gitlab-dedicated/#status-update-automation) from description of active epics to provide initiative status in the status section in the description of the top-level initiative Epic.
1.**Top-Level Epic Status Update**[automation synthesizes updates from status section](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#status-update-automation) from description of active epics to provide initiative status in the status section in the description of the top-level initiative Epic.
1.**Weekly engineering/product sync at 16:30 UTC on Mondays** Dedicated engineering/product meeting is used to discuss status updates and potential mitigations as necessary.
@@ -438,6 +438,8 @@ We provide reports on status of GitLab Dedicated to meet Top Cross-Functional In
### Backlog Refinement
> **Note:** Epic backlog refinement is integrated into the [Environment Automation team's Quarterly Planning Process](environment-automation/#quarterly-planning-process) and occurs during **Step 4 (Weeks -2 to -1)** prior to each quarter.
Prior to the start of a new quarter, the team will spend time refining the Epic backlog. This process will be led by the EM + PM, who will go through the Epics targeted for the upcoming quarter (according to the [roadmap](https://about.gitlab.com/direction/gitlab_dedicated/#roadmap)) and ensure each Epic contains the following information (pulling in different stakeholders to help fill in the details as necessary):
- MVC Scope
@@ -445,7 +447,7 @@ Prior to the start of a new quarter, the team will spend time refining the Epic
- Link to high-level design
- Estimated level of complexity
While the above information is being added, the Epic will move from  to . Once the information has been finalized, the Epic will move to .
While the above information is being added, the Epic will move from  to . Once the information has been finalized, the Epic will move to .
Having this set of refined epics will help us plan for the upcoming quarter and allow engineers to quickly get started on an Epic once it's ready to be picked up during the quarter.
@@ -476,7 +478,7 @@ GitLab Dedicated team respects the Company principle of [everything starting wit
1. Ensure that merge requests include in the description `Closes #<issue>` or `Related to #<issue>` so that the merge request change is linked to the appropriate issue within GitLab.
1. Use draft to indicate the readiness of the MR. In general, remove draft before going into the review process.
1. It is expected that MR author assigns reviewers once the MR is ready to go.
1. Reviewers should review the change and leave comments with questions or suggestions. Please follow the [merge request reviewer guidelines](/handbook/engineering/infrastructure/team/gitlab-dedicated/#merge-request-reviewers) and the [resolving threads guidelines](/handbook/engineering/infrastructure/team/gitlab-dedicated/#resolving-threads-on-a-merge-request) documented below.
1. Reviewers should review the change and leave comments with questions or suggestions. Please follow the [merge request reviewer guidelines](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#merge-request-reviewers) and the [resolving threads guidelines](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/#resolving-threads-on-a-merge-request) documented below.
The MR approval rule settings for all projects should be:
@@ -570,19 +572,19 @@ The standard progression of workflow is from top to bottom in the table below:
| State Label | Description |
| ----------- | ----------- |
|  | Default label added to issues created. Issues with this label need to be confirmed as work we would consider. If we don't want to consider the issue further, we mark it with `workflow-infra::Cancelled` and close it. If this issue does not need Product validation, and we are ready for implementation, issue is moved to `workflow-infra::Ready`. Otherwise, we move it to the next stage `workflow-infra::Proposal`. |
|  | In this stage, proposal is being created and put forward for review with the rest of the team. Issues in this stage are also a part of Product validation workflow. If there are no further questions or blockers, the issue is supposed to be sufficiently refined and ready for implementation and can be moved into `workflow-infra::Ready`. The epics that encapsulate the implementation work for customer facing features must have a Product Manager sign-off before they can be moved to `workflow-infra::Ready` |
|  | The issue is waiting to be picked up for work. |
|  | Issue is assigned to a DRI and work has started. |
|  | Issue is updated with the outcome of the work that was done, and this label is applied and issue closed. |
|  | Default label added to issues created. Issues with this label need to be confirmed as work we would consider. If we don't want to consider the issue further, we mark it with `workflow-infra::Cancelled` and close it. If this issue does not need Product validation, and we are ready for implementation, issue is moved to `workflow-infra::Ready`. Otherwise, we move it to the next stage `workflow-infra::Proposal`. |
|  | In this stage, proposal is being created and put forward for review with the rest of the team. Issues in this stage are also a part of Product validation workflow. If there are no further questions or blockers, the issue is supposed to be sufficiently refined and ready for implementation and can be moved into `workflow-infra::Ready`. The epics that encapsulate the implementation work for customer facing features must have a Product Manager sign-off before they can be moved to `workflow-infra::Ready` |
|  | The issue is waiting to be picked up for work. |
|  | Issue is assigned to a DRI and work has started. |
|  | Issue is updated with the outcome of the work that was done, and this label is applied and issue closed. |
There are three other workflow labels of importance:
| State Label | Description |
| ----------- | ----------- |
|  | Work in the issue is being abandoned due to external factors or decision to not resolve the issue. After applying this label, issue will be closed. |
|  | If no update has been provided in an issue for over a week, the issue will get this label. The team Engineering Manager is responsible for reviewing the status of the issue and helping it move along. |
|  | Work is blocked due external dependencies or other external factors. Where possible, a [blocking issue](https://docs.gitlab.com/ee/user/project/issues/related_issues.html) should also be set. After applying this label, issue will be regularly triaged by the team until the label can be removed. |
|  | Work in the issue is being abandoned due to external factors or decision to not resolve the issue. After applying this label, issue will be closed. |
|  | If no update has been provided in an issue for over a week, the issue will get this label. The team Engineering Manager is responsible for reviewing the status of the issue and helping it move along. |
|  | Work is blocked due external dependencies or other external factors. Where possible, a [blocking issue](https://docs.gitlab.com/ee/user/project/issues/related_issues.html) should also be set. After applying this label, issue will be regularly triaged by the team until the label can be removed. |
#### Support labels
@@ -607,8 +609,8 @@ These scoped labels are intended to distinguish generic work to everything made
| Cloud Provider Label | Description |
| ----------- | ----------- |
|  | Amazon Cloud specific implementation |
|  | Google Cloud specific implementation |
|  | Amazon Cloud specific implementation |
|  | Google Cloud specific implementation |
#### Workaround labels
@@ -616,7 +618,7 @@ Scoped workaround labels are intended to track temporary workarounds applied to
| Workaround label | Description |
| ----------- | ----------- |
|  | This label is applied to issues describing workarounds applied to tenant instances |
|  | This label is applied to issues describing workarounds applied to tenant instances |
@@ -4,9 +4,9 @@ title: Environment Automation Ecosystem Team
## Summary
Ecosystem is part of [Environment Automation](/handbook/engineering/infrastructure/team/gitlab-dedicated/environment-automation/) team, which is within the [Dedicated Group](/handbook/engineering/infrastructure/team/gitlab-dedicated/). Our mission is to maintain ecosystem SLA at the same level as customer SLA by applying identical standards and automation to GitLab Dedicated and all external dependencies.
Ecosystem is part of [Environment Automation](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/environment-automation/) team, which is within the [Dedicated Group](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/). Our mission is to maintain ecosystem SLA at the same level as customer SLA by applying identical standards and automation to GitLab Dedicated and all external dependencies.
We follow the same processes as listed on the [Environment Automation](/handbook/engineering/infrastructure/team/gitlab-dedicated/environment-automation/) and [Dedicated Group](/handbook/engineering/infrastructure/team/gitlab-dedicated/) pages, unless a difference exists which is explicitly noted on this page.
We follow the same processes as listed on the [Environment Automation](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/environment-automation/) and [Dedicated Group](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/) pages, unless a difference exists which is explicitly noted on this page.
