Add latest changes from gitlab-org/gitlab@master

5 files changed, 10 insertions, 120 deletions

diff --git a/.gitlab/issue_templates/Experiment Implementation.md b/.gitlab/issue_templates/Experiment Implementation.md
index 9f1a012e949..b85271ccdad 100644
--- a/.gitlab/issue_templates/Experiment Implementation.md
+++ b/.gitlab/issue_templates/Experiment Implementation.md
@@ -21,8 +21,7 @@
 
 # Tracking Details
 
-- [json schema](https://gitlab.com/gitlab-org/iglu/-/blob/master/public/schemas/com.gitlab/gitlab_experiment/jsonschema/0-3-0) used in `gitlab-experiment` tracking.
-- see [event schema](../../doc/development/internal_analytics/snowplow/index.md#event-schema) for a guide.
+- [json schema](https://gitlab.com/gitlab-org/iglu/-/blob/master/public/schemas/com.gitlab/gitlab_experiment/jsonschema/1-0-3) used in `gitlab-experiment` tracking.
 
 | sequence | activity | category | action | label | property | value |
 | -------- | -------- | ------ | ----- | ------- | -------- | ----- |
diff --git a/.gitlab/issue_templates/Feature Flag Roll Out.md b/.gitlab/issue_templates/Feature Flag Roll Out.md
index 50dae8c5b2b..7ed9a0b4d47 100644
--- a/.gitlab/issue_templates/Feature Flag Roll Out.md
+++ b/.gitlab/issue_templates/Feature Flag Roll Out.md
@@ -1,36 +1,16 @@
-<!-- Title suggestion: [Feature flag] Enable description of feature -->
-
-<!--
-Set the main issue link: The main issue is the one that describes the problem to solve,
-the one this feature flag is being added for. For example:
-
-[main-issue]: https://gitlab.com/gitlab-org/gitlab/-/issues/123456
--->
+<!-- Title suggestion: [Feature flag] Enable <feature-flag-name> -->
 
 [main-issue]: MAIN-ISSUE-LINK
 
 ## Summary
 
-This issue is to rollout [the feature][main-issue] on production,
+This issue is to roll out [the feature][main-issue] on production,
 that is currently behind the `<feature-flag-name>` feature flag.
 
-<!-- Short description of what the feature is about and link to relevant other issues. -->
-
 ## Owners
 
 - Most appropriate Slack channel to reach out to: `#g_TEAM_NAME`
-- Best individual to reach out to: NAME_OF_DRI
-- PM: NAME_OF_PM
-
-## Stakeholders
-
-<!--
-Are there any other stages or teams involved that need to be kept in the loop?
-
-- Name of a PM
-- The Support Team
-- The Delivery Team
--->
+- Best individual to reach out to: GITLAB_USERNAME_OF_DRI
 
 ## Expectations
 
@@ -38,30 +18,11 @@ Are there any other stages or teams involved that need to be kept in the loop?
 
 <!-- Describe the expected outcome when rolling out this feature -->
 
-### When is the feature viable?
-
-<!-- What are the settings we need to configure in order to have this feature viable? -->
-
-<!--
-Example below:
+### What can go wrong and how would we detect it?
 
-1. Enable service ping collection
-   `ApplicationSetting.first.update(usage_ping_enabled: true)`
--->
-
-### What might happen if this goes wrong?
-
-<!-- Should the feature flag be turned off? Any MRs that need to be rolled back? Communication that needs to happen? What are some things you can think of that could go wrong - data loss or broken pages? -->
-
-### What can we monitor to detect problems with this?
+<!-- Data loss, broken pages, stability/availability impact? -->
 
 <!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
-_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?
-
-_Consider adding links to check for Sentry errors, Production logs for 5xx, 302s, etc._
 
 ## Rollout Steps
 
@@ -85,7 +46,7 @@ For assistance with end-to-end test failures, please reach out via the [`#qualit
 ### Specific rollout on production
 
 For visibility, all `/chatops` commands that target production should be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796)
-and cross-posted (with the command results) to the responsible team's Slack channel (`#g_TEAM_NAME`).
+and cross-posted (with the command results) to the responsible team's Slack channel.
 
 - Ensure that the feature MRs have been deployed to both production and canary with `/chatops run auto_deploy status <merge-commit-of-your-feature>`
 - [ ] Depending on the [type of actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors) you are using, pick one of these options:
@@ -138,7 +99,7 @@ To do so, follow these steps:
 
 - [ ] Create a merge request with the following changes. Ask for review and merge it.
     - [ ] Set the `default_enabled` attribute in [the feature flag definition](https://docs.gitlab.com/ee/development/feature_flags/#feature-flag-definition-and-validation) to `true`.
-    - [ ] Review [what warrants a changelog entry](https://docs.gitlab.com/ee/development/changelog.html#what-warrants-a-changelog-entry) and decide if [a changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog) is needed.
+    - [ ] Decide [which changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog) is needed.
 - [ ] Ensure that the default-enabling MR has been included in the release package.
       If the merge request was deployed before [the monthly release was tagged](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
       the feature can be officially announced in a release blog post: `/chatops run release check <merge-request-url> <milestone>`
@@ -182,27 +143,6 @@ You can either [create a follow-up issue for Feature Flag Cleanup](https://gitla
 /chatops run feature set <feature-flag-name> false
 ```
 
-<!-- A feature flag can also be used for rolling out a bug fix or a maintenance work.
-In this scenario, labels must be related to it, for example; ~"type::feature", ~"type::bug" or ~"type::maintenance".
-Please use /copy_metadata to copy the labels from the issue you're rolling out. -->
-
-<!--
-Template placeholders
-
-- name: MAIN-ISSUE-LINK
-  description: the URL of the issue introducing the feature flag
-- name: <feature-flag-name>
-  description: the feature flag name
-- name: #g_TEAM_NAME
-  description: the Slack channel name of the responsible team, e.g. #g_foo
-- name: NAME_OF_DRI
-  description: the GitLab username of the best individual to reach out to, e.g. @foo
-- name: NAME_OF_PM
-  description: the GitLab username of the relevant PM, e.g. @foo
-- name: <your-username>
-  description: the GitLab username of the person who would enable the feature flag on GitLab.com, e.g. @foo
--->
-
 /label ~group::
 /label ~"feature flag"
 /assign me
diff --git a/.gitlab/issue_templates/Feature Proposal - lean.md b/.gitlab/issue_templates/Feature Proposal - lean.md
index c82907a2401..102c79aafd1 100644
--- a/.gitlab/issue_templates/Feature Proposal - lean.md
+++ b/.gitlab/issue_templates/Feature Proposal - lean.md
@@ -43,7 +43,7 @@ Personas are described at https://about.gitlab.com/handbook/product/personas/
 
 <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it?
 
-Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md
+Explore (../../doc/development/internal_analytics/internal_event_instrumentation/quick_start.md) for a guide.
 
 -->
 
diff --git a/.gitlab/issue_templates/Feature proposal - detailed.md b/.gitlab/issue_templates/Feature proposal - detailed.md
index b3398509684..3d0a78f7f96 100644
--- a/.gitlab/issue_templates/Feature proposal - detailed.md
+++ b/.gitlab/issue_templates/Feature proposal - detailed.md
@@ -98,9 +98,6 @@ Test Planning: https://about.gitlab.com/handbook/engineering/quality/quality-eng
 ### Feature Usage Metrics
 
 <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it?
-
-Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md
-
 -->
 
 ### What does success look like, and how can we measure that?
@@ -108,7 +105,7 @@ Create tracking issue using the Snowplow event tracking template. See https://gi
 <!--
 Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this.
 
-Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md
+Explore (../../doc/development/internal_analytics/internal_event_instrumentation/quick_start.md) for a guide.
 -->
 
 ### What is the type of buyer?
diff --git a/.gitlab/issue_templates/Snowplow event tracking.md b/.gitlab/issue_templates/Snowplow event tracking.md
deleted file mode 100644
index 3dfef73f973..00000000000
--- a/.gitlab/issue_templates/Snowplow event tracking.md
+++ /dev/null
@@ -1,46 +0,0 @@
-<!--
-* Use this issue template for creating requests to track snowplow events
-* Snowplow events can be both Frontend (javascript) or Backend (Ruby)
-* Snowplow is currently not used for self-hosted instances of GitLab - Self-hosted still rely on usage ping for product analytics - Snowplow is used for GitLab SaaS
-* You do not need to create an issue to track generic front-end events, such as All page views, sessions, link clicks, some button clicks, etc.
-* What you should capture are specific events with defined business logic. For example, when a user creates an incident by escalating an existing alert, or when a user creates and pushes up a new Node package to the NPM registry.
-* For more details read https://about.gitlab.com/handbook/business-technology/data-team/programs/data-for-product-managers/
- -->
-
-<!--
-We generally recommend events be tracked using a [structured event](https://docs.snowplowanalytics.com/docs/understanding-tracking-design/out-of-the-box-vs-custom-events-and-entities/#structured-events) which has 5 properties you can use. There may be instances where structured events are not sufficient. You may want to track an event where the property changes frequently or is general something very unique. In those cases, use a [self-describing event](https://docs.snowplowanalytics.com/docs/understanding-tracking-design/out-of-the-box-vs-custom-events-and-entities/#self-describing-events)
-
--->
-
-## Structured Snowplow events to track
-
-* Category: The page or backend area of the application. Unless infeasible, please use the Rails page attribute by default in the frontend, and namespace + classname on the backend. If you're not sure what it is, work with your engineering manager to figure it out.
-* Action: A string that is used to define the user action. The first word should always describe the action or aspect: clicks should be `click`, activations should be `activate`, creations should be `create`, etc. Use underscores to describe what was acted on; for example, activating a form field would be `activate_form_input`. An interface action like clicking on a dropdown would be `click_dropdown`, while a behavior like creating a project record from the backend would be `create_project`
-* Label: Optional. The specific element, or object that's being acted on. This is either the label of the element (e.g. a tab labeled 'Create from template' may be `create_from_template`) or a unique identifier if no text is available (e.g. closing the Groups dropdown in the top navbar might be `groups_dropdown_close`), or it could be the name or title attribute of a record being created.
-* Property: Optional. Any additional property of the element, or object being acted on.
-* Value: Optional, numeric. Describes a numeric value (decimal) directly related to the event. This could be the value of an input (e.g. `10` when clicking `internal` visibility)
-
-| Category | Action | Label | Property | Feature Issue | Additional Information |
-| ------ | ------ | ------ | ------ | ------ | ------ |
-| cell | cell | cell | cell | cell | cell |
-| cell | cell | cell | cell | cell | cell |
-
-<!--
-  Snowplow event tracking starts with instrumentation and completed after a chart is created in Sisense.
-
-  Use this checklist to ensure all steps are completed
--->
-
-## Snowplow event tracking checklist
-* [ ] Engineering complete work and deploy changes to GitLab SaaS
-* [ ] Verify the new Snowplow events are listed in the [Snowplow Event Exploration](https://app.periscopedata.com/app/gitlab/539181/Snowplow-Event-Exploration---last-30-days) dashboard
-* [ ] Create chart(s) to track your event(s) in the relevant dashboard
-  * [ ] Use the [Chart Snowplow Actions](https://app.periscopedata.com/app/gitlab/snippet/Chart-Snowplow-Actions/5546da87ae2c4a3fbc98415c88b3eedd/edit) SQL snippet to quickly visualize usage. See [example](https://app.periscopedata.com/app/gitlab/737489/Health-Group-Dashboard?widget=9797112&udv=0)
-
-<!-- Label reminders - you should have one of each of the following labels.
-Use the following resources to find the appropriate labels:
-- https://gitlab.com/gitlab-org/gitlab/-/labels
-- https://about.gitlab.com/handbook/product/categories/features/
--->
-/label ~devops:: ~group: ~Category:
-/label ~"snowplow tracking events"