As the name implies, the purpose of the template is to detail underperforming queries for further investigation.
### Steps
- [ ] Rename the issue to - `Query Performance Investigation - [Query Snippet | Table info]`
- For example - `Query Performance Investigation - SELECT "namespaces".* FROM "namespaces" WHERE "namespaces"."id" = $1 LIMIT $2`
- [ ] Provide information in the Requested Data Points table
-[ ] Provide [priority and severity labels](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#availability)
- [ ] If this requires immediate attention cc `@gitlab-org/database-team` and reach out in the #g_database slack channel
### SQL Statement
```sql
```
### Data from Elastic
Instructions on collecting data from [PostgreSQL slow logs stored in Elasticsearch](https://gitlab.com/gitlab-com/runbooks/-/merge_requests/3361/diffs)
### Requested Data points
Please provide as many of these fields as possible when submitting a query performance report.
- Queries per second (on average or peak)
- Number of calls per second and relative to total number of calls
- Query timings (on average or peak)
- Database time relative to total database time
- Source of calls (Sidekiq, WebAPI, etc)
- Query ID
- Query Plan
- Query Example
- Total number of calls (relative)
- % of Total time
<!--
- Example of a postgres checkup report - https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/snippets/2056787
- Select statements that are in execution during database CPU utilization peak times - licenses table (#292900) - https://gitlab.com/gitlab-org/gitlab/-/issues/292900
<!-- If you already have an implementation plan, please fill in detail below https://about.gitlab.com/handbook/engineering/development/ops/release/planning/#weights -->
/weight X
/label ~"backend-weight::" ~"frontend-weight::" ~"workflow::ready for development"
## Implementation guide
<!-- If the issue clear enough, consider inviting community contributors -->
/label ~"Seeking community contributions" ~"good for new contributors"
<!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." -->
## Proposal
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
<!-- Default labels -->
/label ~"group::release"
/label ~"type::feature"
/label ~"workflow::problem validation"
/label ~UX
<!-- Optional labels -->
/label ~backend ~frontend
<!-- If you already have an implementation plan, please fill in detail below https://about.gitlab.com/handbook/engineering/development/ops/release/planning/#weights -->
/weight X
/label ~"backend-weight::" ~"frontend-weight::" ~"workflow::ready for development"
## Implementation guide
<!-- If the issue clear enough, consider inviting community contributors -->
/label ~"Seeking community contributions" ~"good for new contributors"
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
<!-- Set labels and other metadata -->
/label ~"group::release"
/label ~"type::maintenance"
/label ~"workflow::planning breakdown"
<!-- If you already have an implementation plan, please fill in detail below https://about.gitlab.com/handbook/engineering/development/ops/release/planning/#weights -->
/weight X
/label ~"backend-weight::" ~"frontend-weight::" ~"workflow::ready for development"
## Implementation guide
<!-- If the issue clear enough, consider inviting community contributors -->
/label ~"Seeking community contributions" ~"good for new contributors"
As a [user or stakeholder], I want [goal or objective] so that [reason or benefit].
[Provide any additional description here.]
## Acceptance Criteria
TODO: Fill out (required)
- [ ] [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
TODO: Fill out or delete (optional)
[If applicable, please list out any technical requirements for this feature/enhancement.]
## Design Requirements
TODO: Fill out or delete (optional)
[If applicable, please provide a link to the design specifications for this feature/enhancement.]
## Impact Assessment
TODO: Fill out or delete (optional)
[Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.]
## User Story
TODO: Fill out or delete (optional)
[Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.]
/label ~"Category:Remote Development"
/label ~"section::dev"
/label ~"devops::create"
/label ~"group::ide"
<!-- Replace with other type, e.g. bug or maintenance, if appropriate -->
/label ~"type::feature"
<!-- Replace with other subtype if appropriate -->
/label ~"feature::addition"
<!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process -->
/label ~"rd-workflow::unprioritized"
<!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->
1. Replace all occurrences of X.Y to the release that is targeted as an upgrade stop.
2. Give the issue a title: "X.Y upgrade stop planning"
3. Replace the <deadlinedate> with the ISO date 10 days before the [release date](https://about.gitlab.com/releases/)(this is always two Fridays before).
-->
This planning issue collects a list of changes that require an upgrade stop to X.Y.
## Notes for all engineering managers
To help to determine whether %"X.Y" is a required stop,
add your issue to the list below before `<deadline date>` (your local time).
You can review the [Common scenarios that require stops](https://docs.gitlab.com/ee/development/database/required_stops.html) and
[avoiding required stops](https://docs.gitlab.com/ee/development/avoiding_required_stops.html) to
confirm. If you are still not sure after reviewing the documentation, leave a
comment with the link to your issue or epic in this issue for others to review.
If your change requires an upgrade stop and cannot wait until %"X.Y", please
reach out to `@dorrino` and `@plu8`.
### List of changes that require an upgrade stop for version X.Y
-<epicorissuelink>
## Notes for the issue author only
### After the issue creation
Slack message template:
>>>
The Distribution::Deploy group created an issue (link to this issue) to
determine if X.Y needs to be [a required upgrade
stop](https://docs.gitlab.com/ee/development/avoiding_required_stops.html#causes-of-required-stops). Please review your
upcoming changes and share any may require upgrade stop on the issue (link to
this issue), thank you.
>>>
- [ ] Update "Next Required Stop" bookmark in `#g_distribution` to this issue link.
-[ ] I have read the [Sec Architectural Council](https://about.gitlab.com/handbook/engineering/development/sec/#architectural-council-slack-s_sec-architectural-council) handbook entry.
-[ ] I have read the [Engineering Architecture](https://about.gitlab.com/handbook/engineering/architecture) page.
-[ ] A DRI has already been assigned in the [Reviewed by](#reviewed-by) section of this issue based the above guidance.
## Table of Contents
-[Proposal](#proposal)
-[Scope](#scope)
-[Out of scope](#out-of-scope)
-[In scope](#in-scope)
-[Reviewed by](#reviewed-by)
-[SLO](#slo)
## Proposal
<!--
Review the proposal process here: https://about.gitlab.com/handbook/engineering/development/sec/#architectural-council-slack-s_sec-architectural-council
TL;DR you want to ask and discuss the following to arrive at a proposed solution:
1. What is the issue at hand and what is the preferred action?
2. What are the potential solutions and their associated pros/cons?
Use the checkboxes below to determine whether your is in scope for the Sec Architectural Council.
#### Out of scope
If any of the following apply then this issue is out of scope for the Sec Architectural Council.
- [ ] Does not involve architectural decisions
- [ ] Is after-the-fact
#### In scope
If any of the following apply then a proposal *should* be made:
- [ ] Has a broad impact within Sec
If any of the following apply then you may opt-in to submitting a proposal to the Sec Architectural Council:
- [ ] Is not already covered by architecture guidelines/handbook
- [ ] Is a new unit of work
- [ ] Is strictly Secure
- [ ] Involves architectural decisions
Once opted-in in some cases you may find that you:
- [ ] Could not come to an agreement (escalation)
In which case you may opt-out closing this proposal if there is no broad impact within of Sec. If doing so please close the issue with a comment summarizing of your decision given you will follow standard architecture guidelines.
## Reviewed by
Assigned DRI: `@dri`
I am asking The following Sec Architectural Council [Team Representatives][] to review the proposal outline in this issue:
-[ ] @alan representing the [Security Policies](https://about.gitlab.com/handbook/engineering/development/sec/govern/security-policies/) team
-[ ] @cam_swords representing the [Dynamic Analysis](https://about.gitlab.com/handbook/engineering/development/sec/secure/dynamic-analysis/) team
-[ ] @fcatteau or @adamcohen representing the [Composition Analysis](https://about.gitlab.com/handbook/engineering/development/sec/secure/composition-analysis/) team
-[ ] @idawson representing the [Vulnerability Research](secure/vulnerability-research/) team
-[ ] @julianthome representing the [Vulnerability Research](secure/vulnerability-research/) team
-[ ] @minac representing the [Threat Insights Backend](https://about.gitlab.com/handbook/engineering/development/sec/govern/threat-insights/) team
-[ ] @svedova representing the [Threat Insights Frontend](https://about.gitlab.com/handbook/engineering/development/sec/govern/threat-insights/) team
-[ ] @theoretick representing the [Static Analysis](https://about.gitlab.com/handbook/engineering/development/sec/secure/static-analysis/) team
-[ ] @sashi_kumar representing the [Security Policies](https://about.gitlab.com/handbook/engineering/development/sec/govern/security-policies) team
-[ ] @huzaifaiftikhar1 representing the [Compliance](https://about.gitlab.com/handbook/engineering/development/sec/govern/compliance) team
<!-- Please update the following quick action in case of changes to the representatives list above. -->
While the Sec Architectural Council has a Service Level Objective of 2-business days our Team Representatives are spread out globally so it may take longer than 48 hours in some cases for all parties to review your proposal.
Please update this issue's Due Date accordingly when you:
* Create a proposal after Wednesday 17:00 Australian Eastern Time/Japan Time.
* Create a proposal over the weekend (e.g. before Monday 09:00 Mountain Time/Pacific Time).
---
[Proposal](#proposal)|[Scope](#scope)|[Out of scope](#out-of-scope)|[In scope](#in-scope)|[Reviewed by](#reviewed-by)|[SLO](#slo)
Create this issue under https://gitlab.com/gitlab-org/security/gitlab
Set the title to: `Description of the original issue`
-->
## Prior to starting the security work
- [ ] Read the [security process for engineers] if you are not familiar with it.
- [ ] Make sure the [issue really needs to follow the security workflow].
- [ ] Add a `~severity::x` label to the issue and all associated merge requests.
- [ ] 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`.
## Development
- [ ] Run `scripts/security-harness` in your local repository to prevent accidentally pushing to any remote besides `gitlab.com/gitlab-org/security`.
- [ ] Create a new branch prefixing it with `security-`.
- [ ] Create a merge request targeting `master` on `gitlab.com/gitlab-org/security` and use the [Security merge request template].
-[ ] If this includes a breaking change, make sure to include a mention of it for the relevant versions in [`doc/update/index.md`](https://gitlab.com/gitlab-org/security/gitlab/-/blob/master/doc/update/index.md#version-specific-upgrading-instructions)
- See if the [breaking changes workflow] applies
After your merge request has been approved according to our [approval guidelines] and by a team member of the AppSec team, you're ready to prepare the backports
## Backports
- [ ] Once the MR is ready to be merged, create MRs targeting the latest 3 stable branches.
- The 3 stable branches correspond to the versions in the title of the [Security Tracking Issue].
- At this point, it might be easy to squash the commits from the MR into one
- You can use the script `bin/secpick` instead of the following steps, to help you cherry-picking. See the [secpick documentation]
- [ ] Create each MR targeting the stable branch `X-Y-stable`, using the [Security merge request template].
- Every merge request will have its own set of to-dos, so make sure to complete those.
- [ ] On the "Related merge requests" section, ensure that `4` merge requests are associated: The one targeting `master` and the `3` backports.
- [ ] If this issue requires less than `4` merge requests, add the ~"reduced backports" label.
## Assigning to a release
- [ ] **IMPORTANT**: When this issue is ready for release (Default branch MR and backports are approved and ready to be merged), apply the ~"security-target" label.
- The `gitlab-release-tools-bot` evaluates and links issues with the label to the active [Security Tracking Issue]. If the bot finds the issue is not ready to be included in the patch release, it will leave a comment on the issue explaining what needs to be done.
- This issue will only be included in a patch release if it is successfully linked to the [Security Tracking Issue].
## Documentation and final details
- [ ] To avoid release delays, please nominate a developer in a different timezone who will be able to respond to any pipeline or merge failures in your absence `@gitlab-username`
- [ ] Ensure `~severity::x` label is on this issue, all associated issues, and merge requests
-[ ] Ensure the [Links section](#links) is completed.
-[ ] Add the GitLab [versions](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/engineer.md#versions-affected) and editions affected to the [details section](#details)
- The Git history of the files affected may help you associate the issue with a [release](https://about.gitlab.com/releases/)
-[ ] Fill in any upgrade notes that users may need to take into account in the [details section](#details)
-[ ] Add Yes/No and further details if needed to the migration and settings columns in the [details section](#details)
-[ ] Add the nickname of the external user who found the issue (and/or HackerOne profile) to the Thanks row in the [details section](#details)
[issue as linked]:https://docs.gitlab.com/ee/user/project/issues/related_issues.html#add-a-linked-issue
[issue really needs to follow the security workflow]:https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/engineer.md#making-sure-the-issue-needs-to-follow-the-security-release-workflow
<!-- This issue template is used by https://about.gitlab.com/handbook/engineering/development/analytics-section/analytics-instrumentation/ for tracking effort around Service Ping reporting for GitLab.com -->
The [Analytics Instrumentation group](https://about.gitlab.com/handbook/engineering/development/analytics/analytics-instrumentation/) runs manual reporting of ServicePing for GitLab.com on a weekly basis. This issue:
- Captures the work required to complete the reporting process,.
- Captures the follow-up tasks that are focused on metrics performance verification.
- Identifies any potential issues.
# New metrics to be verified
<!-- Add new metrics that must be verified -->
# Failed metrics
Broken metrics issues are marked with the ~"broken metric" label.
# Use a detached screen session to generate Service Ping for GitLab.com
## Prerequisites
1. Add your SSH key to the local SSH agent: `ssh-add`. Your SSH key is required to connect to a Rails console from the bastion host.
## Triggering
1. Add the SSH key to the local SSH agent: `ssh-add`.
1. Connect to the bastion with SSH agent forwarding: `ssh -A lb-bastion.gprd.gitlab.com`.
1. Note which bastion host machine was assigned. For example: `<username>@bastion-01-inf-gprd.c.gitlab-production.internal:~$` shows that you are connected to `bastion-01-inf-gprd.c.gitlab-production.internal`.
1. Create a named screen: `screen -S $USER-service-ping-$(date +%F)`.
1. Connect to the console host: `ssh $USER-rails@console-01-sv-gprd.c.gitlab-production.internal`.
1. Press <kbd>Control</kbd>+<kbd>a</kbd> followed by <kbd>Control</kbd>+<kbd>d</kbd> to detach from the screen session.
1. Exit from the bastion: `exit`.
## Verification (After approximately 30 hours)
1. Reconnect to the bastion: `ssh -A lb-bastion.gprd.gitlab.com`. Make sure that you are connected to the same host machine that ServicePing was started on. For example, to connect directly to the host machine, use `ssh bastion-01-inf-gprd.c.gitlab-production.internal`.
1. Find your screen session: `screen -ls`.
1. Attach to your screen session: `screen -x 14226.mwawrzyniak_service_ping_2021_01_22`.
1. Check the last payload in the `raw_usage_data` table: `RawUsageData.last.payload`.
1. Check the when the payload was sent: `RawUsageData.last.sent_at`.
## Stop the Service Ping process
Use either of these processes:
1. Reconnect to the bastion host machine. For example, use: `ssh bastion-01-inf-gprd.c.gitlab-production.internal`.
1. Find your screen session: `$ screen -ls`.
1. Attach to your screen session: `$ sudo -u <username> screen -r`.
1. Press <kbd>Control</kbd>+<kbd>c</kbd> to stop the Service Ping process.
OR
1. Reconnect to the bastion host machine. For example, type: `ssh bastion-01-inf-gprd.c.gitlab-production.internal`.
1. List all process started by your username: `ps faux | grep <username>`.
1. Locate the username that owns ServicePing reporting.
1. Send the kill signal for the ServicePing PID: `kill -9 <service_ping_pid>`.
## Service Ping process triggering (through a long-running SSH session)
1. Connect to the `gprd` Rails console.
1. Run `GitlabServicePingWorker.new.perform('triggered_from_cron' => false)`. This process requires more than 30 hours to complete.
1. Find the last payload in the `raw_usage_data` table: `RawUsageData.last.payload`.
1. Check the when the payload was sent: `RawUsageData.last.sent_at`.
<!-- Title suggestion: <async-index-name> synchronous database index(es) addition/removal -->
## Summary
This issue is to add a migration(s) to create/destroy the `<async-index-name>` database index(es) synchronously after it has been created/destroyed on GitLab.com.
The asynchronous index(es) was introduced in <!-- Link to MR that introduced the asynchronous index -->.
<!-- Instructions: Use this template for a proof of concept or when a deeper technical evaluation is required. Please weigh tech evaluation issues and follow the instructions below accordingly. -->
### Topic to Evaluate
<!-- Describe the related issue and challenge we need to establish a proof of concept for-->
*[Link to other Issue](link)
### Tasks prior to evaluation
<!-- Pre-evaluation tasks are critical and should be completed or confirmed by product managers if available -->
- [ ] Clearly document the topic to evaluated in this issue description
- [ ] Determine specific scope including time-bounds for investigation
### Tasks to Evaluate
<!-- Outline the tasks with issues that you need to evaluate as a part of the implementation issue -->
- [ ] Determine feasibility of the feature
- [ ] Create issue for implementation or update existing implementation issue description with implementation proposal
- [ ] Set weight on implementation issue
- [ ] If weight is greater than 5, break issue into smaller issues
- [ ] Add task
- [ ] Add task
### Risks and Implementation Considerations
<!-- Identify any risks found in the research, whether this is performance, impacts to other functionality or other bugs -->
### Team
- [ ] Add ~"workflow::planning breakdown" ~"type::feature" and the corresponding `~devops::<stage>` and `~group::<group>` labels.
<!-- 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 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 -->
<!--
!!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.
-->
----
### 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.) -->
<!-- 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
<!-- 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
<!-- 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 -->
<!-- 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.
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. -->
>⚠️ Related feature and research issues should be linked in the related issues section (Delete this line when this is done)
#### The beneficiary needs to be able to:
- [Small job statement]
- [Micro job statement]
- [Micro job statement]
- [etc.]
#### Research
<!-- 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 |
| ---------- | --------- | --------- |
| [Issue]() | <!--Solution validation, Problem validation, etc., --> | <!-- Planned, In Progress, Complete, etc.,--> |
| [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 `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 `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
<!-- 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.
<!-- Guide for product managers or engineering teams looking to track usage of their features -->
:warning: If GDK is accessible, an alternative to using this guide is to directly establish event/metric definitions using our [internal events generator](https://docs.gitlab.com/ee/development/internal_analytics/internal_event_instrumentation/quick_start.html#defining-event-and-metrics)
## Objective
<!-- The primary goal or purpose behind instrumenting this feature or project. What insights are we aiming to gather?
Examples:
Feature adoption and engagement
- How many unique users/projects/namespaces engage with the feature?
- Frequency with which users return to specific features over time?
User Flow and Navigation
- Sequences of actions users take within the product or feature
- Specific user actions or behaviors tracked as events -->
## Events and Metrics
[Definition of events and metrics](https://docs.gitlab.com/ee/development/internal_analytics/#fundamental-concepts) | [Sample metrics](https://metrics.gitlab.com/) | [Sample events](https://metrics.gitlab.com/snowplow)
**Expand to view examples and guidelines for filling the table**
</summary>
Events:
***Description:** Include what the event is supposed to track, where and when.
***Name:** Primary identifier of the event, format: \<**action**\>\_\<**target_of_action**\>\_\<**where/when**\>
***Example event name:** click_save_button_in_issue_description_within_15s_of_page_load (**action** = click ; **target** = save button; **where** = in issue description ; **when** = within 15s
***Additional properties: Besides user/project/namespace, what other details should be tracked, if any? ex) status, type, object id, etc.
***Feature:** What feature is being instrumented? Please use the feature title that is used in features.yml if thats already available.
Metrics:
***Description:** What quantitative measurements derived from either event data or database columns would you like to track? eg: Weekly count of unique users who update an issue
***Event/DB column:** What event or database column should the metric count or be based on.
***Total or unique count:** Should the metric count all occurrences or only unique counts, e.g. of `user_id` to get a count of unique users triggering an event.
***Time Frame:** What time frames should be tracked. Default and recommended is 7d and 28d.
</details>
## Next steps
* [ ] Assign an engineering counterpart from your group to add instrumentation to the code
*[ ] Explore instrumented data with the help of our [data discovery guide](https://docs.gitlab.com/ee/development/internal_analytics/#data-discovery). You can also [reach out to product data insights team](https://gitlab.com/gitlab-data/product-analytics/-/issues/new?issuable_template=PI%20Chart%20Help) for help with generating Tableau reports/dashboards.
* [ ] Your feedback is valuable to us. Please leave us feedback in the comment section of this issue and tag @tjayaramaraju or @basti
# Important links
:star: [Quick start guide to internal events](https://docs.gitlab.com/ee/development/internal_analytics/internal_event_instrumentation/quick_start.html)
:question: [Analytics Instrumentation slack channel for questions](https://gitlab.enterprise.slack.com/archives/CL3A7GFPF)
:writing_hand: Try our [internal events generator](https://docs.gitlab.com/ee/development/internal_analytics/internal_event_instrumentation/quick_start.html#defining-event-and-metrics). Creating event and metric definition files has never been easier.
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:
(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.
<!-- 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.
