Add latest changes from gitlab-org/gitlab@16-0-stable-eev16.0.0-rc42

14 files changed, 824 insertions, 207 deletions

diff --git a/.gitlab/issue_templates/AI Project Proposal.md b/.gitlab/issue_templates/AI Project Proposal.md
new file mode 100644
index 00000000000..072e7ed9ed3
--- /dev/null
+++ b/.gitlab/issue_templates/AI Project Proposal.md
@@ -0,0 +1,147 @@
+<!--
+HOW TO USE THIS TEMPLATE
+To propose an AI experiment, focus on completing the “Experiment” section first. As you refine the idea and gather feedback on your experiment, use the “Feature release” section to define how it will evolve as a Beta or GA capability. It's important that we link experiment to feature release. Feel free to add sections, but keep the existing ones.
+
+You can choose how to get started with this template. For example, the proposal can start as an issue, and then be promoted to an epic to house all the work related to the experiment/prototype and feature release. If you prefer to start with an epic, you have to manually apply the proposal template. Regardless, if the experiment is eventually prioritized for development, the template content will need to appear in a top-level epic so it can be tracked alongside other prioritized AI experiments.
+
+TITLE FORMAT
+🤖 [AI Proposal] {Need/outcome} {Beneficiary} {Job/Small Job}
+
+The title should be something that is easily understood that quickly communicates the intent of the project allowing team members to easily understand and recognize the expected work that will be done. A proposal title should combine the beneficiary of the feature/UI, the job it will allow them to accomplish (see https://about.gitlab.com/handbook/product/ux/jobs-to-be-done/#how-to-write-a-jtbd), and their expected outcome when the work is delivered. Well-defined statements are concise without sacrificing the substance of the proposal so that anyone can understand it at a glance. (e.g. {Reduce the effort} {for security teams} {when prioritizing business-critical risks in their assets}).
+-->
+
+# Experiment
+
+This section should be completed prior to work on the Experiment beginning.
+
+# [Experiment](https://docs.gitlab.com/ee/policy/alpha-beta-support.html#experiment)
+
+##  Problem to be solved
+
+### User problem
+_What user problem will this solve?_
+
+### Solution hypothesis
+_Why do you believe this AI solution is a good way to solve this problem?_
+
+### Assumption
+_What assumptions are you making about this problem and the solution?_
+
+### Personas
+_What [personas](https://about.gitlab.com/handbook/product/personas/#list-of-user-personas) have this problem, who is the intended user?_
+
+## Proposal
+<!-- Explain the proposed changes, including details around usage and business drivers. -->
+
+### Success
+_How will you measure whether this experiment is a success?_
+
+
+# Feature release
+<!-- DO NOT REMOVE THIS SECTION
+Although the initial focus is on the “Experiment” section, do not remove this “Feature release” section. It's important that we link experiment to feature release. Fill this section as you progress.
+-->
+### Main Job story
+_What job to be done will this solve?_
+<!-- What is the [Main Job story](https://about.gitlab.com/handbook/product/ux/jobs-to-be-done/#how-to-write-a-jtbd) that this proposal was derived from? (e.g. When I am on triage rotation, I want to address all the business-critical risks in my assets, So I can minimize the likelihood of my organization being compromised by a security breach.) -->
+
+## Proposal updates/additions
+<!-- Explain any changes or updates to the original proposal from the experiment, including details around usage, business drivers, and reasonings that drove the updates/additions. -->
+
+### Problem validation
+_What validation exists that customers have this problem?_
+<!-- Refer to https://about.gitlab.com/handbook/product/ux/ux-research/research-in-the-AI-space/#guideline-1-problem-validation --- to help identify and understand user needs -->
+
+### Business objective
+_What business objective will be achieved with this proposal?_
+<!-- Objectives (from a business point of view) that will be achieved upon completion. (For instance, Increase engagement by making the experience efficient while reducing the chances of users overlooking high-priority items. -->
+
+### Confidence
+_Has this proposal been derived from research?_
+<!-- How well do we understand the user's problem and their need? Refer to https://about.gitlab.com/handbook/product/ux/product-design/ux-roadmaps/#confidence to assess confidence -->
+
+| Confidence        | Research                       |
+| ----------------- | ------------------------------ |
+| [High/Medium/Low] | [research/insight issue](Link) |
+
+### Requirements
+_What tasks or actions should the user be capable of performing with this feature?_
+<!-- Requirements can be taken from existing features or design issues used to build this proposal. Any related issues should be linked with this issue in the Feature/solution issues section below. They are more granular validated needs, goals, and additional details that the proposal encompasses. -->
+
+> ⚠️ Related feature and research issues should be linked in the related issues section (Delete this line when this is done)
+
+#### The user needs to be able to:
+- ...
+- ...
+
+## Checklist
+
+### Experiment
+<details> <summary> Issue information </summary>
+
+- [ ] Add information to the issue body about:
+    - [ ] The user problem being solved
+    - [ ] Your assumptions
+    - [ ] Who it's for, list of personas impacted
+    - [ ] Your proposal
+- [ ] Add relevant designs to the Design Management area of the issue if available
+- [ ] Confirm that an unexpected outage of this feature will not negatively impact the application or other features
+- [ ] Add a feature flag so that this feature can be quickly disabled if/when needed
+- [ ] If this experiment introduces a new service or data store, ensure it is not processing or storing [red data](https://about.gitlab.com/handbook/security/data-classification-standard.html#data-classification-levels) without a security and if needed legal review
+  - *NOTE*: We recommend using one of the already adopted models or data stores. If you need to use something else, be aware that using other models or data stores will require additional review during the feature stage for operational fitness and compliance.
+- [ ] Ensure this issue has the ~wg-ai-integration label to ensure visibility to various teams working on this
+
+</details>
+
+### Feature release
+<details> <summary> Issue information </summary>
+
+- [ ] Add information to the issue body about:
+    - [ ] Your proposal
+    - [ ] The Job Statement it's expected to satisfy
+    - [ ] Details about the user problem and provide any research or problem validation
+    - [ ] List the personas impacted by the proposal.
+- [ ] Add all relevant solution validation issues to the Linked items section that shows this proposal will solve the customer problem, or details explaining why it's not possible to provide that validation.
+- [ ] Add relevant designs to the Design Management area of the issue.
+- [ ] You have adhered to our [Definition of Done](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#definition-of-done) standards
+- [ ] Ensure this issue has the ~wg-ai-integration label to ensure visibility to various teams working on this
+
+</details>
+
+<details> <summary> Technical needs </summary>
+
+- [ ] Please consider the operational aspects of the feature you are creating. A list of things to think about is in: https://gitlab.com/gitlab-org/gitlab/-/issues/403859. We will be improving this process in the future: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117637#note_1353253349. 
+- [ ] @ mention your [AppSec Stable Counterpart](https://about.gitlab.com/handbook/product/categories/) and read the [AI secure coding guidelines](https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#artificial-intelligence-ai-features)
+
+1. Work estimate and skills needs to build an ML viable feature: To build any ML feature depending on the work, there are many personas that contribute including, Data Scientist, NLP engineer, ML Engineer, MLOps Engineer, ML Infra engineers, and Fullstack engineer to integrate the ML Services with Gitlab. Post-prototype we would assess the skills needed to build a production-grade ML feature for the prototype.
+2. Data Limitation: We would like to upfront validate if we have viable data for the feature including whether we can use the DataOps pipeline of ModelOps or create a custom one. We would want to understand the training data, test data, and feedback data to dial up the accuracy and the limitations of the data.
+3. Model Limitation: We would want to understand if we can use an open-source pre-trained model, tune and customize it or start a model from scratch as well. Further, we would assess based on the ModelOps model evaluation framework which would be the right model to use based on the use case.
+4. Cost, Scalability, Reliability: We would want to estimate the cost of hosting, serving, inference of the model, and the full end-to-end infrastructure including monitoring and observability.
+5. Legal and Ethical Framework: We would want to align with legal and ethical framework like any other ModelOps features to cover across the nine principles of responsible ML and any legal support needed.
+
+</details>
+
+<details> <summary> Dependency needs </summary>
+
+- [ ] Please consider the operational aspects of the service you are creating. A list of things to think about is in: https://gitlab.com/gitlab-org/gitlab/-/issues/403859. We will be improving this process in the future: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117637#note_1353253349. 
+
+</details>
+
+<details> <summary> Legal needs </summary>
+
+- [ ]  TBD
+
+</details>
+
+## Additional resources
+- If you'd like help with technical validation, or would like to discuss UX considerations for AI mention the AI Assisted group using `@gitlab-org/modelops/applied-ml`.
+- Read about our [AI Integration strategy](https://internal-handbook.gitlab.io/handbook/product/ai-strategy/ai-integration-effort/)
+- Slack channels
+    - `#wg_ai_integration` - Slack channel for the working group and the high level alignment on getting AI ready for Production (Development, Product, UX, Legal, etc.) But from the other channels fell free to reach out and post progress here
+    - `#ai_integration_dev_lobby` - Channel for all implementation related topics and discussions of actual AI features (e.g. explain the code)
+    - `#ai_enablement_team` - Channel for the AI Enablement Team which is building the base for all features (experimentation API, Abstraction Layer, Embeddings, etc.)
+
+
+/label ~wg-ai-integration
+/cc @tmccaslin @hbenson @wayne @pedroms @jmandell
+/confidential
diff --git a/.gitlab/issue_templates/Deprecations.md b/.gitlab/issue_templates/Deprecations.md
index 49f1129fe89..30d01c5f5c4 100644
--- a/.gitlab/issue_templates/Deprecations.md
+++ b/.gitlab/issue_templates/Deprecations.md
@@ -49,9 +49,9 @@ Which tier is this feature available in?
 Please add links to the relevant merge requests.
 
 - As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: `14.8, 14.9, 14.10, 15.0` – `14.8` is the third milestone preceding the major release):
-    - [ ] A [deprecation announcement entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-a-deprecation-announcement) has been created so the deprecation will appear in release posts and on the [general deprecation page](https://docs.gitlab.com/ee/update/deprecations).
+    - [ ] A [deprecation announcement entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-the-announcement) has been created so the deprecation will appear in release posts and on the [general deprecation page](https://docs.gitlab.com/ee/update/deprecations).
     - [ ] Documentation has been updated to mark the feature as [deprecated](https://docs.gitlab.com/ee/development/documentation/versions.html#deprecations-and-removals).
-- [ ] On or before the major milestone: A [removal entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#removals) has been created so the removal will appear on the [removals by milestones](https://docs.gitlab.com/ee/update/removals) page and be announced in the release post.
+- [ ] On or before the major milestone: A [removal entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-the-announcement-1) has been created so the removal will appear on the [removals by milestones](https://docs.gitlab.com/ee/update/removals) page and be announced in the release post.
 - On the major milestone:
     - [ ] The deprecated item has been removed.
     - [ ] If the removal of the deprecated item is a [breaking change](https://about.gitlab.com/handbook/product/gitlab-the-product/#examples-of-breaking-changes), the merge request is labeled ~"breaking change".
diff --git a/.gitlab/issue_templates/Feature Flag Cleanup.md b/.gitlab/issue_templates/Feature Flag Cleanup.md
index d32b0c874d4..f96165fd359 100644
--- a/.gitlab/issue_templates/Feature Flag Cleanup.md
+++ b/.gitlab/issue_templates/Feature Flag Cleanup.md
@@ -48,4 +48,4 @@ Are there any other stages or teams involved that need to be kept in the loop?
 - [ ] Close this rollout issue.
 
 
-/label ~"feature flag" ~"type::feature" ~"feature::addition"
+/label ~"feature flag" ~"type::maintenance" ~"maintenance::removal"
diff --git a/.gitlab/issue_templates/Feature Flag Roll Out.md b/.gitlab/issue_templates/Feature Flag Roll Out.md
index 5791eca11ff..5efc9304a4e 100644
--- a/.gitlab/issue_templates/Feature Flag Roll Out.md
+++ b/.gitlab/issue_templates/Feature Flag Roll Out.md
@@ -43,9 +43,9 @@ Are there any other stages or teams involved that need to be kept in the loop?
 
 <!-- What are the settings we need to configure in order to have this feature viable? -->
 
-<!-- 
+<!--
 Example below:
- 
+
 1. Enable service ping collection
    `ApplicationSetting.first.update(usage_ping_enabled: true)`
 -->
@@ -57,7 +57,7 @@ Example below:
 ### What can we monitor to detect problems with this?
 
 <!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
-_Consider mentioning checks for 5xx errors or other anomalies like an increase in redirects 
+_Consider mentioning checks for 5xx errors or other anomalies like an increase in redirects
 (302 HTTP response status)_
 
 ### What can we check for monitoring production after rollouts?
@@ -66,7 +66,7 @@ _Consider adding links to check for Sentry errors, Production logs for 5xx, 302s
 
 ## Rollout Steps
 
-Note: Please make sure to run the chatops commands in the slack channel that gets impacted by the command. 
+Note: Please make sure to run the chatops commands in the slack channel that gets impacted by the command.
 
 ### Rollout on non-production environments
 
@@ -75,11 +75,15 @@ Note: Please make sure to run the chatops commands in the slack channel that get
     - [ ] `/chatops run auto_deploy status <merge-commit-of-your-feature>`
 - [ ] Enable the feature globally on non-production environments.
     - [ ] `/chatops run feature set <feature-flag-name> true --dev --staging --staging-ref`
+    - If the feature flag causes QA end-to-end tests to fail:
+      - [ ] Disable the feature flag on staging to avoid blocking [deployments](https://about.gitlab.com/handbook/engineering/deployments-and-releases/deployments/).
 - [ ] Verify that the feature works as expected. Posting the QA result in this issue is preferable.
       The best environment to validate the feature in is [staging-canary](https://about.gitlab.com/handbook/engineering/infrastructure/environments/#staging-canary)
       as this is the first environment deployed to. Note you will need to make sure you are configured to use canary as outlined [here](https://about.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/)
       when accessing the staging environment in order to make sure you are testing appropriately.
 
+For assistance with QA end-to-end test failures, please reach out via the `#quality` Slack channel. Note that QA test failures on staging-ref [don't block deployments](https://about.gitlab.com/handbook/engineering/infrastructure/environments/staging-ref/#how-to-use-staging-ref).  
+
 ### Specific rollout on production
 
 For visibility, all `/chatops` commands that target production should be executed in the `#production` slack channel and cross-posted (with the command results) to the responsible team's slack channel (`#g_TEAM_NAME`).
@@ -104,7 +108,7 @@ For visibility, all `/chatops` commands that target production should be execute
 - [ ] Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production.
   If a different developer will be covering, or an exception is needed, please inform the oncall SRE by using the `@sre-oncall` Slack alias.
 - [ ] Ensure that documentation has been updated ([More info](https://docs.gitlab.com/ee/development/documentation/feature_flags.html#features-that-became-enabled-by-default)).
-- [ ] Leave a comment on [the feature issue][main-issue] announcing estimated time when this feature flag will be enabled on GitLab.com. 
+- [ ] Leave a comment on [the feature issue][main-issue] announcing estimated time when this feature flag will be enabled on GitLab.com.
 - [ ] Ensure that any breaking changes have been announced following the [release post process](https://about.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes) to ensure GitLab customers are aware.
 - [ ] Notify `#support_gitlab-com` and your team channel ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#communicate-the-change)).
 - [ ] Ensure that the feature flag rollout plan is reviewed by another developer familiar with the domain.
diff --git a/.gitlab/issue_templates/Geo Replicate a new Git repository type.md b/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
index eee989ed21e..05a643c967c 100644
--- a/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
+++ b/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
@@ -54,7 +54,7 @@ Geo secondary sites have a [Geo tracking database](https://gitlab.com/gitlab-org
   ```ruby
   # frozen_string_literal: true
 
-  class CreateCoolWidgetRegistry < Gitlab::Database::Migration[2.0]
+  class CreateCoolWidgetRegistry < Gitlab::Database::Migration[2.1]
     def change
       create_table :cool_widget_registry, id: :bigserial, force: :cascade do |t|
         t.bigint :cool_widget_id, null: false
@@ -80,11 +80,19 @@ Geo secondary sites have a [Geo tracking database](https://gitlab.com/gitlab-org
         t.index :retry_at
         t.index :state
         # To optimize performance of CoolWidgetRegistry.verification_failed_batch
-        t.index :verification_retry_at, name: :cool_widget_registry_failed_verification, order: "NULLS FIRST", where: "((state = 2) AND (verification_state = 3))"
+        t.index :verification_retry_at,
+          name: :cool_widget_registry_failed_verification,
+          order: "NULLS FIRST",
+          where: "((state = 2) AND (verification_state = 3))"
         # To optimize performance of CoolWidgetRegistry.needs_verification_count
-        t.index :verification_state, name: :cool_widget_registry_needs_verification, where: "((state = 2) AND (verification_state = ANY (ARRAY[0, 3])))"
+        t.index :verification_state,
+          name: :cool_widget_registry_needs_verification,
+          where: "((state = 2) AND (verification_state = ANY (ARRAY[0, 3])))"
         # To optimize performance of CoolWidgetRegistry.verification_pending_batch
-        t.index :verified_at, name: :cool_widget_registry_pending_verification, order: "NULLS FIRST", where: "((state = 2) AND (verification_state = 0))"
+        t.index :verified_at,
+          name: :cool_widget_registry_pending_verification,
+          order: "NULLS FIRST",
+          where: "((state = 2) AND (verification_state = 0))"
       end
     end
   end
@@ -92,7 +100,7 @@ Geo secondary sites have a [Geo tracking database](https://gitlab.com/gitlab-org
 
 - [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
 
-- [ ] Add the new table to the [database dictionary](database_dictionary.md) defined in [`ee/db/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/db/docs):
+- [ ] Add the new table to the [database dictionary](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/database/database_dictionary.md) defined in [`ee/db/geo/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/db/geo/docs):
 
   ```yaml
   table_name: cool_widget_registry
@@ -129,7 +137,7 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
   ```ruby
   # frozen_string_literal: true
 
-  class CreateCoolWidgetStates < Gitlab::Database::Migration[2.0]
+  class CreateCoolWidgetStates < Gitlab::Database::Migration[2.1]
     VERIFICATION_STATE_INDEX_NAME = "index_cool_widget_states_on_verification_state"
     PENDING_VERIFICATION_INDEX_NAME = "index_cool_widget_states_pending_verification"
     FAILED_VERIFICATION_INDEX_NAME = "index_cool_widget_states_failed_verification"
@@ -149,9 +157,17 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
         t.text :verification_failure, limit: 255
 
         t.index :verification_state, name: VERIFICATION_STATE_INDEX_NAME
-        t.index :verified_at, where: "(verification_state = 0)", order: { verified_at: 'ASC NULLS FIRST' }, name: PENDING_VERIFICATION_INDEX_NAME
-        t.index :verification_retry_at, where: "(verification_state = 3)", order: { verification_retry_at: 'ASC NULLS FIRST' }, name: FAILED_VERIFICATION_INDEX_NAME
-        t.index :verification_state, where: "(verification_state = 0 OR verification_state = 3)", name: NEEDS_VERIFICATION_INDEX_NAME
+        t.index :verified_at,
+          where: "(verification_state = 0)",
+          order: { verified_at: 'ASC NULLS FIRST' },
+          name: PENDING_VERIFICATION_INDEX_NAME
+        t.index :verification_retry_at,
+          where: "(verification_state = 3)",
+          order: { verification_retry_at: 'ASC NULLS FIRST' },
+          name: FAILED_VERIFICATION_INDEX_NAME
+        t.index :verification_state,
+          where: "(verification_state = 0 OR verification_state = 3)",
+          name: NEEDS_VERIFICATION_INDEX_NAME
       end
     end
 
@@ -163,17 +179,20 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
 
 - [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
 
-- [ ] Add the new table to the [database dictionary](database_dictionary.md) defined in [`db/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/db/docs):
+- [ ] If `cool_widgets` is a high-traffic table, follow [the database documentation to use `with_lock_retries`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/migration_style_guide.md#when-to-use-the-helper-method)
+
+- [ ] Add the new table to the [database dictionary](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/database/database_dictionary.md) defined in [`db/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/db/docs):
 
   ```yaml
+  ---
   table_name: cool_widget_states
-  description: Description example
-  introduced_by_url: Merge request link
-  milestone: Milestone example
+  description: Separate table for cool widget verification states
+  introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/XXXXX
+  milestone: 'XX.Y'
   feature_categories:
-   - Feature category example
+   - geo_replication
   classes:
-   - Class example
+   - Geo::CoolWidgetState
   gitlab_schema: gitlab_main
   ```
 
@@ -185,20 +204,6 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
 
 - [ ] Be sure to commit the relevant changes in `db/structure.sql` and the file under `db/schema_migrations`
 
-- [ ] Add an entry for the state table in `db/docs/cool_widget_states.yml`
-
-  ```yaml
-  ---
-  table_name: cool_widget_states
-  classes:
-    - Geo::CoolWidgetState
-  feature_categories:
-    - geo_replication
-  description: Separate table for cool widget verification states
-  introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/XXXXX
-  milestone: 'XX.Y'
-  ```
-
 That's all of the required database changes.
 
 ### Implement Geo support of Cool Widgets behind a feature flag
@@ -230,23 +235,30 @@ That's all of the required database changes.
 
     with_replicator Geo::CoolWidgetReplicator
 
-    mount_uploader :file, CoolWidgetUploader
-
     has_one :cool_widget_state, autosave: false, inverse_of: :cool_widget, class_name: 'Geo::CoolWidgetState'
 
     after_save :save_verification_details
 
-    scope :with_verification_state, ->(state) { joins(:cool_widget_state).where(cool_widget_states: { verification_state: verification_state_value(state) }) }
-    scope :checksummed, -> { joins(:cool_widget_state).where.not(cool_widget_states: { verification_checksum: nil } ) }
-    scope :not_checksummed, -> { joins(:cool_widget_state).where(cool_widget_states: { verification_checksum: nil } ) }
-
-    scope :available_verifiables, -> { joins(:cool_widget_state) }
-
     # Override the `all` default if not all records can be replicated. For an
     # example of an existing Model that needs to do this, see
     # `EE::MergeRequestDiff`.
     # scope :available_replicables, -> { all }
 
+    scope :available_verifiables, -> { joins(:cool_widget_state) }
+
+    scope :checksummed, -> {
+      joins(:cool_widget_state).where.not(cool_widget_states: { verification_checksum: nil })
+    }
+
+    scope :not_checksummed, -> {
+      joins(:cool_widget_state).where(cool_widget_states: { verification_checksum: nil })
+    }
+
+    scope :with_verification_state, ->(state) {
+      joins(:cool_widget_state)
+        .where(cool_widget_states: { verification_state: verification_state_value(state) })
+    }
+
     def verification_state_object
       cool_widget_state
     end
@@ -257,7 +269,8 @@ That's all of the required database changes.
       ...
 
       # @param primary_key_in [Range, CoolWidget] arg to pass to primary_key_in scope
-      # @return [ActiveRecord::Relation<CoolWidget>] everything that should be synced to this node, restricted by primary key
+      # @return [ActiveRecord::Relation<CoolWidget>] everything that should be synced
+      #         to this node, restricted by primary key
       def replicables_for_current_secondary(primary_key_in)
         # This issue template does not help you write this method.
         #
@@ -265,7 +278,8 @@ That's all of the required database changes.
         # we want to know which records to replicate. This is not easy to automate
         # because for example:
         #
-        # * The "selective sync" feature allows admins to choose which namespaces #   to replicate, per secondary site. Most Models are scoped to a
+        # * The "selective sync" feature allows admins to choose which namespaces
+        #   to replicate, per secondary site. Most Models are scoped to a
         #   namespace, but the nature of the relationship to a namespace varies
         #   between Models.
         # * The "selective sync" feature allows admins to choose which shards to
@@ -304,8 +318,8 @@ That's all of the required database changes.
 
   ```ruby
     include_examples 'a replicable model with a separate table for verification state' do
-      let(:verifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is included in `available_verifiables`
-      let(:unverifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is NOT included in `available_verifiables`
+      let(:verifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is in `Geo::ReplicableModel.verifiables` scope
+      let(:unverifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is NOT included in `Geo::ReplicableModel.verifiables` scope
     end
   ```
 
@@ -323,10 +337,6 @@ That's all of the required database changes.
         ::CoolWidget
       end
 
-      def repository
-        model_record.repository
-      end
-
       def self.git_access_class
         ::Gitlab::GitAccessCoolWidget
       end
@@ -353,6 +363,10 @@ That's all of the required database changes.
         # (see `RepositoryReplicatorStrategy#before_housekeeping`)
         false
       end
+
+      def repository
+        model_record.repository
+      end
     end
   end
   ```
@@ -402,7 +416,7 @@ That's all of the required database changes.
 
   require 'spec_helper'
 
-  RSpec.describe Geo::CoolWidgetReplicator do
+  RSpec.describe Geo::CoolWidgetReplicator, feature_category: :geo_replication do
     let(:model_record) { build(:cool_widget) }
 
     include_examples 'a repository replicator'
@@ -451,6 +465,7 @@ That's all of the required database changes.
         state { Geo::CoolWidgetRegistry.state_value(:failed) }
         last_synced_at { 1.day.ago }
         retry_count { 2 }
+        retry_at { 2.hours.from_now }
         last_sync_failure { 'Random error' }
       end
 
@@ -476,7 +491,7 @@ That's all of the required database changes.
 
   require 'spec_helper'
 
-  RSpec.describe Geo::CoolWidgetRegistry, :geo, type: :model do
+  RSpec.describe Geo::CoolWidgetRegistry, :geo, type: :model, feature_category: :geo_replication do
     let_it_be(:registry) { create(:geo_cool_widget_registry) }
 
     specify 'factory is valid' do
@@ -491,17 +506,21 @@ That's all of the required database changes.
 - [ ] Add the following to `ee/spec/factories/cool_widgets.rb`:
 
   ```ruby
+  # frozen_string_literal: true
+
   FactoryBot.modify do
-    trait :verification_succeeded do
-        with_file
-        verification_checksum { 'abc' }
-        verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
-    end
+    factory :cool_widget do
+      trait :verification_succeeded do
+          with_file
+          verification_checksum { 'abc' }
+          verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
+      end
 
-    trait :verification_failed do
-        with_file
-        verification_failure { 'Could not calculate the checksum' }
-        verification_state { CoolWidget.verification_state_value(:verification_failed) }
+      trait :verification_failed do
+          with_file
+          verification_failure { 'Could not calculate the checksum' }
+          verification_state { CoolWidget.verification_state_value(:verification_failed) }
+      end
     end
   end
   ```
@@ -549,7 +568,7 @@ That's all of the required database changes.
   end
   ```
 
-- [ ] Add `[:cool_widget, :remote_store]` and `[:geo_cool_widget_state, any]` to `skipped` in `spec/models/factories_spec.rb`
+- [ ] Add `[:geo_cool_widget_state, any]` to `skipped` in `spec/models/factories_spec.rb`
 
 #### Step 2. Implement metrics gathering
 
@@ -573,18 +592,19 @@ Metrics are gathered by `Geo::MetricsUpdateWorker`, persisted in `GeoNodeStatus`
 - [ ] Add the following fields to the `Sidekiq metrics` table in `doc/administration/monitoring/prometheus/gitlab_metrics.md`:
   ```markdown
   | `geo_cool_widgets` | Gauge | XX.Y | Number of Cool Widgets on primary | `url` |
-  | `geo_cool_widgets_checksum_total` | Gauge | XX.Y | Number of Cool Widgets checksummed successfully on primary | `url` |
-  | `geo_cool_widgets_checksummed` | Gauge | XX.Y | Number of Cool Widgets failed to calculate the checksum on primary | `url` |
-  | `geo_cool_widgets_checksum_failed` | Gauge | XX.Y | Number of Cool Widgets tried to checksum on primary | `url` |
+  | `geo_cool_widgets_checksum_total` | Gauge | XX.Y | Number of Cool Widgets to checksum on primary | `url` |
+  | `geo_cool_widgets_checksummed` | Gauge | XX.Y | Number of Cool Widgets that successfully calculated the checksum on primary | `url` |
+  | `geo_cool_widgets_checksum_failed` | Gauge | XX.Y | Number of Cool Widgets that failed to calculate the checksum on primary | `url` |
   | `geo_cool_widgets_synced` | Gauge | XX.Y | Number of syncable Cool Widgets synced on secondary | `url` |
   | `geo_cool_widgets_failed` | Gauge | XX.Y | Number of syncable Cool Widgets failed to sync on secondary | `url` |
   | `geo_cool_widgets_registry` | Gauge | XX.Y | Number of Cool Widgets in the registry | `url` |
-  | `geo_cool_widgets_verification_total` | Gauge | XX.Y | Number of Cool Widgets verified on secondary | `url` |
-  | `geo_cool_widgets_verified` | Gauge | XX.Y | Number of Cool Widgets' verifications failed on secondary | `url` |
-  | `geo_cool_widgets_verification_failed` | Gauge | XX.Y | Number of Cool Widgets' verifications tried on secondary | `url` |
+  | `geo_cool_widgets_verification_total` | Gauge | XX.Y | Number of Cool Widgets to attempt to verify on secondary | `url` |
+  | `geo_cool_widgets_verified` | Gauge | XX.Y | Number of Cool Widgets successfully verified on secondary | `url` |
+  | `geo_cool_widgets_verification_failed` | Gauge | XX.Y | Number of Cool Widgets that failed verification on secondary | `url` |
   ```
+- [ ] Run the rake task `geo:dev:ssf_metrics` and commit the changes to `ee/config/metrics/object_schemas/geo_node_usage.json`
 
-Cool Widget replication and verification metrics should now be available in the API, the `Admin > Geo > Nodes` view, and Prometheus.
+Cool Widget replication and verification metrics should now be available in the API, the `Admin > Geo > Sites` view, and Prometheus.
 
 #### Step 3. Implement the GraphQL API
 
@@ -625,7 +645,7 @@ The GraphQL API is used by `Admin > Geo > Replication Details` views, and is dir
 
   require 'spec_helper'
 
-  RSpec.describe Resolvers::Geo::CoolWidgetRegistriesResolver do
+  RSpec.describe Resolvers::Geo::CoolWidgetRegistriesResolver, feature_category: :geo_replication do
     it_behaves_like 'a Geo registries resolver', :geo_cool_widget_registry
   end
   ```
@@ -649,7 +669,7 @@ The GraphQL API is used by `Admin > Geo > Replication Details` views, and is dir
 
   require 'spec_helper'
 
-  RSpec.describe Geo::CoolWidgetRegistryFinder do
+  RSpec.describe Geo::CoolWidgetRegistryFinder, feature_category: :geo_replication do
     it_behaves_like 'a framework registry finder', :geo_cool_widget_registry
   end
   ```
@@ -683,7 +703,7 @@ The GraphQL API is used by `Admin > Geo > Replication Details` views, and is dir
 
   require 'spec_helper'
 
-  RSpec.describe GitlabSchema.types['CoolWidgetRegistry'] do
+  RSpec.describe GitlabSchema.types['CoolWidgetRegistry'], feature_category: :geo_replication do
     it_behaves_like 'a Geo registry type'
 
     it 'has the expected fields (other than those included in RegistryType)' do
diff --git a/.gitlab/issue_templates/Geo Replicate a new blob type.md b/.gitlab/issue_templates/Geo Replicate a new blob type.md
index 88a7fad4975..fc454919cec 100644
--- a/.gitlab/issue_templates/Geo Replicate a new blob type.md
+++ b/.gitlab/issue_templates/Geo Replicate a new blob type.md
@@ -56,7 +56,7 @@ Geo secondary sites have a [Geo tracking database](https://gitlab.com/gitlab-org
   ```ruby
   # frozen_string_literal: true
 
-  class CreateCoolWidgetRegistry < Gitlab::Database::Migration[2.0]
+  class CreateCoolWidgetRegistry < Gitlab::Database::Migration[2.1]
     def change
       create_table :cool_widget_registry, id: :bigserial, force: :cascade do |t|
         t.bigint :cool_widget_id, null: false
@@ -80,11 +80,19 @@ Geo secondary sites have a [Geo tracking database](https://gitlab.com/gitlab-org
         t.index :retry_at
         t.index :state
         # To optimize performance of CoolWidgetRegistry.verification_failed_batch
-        t.index :verification_retry_at, name: :cool_widget_registry_failed_verification, order: "NULLS FIRST", where: "((state = 2) AND (verification_state = 3))"
+        t.index :verification_retry_at,
+          name: :cool_widget_registry_failed_verification,
+          order: "NULLS FIRST",
+          where: "((state = 2) AND (verification_state = 3))"
         # To optimize performance of CoolWidgetRegistry.needs_verification_count
-        t.index :verification_state, name: :cool_widget_registry_needs_verification, where: "((state = 2) AND (verification_state = ANY (ARRAY[0, 3])))"
+        t.index :verification_state,
+          name: :cool_widget_registry_needs_verification,
+          where: "((state = 2) AND (verification_state = ANY (ARRAY[0, 3])))"
         # To optimize performance of CoolWidgetRegistry.verification_pending_batch
-        t.index :verified_at, name: :cool_widget_registry_pending_verification, order: "NULLS FIRST", where: "((state = 2) AND (verification_state = 0))"
+        t.index :verified_at,
+          name: :cool_widget_registry_pending_verification,
+          order: "NULLS FIRST",
+          where: "((state = 2) AND (verification_state = 0))"
       end
     end
   end
@@ -92,7 +100,7 @@ Geo secondary sites have a [Geo tracking database](https://gitlab.com/gitlab-org
 
 - [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
 
-- [ ] Add the new table to the [database dictionary](database_dictionary.md) defined in [`ee/db/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/db/docs):
+- [ ] Add the new table to the [database dictionary](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/database/database_dictionary.md) defined in [`ee/db/geo/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/db/geo/docs):
 
   ```yaml
   table_name: cool_widget_registry
@@ -131,7 +139,7 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
   ```ruby
   # frozen_string_literal: true
 
-  class CreateCoolWidgetStates < Gitlab::Database::Migration[2.0]
+  class CreateCoolWidgetStates < Gitlab::Database::Migration[2.1]
     VERIFICATION_STATE_INDEX_NAME = "index_cool_widget_states_on_verification_state"
     PENDING_VERIFICATION_INDEX_NAME = "index_cool_widget_states_pending_verification"
     FAILED_VERIFICATION_INDEX_NAME = "index_cool_widget_states_failed_verification"
@@ -144,16 +152,28 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
         t.datetime_with_timezone :verification_started_at
         t.datetime_with_timezone :verification_retry_at
         t.datetime_with_timezone :verified_at
-        t.references :cool_widget, primary_key: true, default: nil, index: false, foreign_key: { on_delete: :cascade }
+        t.references :cool_widget,
+          primary_key: true,
+          default: nil,
+          index: false,
+          foreign_key: { on_delete: :cascade }
         t.integer :verification_state, default: 0, limit: 2, null: false
         t.integer :verification_retry_count, default: 0, limit: 2, null: false
         t.binary :verification_checksum, using: 'verification_checksum::bytea'
         t.text :verification_failure, limit: 255
 
         t.index :verification_state, name: VERIFICATION_STATE_INDEX_NAME
-        t.index :verified_at, where: "(verification_state = 0)", order: { verified_at: 'ASC NULLS FIRST' }, name: PENDING_VERIFICATION_INDEX_NAME
-        t.index :verification_retry_at, where: "(verification_state = 3)", order: { verification_retry_at: 'ASC NULLS FIRST' }, name: FAILED_VERIFICATION_INDEX_NAME
-        t.index :verification_state, where: "(verification_state = 0 OR verification_state = 3)", name: NEEDS_VERIFICATION_INDEX_NAME
+        t.index :verified_at,
+          where: "(verification_state = 0)",
+          order: { verified_at: 'ASC NULLS FIRST' },
+          name: PENDING_VERIFICATION_INDEX_NAME
+        t.index :verification_retry_at,
+          where: "(verification_state = 3)",
+          order: { verification_retry_at: 'ASC NULLS FIRST' },
+          name: FAILED_VERIFICATION_INDEX_NAME
+        t.index :verification_state,
+          where: "(verification_state = 0 OR verification_state = 3)",
+          name: NEEDS_VERIFICATION_INDEX_NAME
       end
     end
 
@@ -165,17 +185,20 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
 
 - [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
 
-- [ ] Add the new table to the database dictionary defined in [`db/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/db/docs):
+- [ ] If `cool_widgets` is a high-traffic table, follow [the database documentation to use `with_lock_retries`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/migration_style_guide.md#when-to-use-the-helper-method)
+
+- [ ] Add the new table to the [database dictionary](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/database/database_dictionary.md) defined in [`db/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/db/docs):
 
   ```yaml
+  ---
   table_name: cool_widget_states
-  description: Description example
-  introduced_by_url: Merge request link
-  milestone: Milestone example
+  description: Separate table for cool widget verification states
+  introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/XXXXX
+  milestone: 'XX.Y'
   feature_categories:
-   - Feature category example
+   - geo_replication
   classes:
-   - Class example
+   - Geo::CoolWidgetState
   gitlab_schema: gitlab_main
   ```
 
@@ -185,24 +208,8 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
   bin/rake db:migrate
   ```
 
-- [ ] If `cool_widgets` is a high-traffic table, follow [the database documentation to use `with_lock_retries`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/migration_style_guide.md#when-to-use-the-helper-method)
-
 - [ ] Be sure to commit the relevant changes in `db/structure.sql` and the file under `db/schema_migrations`
 
-- [ ] Add an entry for the state table in `db/docs/cool_widget_states.yml`
-
-  ```yaml
-  ---
-  table_name: cool_widget_states
-  classes:
-    - Geo::CoolWidgetState
-  feature_categories:
-    - geo_replication
-  description: Separate table for cool widget verification states
-  introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/XXXXX
-  milestone: 'XX.Y'
-  ```
-
 That's all of the required database changes.
 
 ### Implement Geo support of Cool Widgets behind a feature flag
@@ -238,17 +245,26 @@ That's all of the required database changes.
 
     after_save :save_verification_details
 
-    scope :with_verification_state, ->(state) { joins(:cool_widget_state).where(cool_widget_states: { verification_state: verification_state_value(state) }) }
-    scope :checksummed, -> { joins(:cool_widget_state).where.not(cool_widget_states: { verification_checksum: nil } ) }
-    scope :not_checksummed, -> { joins(:cool_widget_state).where(cool_widget_states: { verification_checksum: nil } ) }
-
-    scope :available_verifiables, -> { joins(:cool_widget_state) }
-
     # Override the `all` default if not all records can be replicated. For an
     # example of an existing Model that needs to do this, see
     # `EE::MergeRequestDiff`.
     # scope :available_replicables, -> { all }
 
+    scope :available_verifiables, -> { joins(:cool_widget_state) }
+
+    scope :checksummed, -> {
+      joins(:cool_widget_state).where.not(cool_widget_states: { verification_checksum: nil })
+    }
+
+    scope :not_checksummed, -> {
+      joins(:cool_widget_state).where(cool_widget_states: { verification_checksum: nil })
+    }
+
+    scope :with_verification_state, ->(state) {
+      joins(:cool_widget_state)
+        .where(cool_widget_states: { verification_state: verification_state_value(state) })
+    }
+
     def verification_state_object
       cool_widget_state
     end
@@ -259,7 +275,8 @@ That's all of the required database changes.
       ...
 
       # @param primary_key_in [Range, CoolWidget] arg to pass to primary_key_in scope
-      # @return [ActiveRecord::Relation<CoolWidget>] everything that should be synced to this node, restricted by primary key
+      # @return [ActiveRecord::Relation<CoolWidget>] everything that should be synced
+      #         to this node, restricted by primary key
       def replicables_for_current_secondary(primary_key_in)
         # This issue template does not help you write this method.
         #
@@ -301,8 +318,8 @@ That's all of the required database changes.
 
   ```ruby
     include_examples 'a replicable model with a separate table for verification state' do
-      let(:verifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is included in `available_verifiables`
-      let(:unverifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is NOT included in `available_verifiables`
+      let(:verifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is in `Geo::ReplicableModel.verifiables` scope
+      let(:unverifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is NOT included in `Geo::ReplicableModel.verifiables` scope
     end
   ```
 
@@ -332,7 +349,6 @@ That's all of the required database changes.
         # (see `VerifiableReplicator.verification_enabled?`)
         true
       end
-
     end
   end
   ```
@@ -360,7 +376,7 @@ That's all of the required database changes.
 
   require 'spec_helper'
 
-  RSpec.describe Geo::CoolWidgetReplicator do
+  RSpec.describe Geo::CoolWidgetReplicator, feature_category: :geo_replication do
     let(:model_record) { build(:cool_widget) }
 
     include_examples 'a blob replicator'
@@ -409,6 +425,7 @@ That's all of the required database changes.
         state { Geo::CoolWidgetRegistry.state_value(:failed) }
         last_synced_at { 1.day.ago }
         retry_count { 2 }
+        retry_at { 2.hours.from_now }
         last_sync_failure { 'Random error' }
       end
 
@@ -434,7 +451,7 @@ That's all of the required database changes.
 
   require 'spec_helper'
 
-  RSpec.describe Geo::CoolWidgetRegistry, :geo, type: :model do
+  RSpec.describe Geo::CoolWidgetRegistry, :geo, type: :model, feature_category: :geo_replication do
     let_it_be(:registry) { create(:geo_cool_widget_registry) }
 
     specify 'factory is valid' do
@@ -449,17 +466,21 @@ That's all of the required database changes.
 - [ ] Add the following to `spec/factories/cool_widgets.rb`:
 
   ```ruby
+  # frozen_string_literal: true
+
   FactoryBot.modify do
-    trait :verification_succeeded do
-        with_file
-        verification_checksum { 'abc' }
-        verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
-    end
+    factory :cool_widget do
+      trait :verification_succeeded do
+          with_file
+          verification_checksum { 'abc' }
+          verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
+      end
 
-    trait :verification_failed do
-        with_file
-        verification_failure { 'Could not calculate the checksum' }
-        verification_state { CoolWidget.verification_state_value(:verification_failed) }
+      trait :verification_failed do
+          with_file
+          verification_failure { 'Could not calculate the checksum' }
+          verification_state { CoolWidget.verification_state_value(:verification_failed) }
+      end
     end
   end
   ```
@@ -539,18 +560,19 @@ Metrics are gathered by `Geo::MetricsUpdateWorker`, persisted in `GeoNodeStatus`
 
   ```markdown
   | `geo_cool_widgets` | Gauge | XX.Y | Number of Cool Widgets on primary | `url` |
-  | `geo_cool_widgets_checksum_total` | Gauge | XX.Y | Number of Cool Widgets checksummed successfully on primary | `url` |
-  | `geo_cool_widgets_checksummed` | Gauge | XX.Y | Number of Cool Widgets failed to calculate the checksum on primary | `url` |
-  | `geo_cool_widgets_checksum_failed` | Gauge | XX.Y | Number of Cool Widgets tried to checksum on primary | `url` |
+  | `geo_cool_widgets_checksum_total` | Gauge | XX.Y | Number of Cool Widgets to checksum on primary | `url` |
+  | `geo_cool_widgets_checksummed` | Gauge | XX.Y | Number of Cool Widgets that successfully calculated the checksum on primary | `url` |
+  | `geo_cool_widgets_checksum_failed` | Gauge | XX.Y | Number of Cool Widgets that failed to calculate the checksum on primary | `url` |
   | `geo_cool_widgets_synced` | Gauge | XX.Y | Number of syncable Cool Widgets synced on secondary | `url` |
   | `geo_cool_widgets_failed` | Gauge | XX.Y | Number of syncable Cool Widgets failed to sync on secondary | `url` |
   | `geo_cool_widgets_registry` | Gauge | XX.Y | Number of Cool Widgets in the registry | `url` |
-  | `geo_cool_widgets_verification_total` | Gauge | XX.Y | Number of Cool Widgets verified on secondary | `url` |
-  | `geo_cool_widgets_verified` | Gauge | XX.Y | Number of Cool Widgets' verifications failed on secondary | `url` |
-  | `geo_cool_widgets_verification_failed` | Gauge | XX.Y | Number of Cool Widgets' verifications tried on secondary | `url` |
+  | `geo_cool_widgets_verification_total` | Gauge | XX.Y | Number of Cool Widgets to attempt to verify on secondary | `url` |
+  | `geo_cool_widgets_verified` | Gauge | XX.Y | Number of Cool Widgets successfully verified on secondary | `url` |
+  | `geo_cool_widgets_verification_failed` | Gauge | XX.Y | Number of Cool Widgets that failed verification on secondary | `url` |
   ```
+- [ ] Run the rake task `geo:dev:ssf_metrics` and commit the changes to `ee/config/metrics/object_schemas/geo_node_usage.json`
 
- Cool Widget replication and verification metrics should now be available in the API, the `Admin > Geo > Nodes` view, and Prometheus.
+ Cool Widget replication and verification metrics should now be available in the API, the `Admin > Geo > Sites` view, and Prometheus.
 
 #### Step 3. Implement the GraphQL API
 
@@ -591,7 +613,7 @@ The GraphQL API is used by `Admin > Geo > Replication Details` views, and is dir
 
   require 'spec_helper'
 
-  RSpec.describe Resolvers::Geo::CoolWidgetRegistriesResolver do
+  RSpec.describe Resolvers::Geo::CoolWidgetRegistriesResolver, feature_category: :geo_replication do
     it_behaves_like 'a Geo registries resolver', :geo_cool_widget_registry
   end
   ```
@@ -615,7 +637,7 @@ The GraphQL API is used by `Admin > Geo > Replication Details` views, and is dir
 
   require 'spec_helper'
 
-  RSpec.describe Geo::CoolWidgetRegistryFinder do
+  RSpec.describe Geo::CoolWidgetRegistryFinder, feature_category: :geo_replication do
     it_behaves_like 'a framework registry finder', :geo_cool_widget_registry
   end
   ```
@@ -649,7 +671,7 @@ The GraphQL API is used by `Admin > Geo > Replication Details` views, and is dir
 
   require 'spec_helper'
 
-  RSpec.describe GitlabSchema.types['CoolWidgetRegistry'] do
+  RSpec.describe GitlabSchema.types['CoolWidgetRegistry'], feature_category: :geo_replication do
     it_behaves_like 'a Geo registry type'
 
     it 'has the expected fields (other than those included in RegistryType)' do
diff --git a/.gitlab/issue_templates/Navigation Proposals.md b/.gitlab/issue_templates/Navigation Proposals.md
index 72c8f43cc97..934cf440006 100644
--- a/.gitlab/issue_templates/Navigation Proposals.md
+++ b/.gitlab/issue_templates/Navigation Proposals.md
@@ -4,12 +4,23 @@
 
 <!-- Use this section to explain the proposed changes, including details around usage and business drivers. -->
 
+
+#### Other locations that were considered
+
+ <!-- Include other design patterns or places you considered for this feature besides navigation. -->
+
 ### Checklist
 
+- [ ] Review the handbook page for [navigation changes](https://about.gitlab.com/handbook/product/ux/navigation/#when-to-consider-making-a-change-to-the-navigation)
 - [ ] Add relevant information to the issue description detailing your proposal, including usage and business drivers.
-- [ ] Follow the [product development workflow](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation) validation process to ensure you are solving a well understood problem and that the proposed change is understandable and non-disruptive to users. Navigation-specific research is strongly encouraged.
-- [ ] Engage the [Foundations Product Manager](https://about.gitlab.com/handbook/product/categories/#foundations-group) for approval. The Foundations DRI will work with UX partners in product design, research, and technical writing, as applicable.
-- [ ] Engage the [Foundations](https://about.gitlab.com/handbook/product/categories/#foundations-group) team to ensure your proposal is in alignment with holistic changes happening to the left side bar.
-- [ ] Consider whether you need to communicate the change somehow, or if you will have an interim period in the UI where your nav item will live in more than one place.
+- [ ] List at least two other places you considered to introduce your feature
+- [ ] Add relevant designs to the Design Management area of the issue
+- [ ] Ensure your UI suggestion align with the [Documentation Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/)
+- [ ] Engage ~"Technical Writing". They can help craft a term that best describes the feature(s) you’re proposing. 
+- [ ] Follow the [product development workflow](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation) validation process to ensure you are solving a well understood problem and that the proposed change is understandable and non-disruptive to users. Navigation-specific research is mandatory for additions or when restructuring.
+- [ ] Engage the [Foundations Product Manager](https://about.gitlab.com/handbook/product/categories/#foundations-group) for approval. The Foundations DRI (@cdybenko) will work with UX partners in product design, research, and technical writing, as applicable.
+- [ ] Consider whether you need to [communicate the change somehow](https://design.gitlab.com/patterns/navigation#messaging-changes-to-users), or if you will have an interim period in the UI where your item will live in more than one place.
+- [ ] Ensure engineers are familiar with the [implementation steps for navigation](https://docs.gitlab.com/ee/development/navigation_sidebar.html#navigation-sidebar).
 
-/label ~UX ~"UI text" ~"documentation" ~"documentation" ~"Category:Navigation & Settings" ~"Category:Foundations" ~navigation 
+/label ~UX ~"UI text" ~"documentation" ~"Category:Navigation & Settings"  ~navigation ~type::ignore
+/label ~"Nav request::Start"  
diff --git a/.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md b/.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md
index 7bb602feed2..26dc1c97a99 100644
--- a/.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md
+++ b/.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md
@@ -20,6 +20,7 @@ _NOTE: If the issue has addressed all of these questions, this separate section
 Some relevant technical details, if applicable, such as:
 
 - Does this need a ~"feature flag"?
+- Does there need to be an associated ~"instrumentation" issue created related to this work?
 - Is there an example response showing the data structure that should be returned (new endpoints only)?
 - What permissions should be used?
 - Is this EE or CE?
diff --git a/.gitlab/issue_templates/Security developer workflow.md b/.gitlab/issue_templates/Security developer workflow.md
index 3857303f2c4..294d699ea2f 100644
--- a/.gitlab/issue_templates/Security developer workflow.md
+++ b/.gitlab/issue_templates/Security developer workflow.md
@@ -13,6 +13,7 @@ Set the title to: `Description of the original issue`
 - [ ] Add a `~severity::x` label to the issue and all associated merge requests.
 - [ ] **IMPORTANT**: Mark this [issue as linked] to the Security Release Tracking Issue. You can find it [here](https://gitlab.com/gitlab-org/gitlab/-/issues?sort=created_date&state=opened&label_name[]=upcoming+security+release). This issue
 MUST be linked for the release bot to know that the associated merge requests should be merged for this security release.
+- [ ] Mark this [issue as linked] to the `gitlab-org/gitlab` issue that describes the security vulnerability.
 - Fill out the [Links section](#links):
   - [ ] Next to **Issue on GitLab**, add a link to the `gitlab-org/gitlab` issue that describes the security vulnerability.
 - [ ] If this change affects the public interface (public API or UI) of the product, post in the `#support_gitlab-com` Slack channel  to explain the impact and discuss a mitigation plan for users that might be affected. If you need Support feedback or approval, reach out in `#spt_managers` Slack channel or mention `@gitlab-com/support/managers`.
diff --git a/.gitlab/issue_templates/UX Theme.md b/.gitlab/issue_templates/UX Theme.md
index b015c3d44e6..32e771735b1 100644
--- a/.gitlab/issue_templates/UX Theme.md
+++ b/.gitlab/issue_templates/UX Theme.md
@@ -1,39 +1,25 @@
-<!-- A majority of the work designers do will be on themes in the (Now) Next 1-3 milestone column of their UX Roadmap. These themes are comprised of high-confidence outcomes and validated needs. The UX theme issue is where collaboration should occur, including plans and discussion on subthemes, research, and design feedback. Related issues for design exploration and solution validation should stem from the theme issue. 
+<!-- Most of the work designers do will be on themes in the (Now) Next 1-3 milestone column of their UX Roadmap. These themes are comprised of high-confidence outcomes and validated needs. The UX theme issue is where collaboration should occur, including plans and discussion on subthemes, research, and design feedback. Related design exploration and solution validation issues should stem from the theme issue. 
 
-One of the advantages of working with UX themes is that it allows us to think and design holistically by designing the theme as a whole as opposed to a single issue at a time trying to piece them together as you go. For more details please refer to this section of the handbook when creating UX Themes: https://about.gitlab.com/handbook/product/ux/product-design/ux-roadmaps/#theme-structure -->
+One of the advantages of working with UX themes is that it allows us to think and design holistically by designing the theme as a whole instead of a single issue at a time, trying to piece them together as we go. For more details, please refer to this section of the handbook when creating UX Themes: https://about.gitlab.com/handbook/product/ux/product-design/ux-roadmaps/#ux-theme-structure -->
 
-<!-- Theme Issue Title {UX Theme: <theme statement here>} -->
-<!-- Theme Statement: A theme is written as a statement that combines the beneficiary, their need, and the expected outcome when the work is delivered. Well-defined statements are concise without sacrificing the substance of the theme so that anyone can understand it at a glance. (For instance; Reduce the effort for security teams to identify and escalate business-critical risks) 
-
-!!Note: The theme statement is the defacto title that will be used to reference the theme and serve as the theme issue title.!! It should be something that is easily understood, that quickly communicates the intent of the theme allowing team members to easily understand and recognize the expected work that will be done.
+<!--
+!!Note: The theme statement is the defacto title that will reference the theme and serve as the theme issue title.!! It should be something that is easily understood that quickly communicates the intent of the theme allowing team members to easily understand and recognize the expected work that will be done.
 -->
 
 ----
 
-### Problem to solve
-<!-- In a brief statement, summerize the problem we are intending to address with this theme. For instance, users are unable to complete [task], or, users struggle with the amount of steps required to complete [task] -->
-
+### Theme statement
+<!-- A theme statement combines the beneficiary, their job, and their expected outcome when the work is delivered and serves as the design goal for the team who owns the theme. Well-defined statements are concise without sacrificing the substance of the theme so that anyone can understand it at a glance. Well-defined statements are concise without sacrificing the substance of the theme so that anyone can understand it at a glance. (For instance, Reduce the effort for security teams when prioritizing business-critical risks in their assets.) -->
 
-### Beneficiary 
-<!-- Who is the recipient(s) of the value this theme provides; a customer, end-user, or buyer. Who benefits from this theme being executed? This can be a role, a team, or a persona. For instance: "Development teams, [or] Developers, [or], Sasha the Software Engineer". --> 
+<!-- Also Theme issue tile -->
+{`Need/outcome` } + {`Beneficiary`} + {`Job/Small Job`} 
 
-- **[Direct beneficiary]**
-
-#### Need & Primary JTBD
-<!-- What is the JTBD and what are the needs related to the beneficiary and theme? 
-- JTBD: The JTBD statement, for instance, (When I am triaging vulns, I want to address business-critical risks, So I can ensure there is no unattended risk in my orgs assets.) 
-- Need: Abstracted from the JTBD, for instance, (Identify and escalate business-critical risks detected in my orgs assets.)
---> 
-
-- **JTBD:** 
-- **Need:**   
-
-#### Expected outcome
-<!-- What will the user be able to achieve when this theme is executed? For instance, (Users will be able to effectively triage vulnerabilities at scale across all their orgs assets.) -->
+#### Main Job story
+<!-- What is the [Main Job story](https://about.gitlab.com/handbook/product/ux/jobs-to-be-done/#how-to-write-a-jtbd) that this theme was derived from? (For instance, When I am on triage rotation, I want to address all the business-critical risks in my assets, So I can minimize the likelihood of my organization being compromised by a security breach.) -->
 
 
 #### Business objective
-<!-- What business objective will result from delivering this theme? This answers why we are working on this theme from a business perspective. Examples of objectives are but are not limited to: Sales rate / conversion rate, Success rate / completion rate, Traffic / visitor count, Engagement, or other business-oriented goals. --> 
+<!-- Objectives (from a business point of view) that will be achieved upon completion. (For instance, Increase engagement by making the experience efficient while reducing the chances of users overlooking high-priority items. --> 
 
 
 #### Confidence
@@ -42,43 +28,24 @@ One of the advantages of working with UX themes is that it allows us to think an
 
 | Confidence | Research | 
 | --- | --- | 
-| [High/Medium/Low] | [research/insight issue](Link) |
-
-### User-stories
-<!-- Product designers should work with their PMs to gather up all of the relevant user stories. Look for alignment with the JTBD added above. Overall, the solution you and your team come up with should help to support the user stories. -->
+| [High/Medium/Low] | [research/insight issue](Link) | 
 
-- [user-story here]
-- [user-story here]
-- [user-story here]
-- [etc.]
 
 ### Requirements
-<!-- Requirements can be taken from existing features or design issues that were used to build this theme. Any related issues should be linked with this issue in the Feature/solution issues section below. They are more granular validated needs, goals, and additional details that the theme encompasses. These are typically reserved for themes in the next (1-3 milestones) column. Requirements should answer “what” the beneficiary of this theme needs from the solution.
-
-Note: This is not a backlog. If the issue can not be delivered in the theme timeframe then the theme is too big and needs to be broken down into multiple themes. -->
-
-The beneficieray needs to be able to:
-- [need here]
-- [need here]
-- [need here]
-- [etc.]
+<!-- Requirements can be taken from existing features or design issues used to build this theme. Any related issues should be linked with this issue in the Feature/solution issues section below. They are more granular validated needs, goals, and additional details that the theme encompasses. These are typically reserved for themes in the next (1-3 milestones) column. Requirements should answer “what” the beneficiary of this theme needs from the solution.
 
-#### Feature/solution issues
-<!-- Use this table to track feature issues related to this theme (if applicable). Not all themes require sub-issues as they are typically discovered while working on the theme itself. Think of these issues as if they were the result of breaking down the design into discrete work items. 
+Note: This is not a backlog. If the issue can not be delivered in the theme timeframe, then the theme is too big and needs to be broken down into multiple themes. -->
 
-Note: if feature issues already exist then you can add them to this table. Keep in mind that these issues will require validation if they are being added to a Theme that's in the Next (1-3 milestones) container and are assumptive.
+>⚠️ Related feature and research issues should be linked in the related issues section (Delete this line when this is done)
 
-Refer to https://about.gitlab.com/handbook/product/ux/product-designer/#ux-issue-weights for calculating UX weights.
---> 
-
-| Issue | UX Weight |  
-| ---------- | --------- | 
-| [Issue](link) | `0 - 10` | 
-| [Issue](link) | `0 - 10` | 
-| [Issue](link) | `0 - 10` | 
+#### The beneficiary needs to be able to:
+- [Small job statement]
+  - [Micro job statement]
+  - [Micro job statement]
+- [etc.]
 
 #### Research
-<!-- Use this table to track UX research related to this theme. This may include, problem validation and/or solution validation activities. 
+<!-- Researchers and Designers; Use this table to track UX research related to this theme. This may include problem validation and solution validation activities. 
 --> 
 
 | Issue | Research type | Research status |
@@ -87,16 +54,35 @@ Refer to https://about.gitlab.com/handbook/product/ux/product-designer/#ux-issue
 | [Issue]()  | <!--Solution validation, Problem validation, etc., --> |  <!-- Planned, In Progress, Complete, etc.,-->  |
 
 #### Ready for design checklist
-The items are self-check suggestions; they could be contributed by designers, product managers or researchers
-* [ ] The stated `Problem to solve` has high confidence (derived from research or other data-gathering techniques)
-* [ ] Relevant issues, research, and other background information are linked to the Related issues section
-* [ ] The stated `Beneficiary` has been defined
-* [ ] There is high confidence in the stated `Need & Primary JTBD` (derived from research or other data gathering techniques)
-* [ ] The `Expected outcome` has been defined
+The items are self-check suggestions; they could be contributed by designers, product managers, or researchers
+* [ ] The `theme` has high confidence (derived from research or other data-gathering techniques)
+* [ ] The `Related issues`, features, research, and other background information are linked to the related issues section
 * [ ] The `Business objective` has been defined
-* [ ] The theme `Confidence` has been defined as High
-* [ ] `User-stories` have been defined
-* [ ] The `Requirements` have been defined and the scope has been agreed upon
-* [ ] This UX Theme contains everyhting necessary to complete a design solution and is ready for design
+* [ ] The `Requirements` have been defined, and the scope has been agreed upon
+* [ ] This UX Theme contains everything necessary to complete a design solution and is ready for design
+
+#### [Thematic design workflow checklist](https://about.gitlab.com/handbook/product/ux/product-design/ux-roadmaps/#suggested-workflow)
+<!-- please refer to the [suggested workflow](https://about.gitlab.com/handbook/product/ux/product-design/ux-roadmaps/#suggested-workflow) when working on UX themes-->
+* [ ] **Theme assessed** Ready for design checklist complete
+* [ ] **Ideate and Iterate**
+  * [ ] User flow diagram generated
+  * [ ] Low-fidelity wireframes of the entire theme created
+  * [ ] [Feedback requested](https://about.gitlab.com/handbook/product/ux/product-designer/#design-reviews) and incorporated into flow diagram and wireframes
+* [ ] **Validate**
+  * [ ] [Solution validation](https://about.gitlab.com/handbook/product/ux/ux-research/solution-validation-and-methods/) conducted on Low/mid-fidelity flow 
+* [ ] **Refine**  
+  * [ ] Resaerch findings incorporated into design
+  * [ ] All micro-interactions are defined
+  * [ ] All edge-cases are accounted for and defined
+  * [ ] All copy has been reviewed by tech writing
+  * [ ] Accessibnility guidelines have been considered
+  * [ ] High-fidelity designs posted
+  * [ ] Feedback requested from counterparts
+    * [ ] (If necessary) Validate high-fidelity flow in a 2nd round of user testing
+  * [ ] Refine final design from feedback and user research
+* [ ] **Hand-off**
+  * [ ] Designs broken down based on the their ability to stand alone and that they provide value to the user.
+  * [ ] MVC plan agreement reached 
+  * [ ] Planning breakdown complete
 
 /label ~"UX"  ~"UX Theme"
diff --git a/.gitlab/issue_templates/Utilization group - bug.md b/.gitlab/issue_templates/Utilization group - bug.md
new file mode 100644
index 00000000000..03fed78189e
--- /dev/null
+++ b/.gitlab/issue_templates/Utilization group - bug.md
@@ -0,0 +1,166 @@
+<!---
+Please read this!
+
+Before opening a new issue, make sure to search for keywords in the issues
+filtered by the "regression" or "type::bug" label:
+
+- https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&label_name[]=group%3A%3Autilization&label_name[]=section%3A%3Afulfillment&label_name%5B%5D=type::regression
+- https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&label_name[]=group%3A%3Autilization&label_name[]=section%3A%3Afulfillment&label_name%5B%5D=type::bug
+
+and verify the issue you're about to submit isn't a duplicate.
+--->
+Utilization group: Bug Report Template
+
+## Bug Summary
+
+<!-- Provide a brief overview of the issue. What is the problem that needs to be addressed? -->
+
+## Steps to reproduce
+
+<!-- Provide a clear and detailed description of the steps needed to reproduce the bug. This should include any specific inputs, expected outputs, and observed outputs. -->
+
+1. [Step 1]
+1. [Step 2]
+1. [Step 3]
+1. [Step 4]
+1. [Step 5]
+
+## Example Project
+
+<!-- If possible, please create an example project here on GitLab.com that exhibits the problematic 
+behavior, and link to it here in the bug report. If you are using an older version of GitLab, this 
+will also determine whether the bug is fixed in a more recent version. -->
+
+## What is the current *bug* behavior?
+
+<!-- Describe the current behavior of the system or application in response to the actions described in the steps above. -->
+
+## What is the expected *correct* behavior?
+
+<!-- Describe the expected behavior of the system or application in response to the actions described in the steps above. -->
+
+## Reproducibility
+
+<!-- Describe how frequently the bug occurs. -->
+
+## Impact Assessment
+
+<!-- Describe the impact of this bug on the user experience and/or the product as a whole. -->
+
+## Severity
+
+<!-- Provide an assessment of the severity of the bug, based on its impact on the user experience and/or the product as a whole. -->
+
+## Environment
+
+<!-- List the relevant environment information, including the operating system, web browser, device, etc. -->
+
+## Screenshots and/or Relevant logs
+
+<!-- Include any relevant screenshots to help illustrate the bug. -->
+<!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code
+ as it's tough to read otherwise. -->
+
+## Output of checks (GitLab.com)
+
+<!-- If you are reporting a bug on GitLab.com, uncomment below, if not, delete this section -->
+
+<!-- This bug happens on GitLab.com -->
+<!-- /label ~"reproduced on GitLab.com" -->
+
+## Results of GitLab environment info
+
+<!--  Input any relevant GitLab environment information if needed. -->
+
+<details>
+<summary>Expand for output related to GitLab environment info</summary>
+
+<pre>
+
+(For installations with omnibus-gitlab package run and paste the output of:
+`sudo gitlab-rake gitlab:env:info`)
+
+(For installations from source run and paste the output of:
+`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
+
+</pre>
+</details>
+
+## Results of GitLab application Check
+
+<!--  Input any relevant GitLab application check information if needed. -->
+
+<details>
+<summary>Expand for output related to the GitLab application check</summary>
+<pre>
+
+(For installations with omnibus-gitlab package run and paste the output of:
+`sudo gitlab-rake gitlab:check SANITIZE=true`)
+
+(For installations from source run and paste the output of:
+`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`)
+
+(we will only investigate if the tests are passing)
+
+</pre>
+</details>
+
+## Possible fixes
+
+<!-- If you can, link to the line of code that might be responsible for the problem. -->
+<!-- If you have any suggestions for how to fix the bug, provide them here. -->
+<!-- If you are unsure about the subtype of this bug, please check our SSOT https://about.gitlab.com/handbook/engineering/metrics/?_gl=1*920mnx*_ga*ODQ3OTI1Mjk1LjE2NzA0MDg0NjU.*_ga_ENFH3X7M5Y*MTY4MTM3OTA3My4yNzkuMS4xNjgxMzc5MTI0LjAuMC4w#work-type-classification -->
+
+/label ~"type::bug"
+/label ~"Category:Consumables Cost Management"
+/label ~"group::utilization"
+/label ~"section::fulfillment"
+
+---
+<details>
+<summary>Illustrative Description: (This is not an actual issue, but rather a sample report that demonstrates how a bug could be presented)</summary>
+## Bug Summary
+
+When attempting to log in to GitLab using a new account, the system does not recognize the account and returns an error message.
+
+## Steps to Reproduce
+
+1. Navigate to the GitLab login page.
+1. Enter the email and password for a new account.
+1. Click the "Log In" button.
+1. Observe the error message: "The email or password you entered is incorrect. Please try again."
+
+## What is the current *bug* behavior?
+
+The system does not recognize the new account and returns an error message.
+
+## What is the expected *correct* behavior?
+
+The system should recognize the new account and allow the user to log in.
+
+## Reproducibility
+
+This bug occurs consistently when attempting to log in with a new account.
+
+## Impact Assessment
+
+This bug prevents new users from accessing GitLab and may result in frustration and lost productivity.
+
+## Severity
+
+This bug is of medium severity, as it prevents new users from accessing the system, but does not affect the functionality of existing users.
+
+## Environment
+
+- Operating System: macOS Ventura
+- Browser: Google Chrome 111.0.5563.146
+
+## Screenshots and/or Relevant logs
+
+[Insert screenshot of the error message.]
+
+## Possible Fix
+
+It is unclear what may be causing this bug. Further investigation is required to identify a possible fix.
+
+</details>
diff --git a/.gitlab/issue_templates/Utilization group - feature.md b/.gitlab/issue_templates/Utilization group - feature.md
new file mode 100644
index 00000000000..57a4d4128c0
--- /dev/null
+++ b/.gitlab/issue_templates/Utilization group - feature.md
@@ -0,0 +1,65 @@
+Utilization group: Feature Template
+
+## Description
+
+<!-- As a [user or stakeholder], I want [goal or objective] so that [reason or benefit]. -->
+
+## Acceptance Criteria
+<!-- 
+- [ ] [Describe what must be achieved to complete this issue.]
+- [ ] [Describe another requirement needed to complete this issue.]
+- [ ] [Add additional acceptance criteria as needed.]
+ -->
+## Technical Requirements
+
+<!-- [If applicable, please list out any technical requirements for this feature/enhancement.] -->
+
+## Design Requirements
+
+<!-- [If applicable, please provide a link to the design specifications for this feature/enhancement.] -->
+
+## Impact Assessment
+
+<!-- [Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.] -->
+
+## User Story
+
+<!-- [Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.] -->
+/label ~"type::feature"
+/label ~"Category:Consumables Cost Management"
+/label ~"group::utilization"
+/label ~"section::fulfillment"
+
+<details>
+<summary>Illustrative Description: (This is not an actual issue, but rather a sample report that demonstrates how a feature could be presented) </summary>
+
+## Description
+
+As a developer, I want to be able to easily create and manage merge requests, so that I can collaborate effectively with my team and ensure that code changes are reviewed and merged efficiently.
+
+## Acceptance Criteria
+
+- [ ] The merge request feature should allow developers to create a new merge request from a branch.
+- [ ] The merge request feature should allow developers to assign the merge request to another team member for review.
+- [ ] The merge request feature should provide a clear and easy-to-use interface for managing merge requests.
+- [ ] The merge request feature should integrate with other GitLab features, such as issue tracking and continuous integration.
+
+## Technical Requirements
+
+- The merge request feature should be implemented using GitLab's API.
+- The merge request feature should be integrated with GitLab's existing authentication and authorization system.
+- The merge request feature should be optimized for performance and scalability.
+
+## Design Requirements
+
+- [Design specifications for this feature can be found here.](insert_design_link_here)
+
+## Impact Assessment
+
+This feature will significantly enhance the collaboration and code review process for developers using GitLab. By providing an intuitive and easy-to-use interface for managing merge requests, developers will be able to work more efficiently and effectively as a team. Additionally, integrating the merge request feature with other GitLab features will further streamline the development process.
+
+## User Story
+
+As a developer working on a new feature branch, I want to be able to create a new merge request and assign it to a team member for review, so that I can ensure that my code changes are thoroughly reviewed before being merged into the main codebase. With the new merge request feature, I can easily create a new merge request, assign it to a team member for review, and track its status throughout the review process. This will help me work more efficiently and effectively as a team, while also maintaining high code quality and reliability.
+
+</details>
diff --git a/.gitlab/issue_templates/Utilization group - maintenance.md b/.gitlab/issue_templates/Utilization group - maintenance.md
new file mode 100644
index 00000000000..e25c80e26c7
--- /dev/null
+++ b/.gitlab/issue_templates/Utilization group - maintenance.md
@@ -0,0 +1,69 @@
+Utilization Group: Maintenance Template
+
+## Description
+<!-- Briefly describe the maintenance issue. -->
+
+## Acceptance Criteria
+<!-- 
+- [ ] [Describe the completion requirements.]
+- [ ] [Add additional acceptance criteria as necessary.]
+ -->
+ 
+## Technical Requirements
+<!-- [List any technical requirements for this maintenance issue.] -->
+
+## Impact Assessment
+<!-- [Describe the impact of this maintenance issue on the user experience and/or the product as a whole.] -->
+
+## Steps to Reproduce
+<!-- [Provide detailed steps on how to reproduce the maintenance issue.] -->
+
+## Expected Results
+<!-- [Describe the expected outcome when the maintenance issue is resolved.] -->
+
+## Actual Results
+<!-- [Describe the current outcome of the maintenance issue.] -->
+
+/label ~type::maintenance
+/label ~"Category:Consumables Cost Management"
+/label ~"group::utilization"
+/label ~"section::fulfillment"
+
+<details>
+<summary>Illustrative Description: (This is not an actual maintenance issue, but rather a sample report that demonstrates how a maintenance issue could be presented) </summary>
+
+## Description
+
+The login page is taking longer than expected to load, which is impacting the user experience.
+
+## Acceptance Criteria
+
+- [ ] The login page should load in less than 3 seconds on both desktop and mobile devices.
+- [ ] The login page should be tested on different browsers to ensure compatibility.
+- [ ] The login page should not display any errors or warnings in the console.
+
+## Technical Requirements
+
+- [ ] The login page should be optimized for performance.
+- [ ] The login page should be tested on different browsers.
+- [ ] The login page should be updated to use the latest version of the authentication library.
+
+## Impact Assessment
+
+This maintenance issue is impacting the user experience by causing delays in the login process. By resolving this issue, users will be able to log in faster and have a better overall experience.
+
+## Steps to Reproduce
+
+1. Open the login page.
+1. Wait for the page to load.
+1. Measure the time it takes for the page to fully load.
+
+## Expected Results
+
+The login page should load in less than 3 seconds on both desktop and mobile devices.
+
+## Actual Results
+
+The login page is currently taking more than 5 seconds to load on desktop devices and more than 7 seconds on mobile devices. This is causing frustration and delays for users.
+
+</details>
diff --git a/.gitlab/issue_templates/rca.md b/.gitlab/issue_templates/rca.md
new file mode 100644
index 00000000000..238039bd712
--- /dev/null
+++ b/.gitlab/issue_templates/rca.md
@@ -0,0 +1,125 @@
+**Please note:** if the incident relates to sensitive data or is security-related, consider
+labeling this issue with ~security and mark it confidential, or create it in a private repository. 
+
+There is now a separate internal-only RCA template for SIRT issues referenced https://about.gitlab.com/handbook/security/root-cause-analysis.html
+***
+
+## Summary
+
+A brief summary of what happened. Try to make it as executive-friendly as possible.
+
+- Service(s) affected:
+- Team attribution:
+- Minutes downtime or degradation:
+
+## Impact & Metrics
+
+Start with the following:
+
+| Question | Answer |
+| ----- | ----- |
+| What was the impact? | (i.e. service outage, sub-service brown-out, exposure of sensitive data, ...) |
+| Who was impacted? | (i.e. external customers, internal customers, specific teams, ...) |
+| How did this impact customers? | (i.e. preventing them from doing X, incorrect display of Y, ...) |
+| How many attempts made to access? |  |
+| How many customers affected? |  |
+| How many customers tried to access? |  |
+
+Include any additional metrics that are of relevance.
+
+Provide any relevant graphs that could help understand the impact of the incident and its dynamics.
+
+## Detection & Response
+
+Start with the following:
+
+| Question | Answer |
+| ----- | ----- |
+| When was the incident detected? | YYYY-MM-DD UTC |
+| How was the incident detected? | (i.e. DELKE, H1 Report, ...) |
+| Did alarming work as expected? |  |
+| How long did it take from the start of the incident to its detection? |  |
+| How long did it take from detection to remediation? |  |
+| What steps were taken to remediate? |  |
+| Were there any issues with the response? | (i.e. bastion host used to access the service was not available, relevant team member wasn't page-able, ...) |
+
+## MR Checklist
+
+Consider these questions if a code change introduced the issue.
+
+| Question | Answer |
+| ----- | ----- |
+| Was the [MR acceptance checklist](https://docs.gitlab.com/ee/development/code_review.html#acceptance-checklist) marked as reviewed in the MR? | |
+| Should the checklist be updated to help reduce chances of future recurrences? If so, who is the DRI to do so? | |
+
+## Timeline
+
+YYYY-MM-DD
+
+- 00:00 UTC - something happened
+- 00:01 UTC - something else happened
+- ...
+
+YYYY-MM-DD+1
+
+- 00:00 UTC - and then this happened
+- 00:01 UTC - and more happened
+- ...
+
+
+## Root Cause Analysis
+
+The purpose of this document is to understand the reasons that caused an incident, and to create mechanisms to prevent it from recurring in the future. A root cause can **never be a person**, the way of writing has to refer to the system and the context rather than the specific actors.
+
+Follow the "**5 whys**" in a **blameless** manner as the core of the root cause analysis.
+
+For this, it is necessary to start with the incident and question why it happened. Keep iterating asking "why?" 5 times. While it's not a hard rule that it has to be 5 times, it helps to keep questions get deeper in finding the actual root cause.
+
+Keep in mind that from one "why?" there may come more than one answer, consider following the different branches.
+
+### Example of the usage of "5 whys"
+
+The vehicle will not start. (the problem)
+
+1. Why? - The battery is dead.
+2. Why? - The alternator is not functioning.
+3. Why? - The alternator belt has broken.
+4. Why? - The alternator belt was well beyond its useful service life and not replaced.
+5. Why? - The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)
+
+## What went well
+
+Start with the following:
+
+- Identify the things that worked well or as expected.
+- Any additional call-outs for what went particularly well.
+
+## What can be improved
+
+Start with the following:
+
+- Using the root cause analysis, explain what can be improved to prevent this from happening again.
+- Is there anything that could have been done to improve the detection or time to detection?
+- Is there anything that could have been done to improve the response or time to response?
+- Is there an existing issue that would have either prevented this incident or reduced the impact?
+- Did we have any indication or beforehand knowledge that this incident might take place?
+- Was the [MR acceptance checklist](https://docs.gitlab.com/ee/development/code_review.html#acceptance-checklist) marked as reviewed in the MR?
+- Should the checklist be updated to help reduce chances of future recurrences?
+
+
+
+## Corrective actions
+
+- List issues that have been created as corrective actions from this incident.
+- For each issue, include the following:
+    - `<Bare issue link>` - Issue labeled as ~"corrective action".
+    - An estimated date of completion of the corrective action.
+    - The named individual who owns the delivery of the corrective action.
+
+## Guidelines
+
+- [Blameless RCA Guideline](https://about.gitlab.com/handbook/customer-success/professional-services-engineering/workflows/internal/root-cause-analysis.html)
+- [5 whys](https://en.wikipedia.org/wiki/5_Whys)
+
+/confidential
+/label ~RCA