GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2020-07-15T12:23:25Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/225954Add Process and Program Management Persona2020-07-15T12:23:25ZDoug BishopAdd Process and Program Management Persona### Problem to solve
1) All the personas available assume the entire Organization is utilizing GitLab and utilize the same methodology for doing work. While that is more efficient and tends to be the case in smaller companies, Larger com...### Problem to solve
1) All the personas available assume the entire Organization is utilizing GitLab and utilize the same methodology for doing work. While that is more efficient and tends to be the case in smaller companies, Larger companies who are trying to shift their culture have growing pains that need to be addressed. Having capabilities in GitLab to address this persona will enable faster culture change by making the transition easier.
2) A persona to represent Companies that acquire Products (or other Companies) is needed to keep things separated for a while while a clear migration path is established. This migration could be 6 months, a year and sometimes longer. Having capabilities in GitLab to address this persona will enable easier tracking and management of a hybrid organization.
### Proposal
Doug is a Process Manager / Program Manager with a more traditional Program / Project Manager (not a Release Manager) perspective in a hybrid organization. He serves as a bridge between Executive Level Wants, Needs and Directions and the Team Level people doing work in a Self-organized fashion. His job is to:
* Communicate, Coordinate, Facilitate and to Enable his Team(s) to succeed.
* Establish clear Process on interactions between those in GitLab and those working in a more traditional environment.
* Evangelize Culture Shift towards DevOps and Git by including steps for DevOps / Git training into Process wherever feasible.
Frustrations:
* Its difficult to navigate between two different styles of business methodology. Many parts of the org are not in GitLab - forcing a mixed methodology from a Project Management perspective as well as a need for clear process on how others engage the Teams.
* Its difficult to produce meaningful reporting and status - Everyone wants to see the same data but they want to see it in different ways and from different levels
* Its difficult to establish priority around big picture efforts when no one can easily see how those items relate at a higher level. 30 Initiatives all in-flight creates the need to see Initiate Rollup / Summaries
* Its difficult to use a tool that requires coding knowledge when not a coder
* Its difficult to perform traditional Program Management in a tool not set up for Program Management
* Its difficult to create Process Flows (diagrams) in a tool not well-set for easy creation / visualization of Flow Maps (if you can't flow it out how can you automate it?)
### Who can address the issue
Marketing maintains a Handbook of Roles-Personas
https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/https://gitlab.com/gitlab-org/gitlab/-/issues/12805Default swim lanes in issue boards + Copy from existing2021-11-08T16:15:11ZVirjinia Alexievavalexieva@gitlab.comDefault swim lanes in issue boards + Copy from existing### Problem to solve
<!-- What problem do we solve? -->
Every time a user creates a board now, they need to select the swim lanes they would like to add. This leads to inefficiencies when a user has created a board that they already lik...### Problem to solve
<!-- What problem do we solve? -->
Every time a user creates a board now, they need to select the swim lanes they would like to add. This leads to inefficiencies when a user has created a board that they already like and has to recreate the same thing for each milestone. We currently have the option to automatically add `To do` & `Doing ` swim lanes, but this seems somehow misplaced as only shows once the board is created.
![Screen_Shot_2019-07-12_at_12.26.52_PM](/uploads/250b339ee5992e3257464d210d964346/Screen_Shot_2019-07-12_at_12.26.52_PM.png)
### Intended users
<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
PMs
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
Add the ability for a user to start a board with default swim lanes:
- Add another heading just under the board name box, saying `Swimlanes` and have 2 buttons:
- One, which is pressed by default called `Default` and another one called `Copy Existing/New`. That button can give us existing boards as a dropdown and the ability to create an empty one similar to the below.
![Screen_Shot_2019-07-12_at_12.37.55_PM](/uploads/b05029d115acc353ec3248fc07f613aa/Screen_Shot_2019-07-12_at_12.37.55_PM.png)
![Screen_Shot_2019-07-12_at_12.54.20_PM](/uploads/1a5efd79c1148d82192010371ee12784/Screen_Shot_2019-07-12_at_12.54.20_PM.png)
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? -->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### Testing
<!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ -->
### What does success look like, and how can we measure that?
<!-- 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. -->
### What is the type of buyer?
<!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
### Links / referencesBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/10736Links to review apps break when the environment is redeployed2023-03-10T03:22:52ZNathan Friendhello@nathanfriend.ioLinks to review apps break when the environment is redeployed### Problem to solve
This is a situation I've encountered a few times:
1. A developer creates an MR, and a review app for the MR is automatically created
3. The developer jumps into the review app, creates some test data, and shares a ...### Problem to solve
This is a situation I've encountered a few times:
1. A developer creates an MR, and a review app for the MR is automatically created
3. The developer jumps into the review app, creates some test data, and shares a link to a specific page within the review app with a UX designer for approval
4. A few hours later, the developer adds some tests, which causes the review app the redeploy with a new URL
5. The UX designer follows the original link that was shared by the developer, but the link is now outdated and broken
### Intended users
<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
Anyone who uses review apps, which includes just about every persona!
### Further details
I often avoid pushing new changes to an MR after I share a link to an environment to avoid breaking the environment before the reviewer. It would be nice to not have to think about this!
### Proposal
Provide a way to keep review app URLs consistent between deployments so that links can be safely shared.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/27266Warning that you are commenting on closed issue2022-05-19T16:11:54ZJason YavorskaWarning that you are commenting on closed issue### Problem to solve
We recently made the "moved" state more visible, but people are still commenting on closed issues in various scenarios.
### Target audience
<!--- For whom are we doing this? Include a [persona](https://about.gitla...### Problem to solve
We recently made the "moved" state more visible, but people are still commenting on closed issues in various scenarios.
### Target audience
<!--- For whom are we doing this? Include a [persona](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/)
listed below, if applicable, along with its [label](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=persona%3A),
or define a specific company role, e.g. "Release Manager".
Existing personas are: (copy relevant personas out of this comment, and delete any persona that does not apply)
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
- Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
- Devon, DevOps Engineer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#devon-devops-engineer
- Sidney, Systems Administrator, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sidney-systems-administrator
- Sam, Security Analyst, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sam-security-analyst
-->
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
We should show a warning in/around the comment box to a user that they are commenting on a closed issue. They may still want to do it for some reason, but this would prevent accidental conversations in the wrong/undiscoverable place.
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? -->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### What does success look like, and how can we measure that?
<!-- 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. -->
### Links / references
cc @victorwuBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/27243Commit message line/character count2019-11-05T18:31:53ZLuke BennettCommit message line/character count### Problem to solve
Wondering if your commit message meets repo requirements.
I love to use GitLab UI to make changes to a repo when I can. It's always quick, clean and integrated.
The most consistent negative moment when doing this ...### Problem to solve
Wondering if your commit message meets repo requirements.
I love to use GitLab UI to make changes to a repo when I can. It's always quick, clean and integrated.
The most consistent negative moment when doing this is when I am writing a commit message to a repo that I know has commit requirements (like gitlab-ce/ee) and I have no idea how long my intended commit message is.
![Screenshot_2019-03-11_at_14.13.05](/uploads/bf618b350f458784505d261c6a5f0bb4/Screenshot_2019-03-11_at_14.13.05.png)
![Screenshot_2019-03-11_at_14.13.12](/uploads/260a6917b135b11c33e2698ac2a33b4e/Screenshot_2019-03-11_at_14.13.12.png)
### Target audience
Everyone can contribute :shrug:
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
- Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
- Devon, DevOps Engineer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#devon-devops-engineer
- Sidney, Systems Administrator, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sidney-systems-administrator
- Sam, Security Analyst, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sam-security-analyst
-->
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
When I am working on desktop, IDEs will have a `line:character` count. It would be great to see this in the GitLab commit message boxes.
![Screenshot_2019-03-11_at_14.16.54](/uploads/37b207cee454c38b5f13795821a85f67/Screenshot_2019-03-11_at_14.16.54.png)
In the bottom right you can see the cursor is on line 1, character 73. I will now know that this could be improved and will rethink it.
Addtionaly, something to consider for the future but not in the scope of this issue, the text changes color after 50 characters to indicate that I am over the recommended limit.
### Permissions and Security
### Documentation
### What does success look like, and how can we measure that?
Add a `line:character` count component to commit message textareas.
I'm thinking we probably don't need to add it anywhere except web IDE because I assume web IDE will replace single file edit at some point?
### Links / referenceshttps://gitlab.com/gitlab-org/gitlab/-/issues/10298Error Budget MVC2023-12-18T05:28:34ZJoshua LambertError Budget MVC### Problem to solve
Organizations need a way to balance stability and velocity. A common way to try to achieve this, is to utilize Error Budgets. These allow organizations to set an agreed upon toleration for errors, and track any outa...### Problem to solve
Organizations need a way to balance stability and velocity. A common way to try to achieve this, is to utilize Error Budgets. These allow organizations to set an agreed upon toleration for errors, and track any outages against it. This way they understand if they are over or undershooting on stability.
GitLab should provide tools to help establish and track an error budget.
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
The simplest form of tracking an error budget is to simply track the time of an outage. This is fairly naive, as it doesn't account for severity, but this could be added later as a multiple of sorts. This allows us to still track error rates when we may not be able to know or track the error rate over the set of requests.
To track the incident duration, we can utilize the beginnings of our incident management feature set. We are now able to automatically open issues from alerts, and we can build on this to also track the duration by logging when an alert has cleared.
To achieve this we should:
* Comment in the issue when an alert has cleared.
* Calculate the time the issue was open, and utilize time tracking to store the value.
While we aren't doing any global reporting right now, you can retrieve this field via the API and also export via CSV (https://docs.gitlab.com/ee/user/project/issues/csv_export.html). This can allow for manual reports to be built while we build larger reporting capabilities.
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? -->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### Target audience
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
- Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
- Devon, DevOps Engineer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#devon-devops-engineer
- Sidney, Systems Administrator, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sidney-systems-administrator
### What does success look like, and how can we measure that?
<!-- 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. -->
### What is the type of buyer?
<!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
### Links / references
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->Next 4-6 releaseshttps://gitlab.com/gitlab-org/gitlab/-/issues/10260Single list for epics and issues2023-01-30T15:18:00ZFabio BusattoSingle list for epics and issues### Problem to solve
We use both epics and issues to store valuable information that we want to find in the future. When searching, we use labels to find what's of our interest.
That's great, and epics and issues lists are places where...### Problem to solve
We use both epics and issues to store valuable information that we want to find in the future. When searching, we use labels to find what's of our interest.
That's great, and epics and issues lists are places where I go very often.
With group level support for lists, I don't have to look at multiple issues lists anymore.
I still have to check issues and epics independently, and this is suboptimal. When I know that I wrote information somewhere, and I want to find it, I still need to go to multiple lists (epics and group issues).
It would be awesome to have both in one single list, or to easily jump from the group issue list to the epics list for the same group, keeping search criteria and labels.
### Target audience
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
### Proposal
Create a unified experience for searching in both epics and issues for a specific group.
It could be a new way to show the list view, or an easy way to switch from epics to issues, keeping the same search filters.
Maybe the MVC is to share search history between the two lists in the same group, so we can easily set them again.
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? -->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### What does success look like, and how can we measure that?
<!-- 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. -->
### What is the type of buyer?
<!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
### Links / referencesBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/27177Add route-map.yml to Pages project templates2023-03-21T20:36:21ZMark PundsackAdd route-map.yml to Pages project templates### Problem to solve
Route maps are awesome, but non-obvious.
### Target audience
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, Development T...### Problem to solve
Route maps are awesome, but non-obvious.
### Target audience
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
- Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
For most static site generators, there are usually some common formats for mapping source code to output. We should create `route-map.yml` files for these, and include them in the project templates.
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? -->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### What does success look like, and how can we measure that?
<!-- 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. -->
### Links / referencesBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/27155Improve workflow for discussions in issues2022-05-19T16:13:11ZFabio BusattoImprove workflow for discussions in issues### Problem to solve
As Product Managers, we are daily dealing with issues that are being worked by engineers in the current cycle.
It may happen that we have to focus on something most important and we are not able to immediately answe...### Problem to solve
As Product Managers, we are daily dealing with issues that are being worked by engineers in the current cycle.
It may happen that we have to focus on something most important and we are not able to immediately answer all the mentions immediately. This creates a backlog of mentions that we need to prioritize.
This may be critical when we're close to the feature freeze, where a hard deadline can determine if an entire feature will be shipped or not.
Before having discussions in issues, the flow I used was:
1. go to the issue
1. find my last comment (assuming it addressed all the mentions before that
1. read through the comments added after my last one
1. check if there is something I need to take care
1. add a new comment
Now this is not possible anymore, because the top-down order is not the chronological order anymore. New comments can be in discussions at the very beginning of the issue. This forces me to go through all the list of comments again, to check for discussions that have new mentions.
This process is suboptimal and takes more than it was before.
There is a workaround for that. Use email notifications, that are reflecting the chronological order, to get the list of messages that need my attention. Anyway, this is prone to error, and still very time consuming and inefficient.
How can we improve this process and make our answers quicker and more effective in the very critical days around feature freeze?
I
### Target audience
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
### Further details
In merge requests, we have very useful features like:
1. resolve a discussion
1. jump to unresolved discussion
These are not perfect, but still helping a lot in discussion management.
### Proposal
Implement features to help discussion management for quick and effective answers.
Possible exaples:
1. resolve a discussion
1. jump to next unresolved discussion
1. jump to next unresolved discussion where I was mentioned
1. jump to next unresolved discussion I opened
1. unthread discussions and sort all comments by chronological order (like email clients do)
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? -->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### What does success look like, and how can we measure that?
<!-- 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. -->
### Links / referencesBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/27123Unify all GitLab tokens into a single implementation2023-10-16T20:54:32ZJoshua LambertUnify all GitLab tokens into a single implementation### Problem to solve
Currently GitLab utilizes a wide variety of tokens:
* Personal Access Tokens
* Deploy Tokens
* CI Job Tokens
* Group Access Tokens
* Project Access Tokens
* OAuth tokens
These tokens are all handled slightly differ...### Problem to solve
Currently GitLab utilizes a wide variety of tokens:
* Personal Access Tokens
* Deploy Tokens
* CI Job Tokens
* Group Access Tokens
* Project Access Tokens
* OAuth tokens
These tokens are all handled slightly different, with different permissions, scopes, authentication methods, and more. Further, they are all stored in their own separate tables, which means that there can be collisions between tokens of different types.
### Target audience
<!--- For whom are we doing this? Include a [persona](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/)
listed below, if applicable, along with its [label](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=persona%3A),
or define a specific company role, e.g. "Release Manager".
Existing personas are: (copy relevant personas out of this comment, and delete any persona that does not apply)
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
- Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
- Devon, DevOps Engineer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#devon-devops-engineer
- Sidney, Systems Administrator, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sidney-systems-administrator
- Sam, Security Analyst, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sam-security-analyst
-->
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
We should try to standardize on a single token type, and simply extend the scopes and rights system so that it supports all of the existing tokens we have today. This would significantly simplify the authentication architecture within GitLab, allow us to focus on improving a single token, and ultimately go faster.
Further, if we standardized on an OAuth token for these token types, we could improve our support for NPM: https://gitlab.com/gitlab-org/gitlab-ee/issues/9140#note_133520809
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? -->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### What does success look like, and how can we measure that?
<!-- 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. -->
### Links / referencesBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/10158Collect telemetry and metrics directly in GitLab2023-09-05T21:58:30ZBrendan O'Leary 🐢Collect telemetry and metrics directly in GitLab### Problem to solve
When releasing a new application or a new feature to an exisiting application it can be valuable to collect metrics and usage statistics (typically referred to collectively as 'telemetry' data) about the usage of tha...### Problem to solve
When releasing a new application or a new feature to an exisiting application it can be valuable to collect metrics and usage statistics (typically referred to collectively as 'telemetry' data) about the usage of that feature.
### Target audience
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
### Further details
Use cases include things like:
* GitLab is adding a new feature called `suggestions` that allows users to suggest changes to a line of code in a Merge Request. How many people use this feature in the first 30 days after release?
* How much is the usage of a stage growing over time? (e.g. [SMAU](https://about.gitlab.com/handbook/finance/operating-metrics/#smau))
* Collecting metrics on a feature to make UX decisions
* A/B testing the method of displaying a feature to a user
* Deciding to deprecate support for a set of features
This directly contributes to our ~"Product Vision 2019" and our plan to ~"rebuild in GitLab" those items required for a complete DevOps lifecycle management tool in a single application.
### Proposal
There are a number of ways we could implement this, I don't think I have an opinion currently...there was a detailed (internal) discussion here: https://gitlab.slack.com/archives/C0NFPSFA8/p1551463148058200.
* Integrate into APM / ~Monitor some concept of generic metrics either time based or otherwise.
* Extend the ~Release feature around Feature Flags to send data back about the usage of a given flag
* Have ~Fulfillment build first-class telemetry directly into GitLab as part of their plans around [usage ping](https://docs.gitlab.com/ee/user/admin_area/settings/usage_statistics.html#usage-ping-core-only)
* Some combination of all of the above or using a generic library for telemetry such as [Microsoft Application Inights](https://github.com/Microsoft/ApplicationInsights-Ruby)
### Permissions and Security
I think it makes sense that Maintainers and above would have access to this data, thought I could see an argument for large spred of data.
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### What does success look like, and how can we measure that?
<!-- 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. -->
### What is the type of buyer?
<!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
### Links / references
/cc @jeremy @tipyn @joshlambert @jlenny @markpundsack @ebrinkman @kencjohnston
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->Awaiting further demandhttps://gitlab.com/gitlab-org/gitlab/-/issues/27092Gamify GitLab by adding a 👍 count to the user profile page2024-03-18T14:36:20ZNathan Friendhello@nathanfriend.ioGamify GitLab by adding a 👍 count to the user profile page### Problem to solve
Gamify GitLab.
### Target audience
Really, anybody:
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, Development Team Lead...### Problem to solve
Gamify GitLab.
### Target audience
Really, anybody:
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
- Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
- Devon, DevOps Engineer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#devon-devops-engineer
- Sidney, Systems Administrator, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sidney-systems-administrator
- Sam, Security Analyst, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sam-security-analyst
### Further details
Sites like [Stack Overflow](https://stackoverflow.com/) have had great success with gamifying participation through a "reputation score", which is earned when users provide value to the site.
This idea originated from a comment made by @jlenny: https://gitlab.com/gitlab-org/gitlab-ce/issues/57781#note_141778770.
### Proposal
Implement a simple reputation system using the number of :thumbsup: emojis the user has collected. The :thumbsup: count would appear on the user's profile. The count could also be shown in the popover that appears when a username is hovered over (i.e. @nfriend).
As @jlenny mentioned in https://gitlab.com/gitlab-org/gitlab-ce/issues/57781#note_141778770, we could implement some rules to make this count more meaningful, i.e. only count :thumbsup: on closed issues that the user participated in.
A future usage of this :thumbsup: count might be a site-wide leaderboard.
We could also consider counting other emojis, like :tada:, :thumbsdown:, :100:, :smile:, etc.
### What does success look like, and how can we measure that?
Are people having fun?
### Links / referencesBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/27083Mark task as irrelevant in issues2022-05-19T16:13:10ZPhilippe LafoucrièreMark task as irrelevant in issues### Problem to solve
Add the ability to mark a task as irrelevant quickly.
### Target audience
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, ...### Problem to solve
Add the ability to mark a task as irrelevant quickly.
### Target audience
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
- Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
- Devon, DevOps Engineer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#devon-devops-engineer
- Sidney, Systems Administrator, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sidney-systems-administrator
- Sam, Security Analyst, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sam-security-analyst
### Further details
In our MR template, we have a lot of task as a checklist. Many of them don't apply all the time, and many people are leaving the task open because they're nothing to mark as done. I generally strike through these tasks to make sure the reviewer understands what's really left to do. There's no other than editing the description of the MR, and add `~~` around these tasks, which is tedious. When it's tedious, people don't do it.
### Proposal
Next to each task, on hover, we could have a new icon to strikethrough the whole line in one click.
Note that having another button in the toolbar would not be as efficient, as it would require to select the lines, go click on the button, and start again with the next line.
### Permissions and Security
The user must be authorized to update the description of the issue/MR.
### Documentation
Update https://docs.gitlab.com/ee/user/markdown.html#task-lists
### What does success look like, and how can we measure that?
We see more MRs with strikethrough tasks, instead of undone tasks.
### Links / references
/cc @victorwuBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/27019Add instructions for setting up review apps with new project templates2021-07-19T23:08:16ZJason YavorskaAdd instructions for setting up review apps with new project templates### Problem to solve
We have several new project templates, and most of them it makes sense to have review apps. We can't really set it up automatically as part of the template, though, because it requires having infrastructure setup. W...### Problem to solve
We have several new project templates, and most of them it makes sense to have review apps. We can't really set it up automatically as part of the template, though, because it requires having infrastructure setup. What we can do is add documentation to each of the projects to make it clear how to take advantage of this awesome feature that is a big differentiator between GitLab and other CD solutions.
In situations where AutoDevOps is possible, that should be the preferred solution.
### Target audience
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
- Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
- Devon, DevOps Engineer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#devon-devops-engineer
### Further details
As mentioned, review apps are strategic and also one of our coolest features. If this can help drive adoption of usage of review apps, that's a huge win because it will help teams get the most out of using GitLab CD.
### Proposal
The list of project templates can be found in https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/project_template.rb, which contains rows that look something like:
`ProjectTemplate.new('rails', 'Ruby on Rails', _('Includes an MVC structure, Gemfile, Rakefile, along with many others, to help you get started.'), 'https://gitlab.com/gitlab-org/project-templates/rails', 'illustrations/logos/rails.svg'),`
What needs to be done to update each of them is to go to the URL (in this example, https://gitlab.com/gitlab-org/project-templates/rails) and update the README with the new content. Then, the project must be exported, vendored (as per https://gitlab.com/gitlab-org/gitlab-ce/issues/46043), and then added back to this project in `/vendor/project_templates`.
If you find a way to make this export/vendor/re-add process more automated, that's a nice bit of technical debt that can be fixed at the same time.
### Permissions and Security
There are no additional security or permissions considerations in play here; this should follow all existing permissions around creating new projects and setting up review apps. It should be clear in the READMEs what the permissions are, so people without access to the appropriate configuration (for example, to set up the review app infrastructure) don't get confused.
### Documentation
This is in a sense a documentation task, and we should be careful here to avoid _duplicating_ documentation. The section about setting up review apps should discuss anything specific to the project, but should point to existing documentation links in order to actually offer guidance. The primary goal here is driving awareness that review apps are an option, and that it's easy, not providing in-template comprehensive documentation.
### What does success look like, and how can we measure that?
+adoption of review apps
### Links / referencesBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/27016Ability to select a default issue or merge request template from `.gitlab/*te...2023-06-17T00:09:22ZAntony Sabaasaba@gitlab.comAbility to select a default issue or merge request template from `.gitlab/*templates`### Problem to solve
Currently, the default templates are not version controlled in the repository along with the other templates available in `.gitlab/*templates`. If those directories are properly populated, one of them should be abl...### Problem to solve
Currently, the default templates are not version controlled in the repository along with the other templates available in `.gitlab/*templates`. If those directories are properly populated, one of them should be able to be chosen as the default template instead of using the text box in the project settings.
### Target audience
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
- Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
- Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
### Further details
Currently only Maintainers and Owners can change the default templates in the project settings, even though developers and others (for public projects) can contribute changes all other templates through the usual development and MR processes.
A project could manage a default template and follow manual steps to copy and paste into the
### Proposal
If there are templates available, provide a way to choose one instead of using the text field.
Another option may be to specify a specific named path that will be used by default if present, such as `.gitlab/issue_templates/default.md` and `.gitlab/merge_request_details.md`.
### Documentation
The documentation for [setting default templates will need to be updated for the new controls](https://docs.gitlab.com/ee/user/project/description_templates.html#setting-a-default-template-for-issues-and-merge-requests--starter
### What does success look like, and how can we measure that?
We will see updates to the default templates submitted as merge requests, with more team members contributing to them.
### Links / referenceshttps://gitlab.com/gitlab-org/gitlab/-/issues/26999Set headers for notification emails for issues/MRs a user opened2023-10-26T17:39:05ZBalasankar 'Balu' CSet headers for notification emails for issues/MRs a user opened### Problem to solve
A way to differentiate notification emails if they are from an issue/MR I opened, so I can create an email filter for them.
### Target audience
Well, I think this is useful for all GitLab users. So I am gonna leav...### Problem to solve
A way to differentiate notification emails if they are from an issue/MR I opened, so I can create an email filter for them.
### Target audience
Well, I think this is useful for all GitLab users. So I am gonna leave all Personas here.
- Parker, Product Manager, https://design.gitlab.com/research/personas#persona-parker
- Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
- Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha
- Devon, DevOps Engineer, https://design.gitlab.com/research/personas#persona-devon
- Sidney, Systems Administrator, https://design.gitlab.com/research/personas#persona-sidney
- Sam, Security Analyst, https://design.gitlab.com/research/personas#persona-sam
-->
### Proposal
We are setting some headers for emails already. So, if we are sending a notification email from an issue/MR to a user, let us check if that user is the author of that issue/MR, and add a differentiating header if that is the case.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/10004Add "Add Group" button to operational dashboard2023-09-05T21:58:31ZJason YavorskaAdd "Add Group" button to operational dashboard### Problem to solve
You can add a project to the ops dashboard, but not a group. It would be nicer if you could add a group at once, and any projects added/removed are automatically reflected.
![image](/uploads/5ce29a7018216ee69184456...### Problem to solve
You can add a project to the ops dashboard, but not a group. It would be nicer if you could add a group at once, and any projects added/removed are automatically reflected.
![image](/uploads/5ce29a7018216ee69184456e1648625f/image.png)
### Target audience
<!--- For whom are we doing this? Include a [persona](https://design.gitlab.com/research/personas)
listed below, if applicable, along with its [label](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=persona%3A),
or define a specific company role, e.g. "Release Manager".
Existing personas are: (copy relevant personas out of this comment, and delete any persona that does not apply)
- Parker, Product Manager, https://design.gitlab.com/research/personas#persona-parker
- Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
- Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha
- Devon, DevOps Engineer, https://design.gitlab.com/research/personas#persona-devon
- Sidney, Systems Administrator, https://design.gitlab.com/research/personas#persona-sidney
- Sam, Security Analyst, https://design.gitlab.com/research/personas#persona-sam
-->
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### What does success look like, and how can we measure that?
<!-- 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. -->
### What is the type of buyer?
(Which leads to: in which enterprise tier should this feature go
see https://about.gitlab.com/handbook/product/pricing/#four-tiers )
### Links / references
cc @joshlambertAwaiting further demandhttps://gitlab.com/gitlab-org/gitlab/-/issues/9993Artifact release meta-data2022-02-16T14:55:13ZJoshua LambertArtifact release meta-data### Problem to solve
A release often incorporates multiple underlying packages and services. These could be composed of upstream pipelines, which are publishing a particular package, library, or container. They could also be composed of...### Problem to solve
A release often incorporates multiple underlying packages and services. These could be composed of upstream pipelines, which are publishing a particular package, library, or container. They could also be composed of other public dependencies, like: a base image, published packages, official container, a helm chart, etc.
When a final release is being evaluated, we should be able to present users with a few key data points:
1. What underlying packages/containers the release incorporates and depends on
1. The changelogs of each underlying dependency, if they are changing
1. The security scan results of those dependencies
1. The license compliance of those dependencies
This is important for a few reasons:
1. To present a comprehensive Bill of Materials (BOM), which includes underlying components
1. To assist reviewers of the final release to understand the impact across security, compliance, risk
### Target audience
- Parker, Product Manager, https://design.gitlab.com/research/personas#persona-parker
- Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
- Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha
- Devon, DevOps Engineer, https://design.gitlab.com/research/personas#persona-devon
### Further details
<!--- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
When a release is generated for a package or container, we should attach metadata to that release:
* The changelog to document what has changed
* The security posture (quantity of high/medium/low, etc.)
* The license compliance and type (e.g. Apache 2.0 but includes license violations)
* Any underlying dependencies that are included, and links to their metadata
This way when that artifact is consumed by a downstream project, the provenance and state is clear.
---
Then for a given release, we could show a view of what is contained within as well as generate a portion of the changelog. This is important for customers who may be doing frequent releases with upstream projects, to understand 'what is in this release`?
### What does success look like, and how can we measure that?
<!--- 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 -->
### What is the type of buyer?
(Which leads to: in which enterprise tier should this feature go
see https://about.gitlab.com/handbook/product/pricing/#four-tiers )
### Links / references
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->Awaiting further demandhttps://gitlab.com/gitlab-org/gitlab/-/issues/9966Filtering out Epics which don’t have any Issues added to it.2019-11-05T18:32:24ZLisaFiltering out Epics which don’t have any Issues added to it.### Problem to solve
Currently it's not possible to Filter out Epics which don't have any Issues added to it. There is a need from a prospect to make this possible as this was a feature he used in Jira and is missing in GitLab.
<!-- Wh...### Problem to solve
Currently it's not possible to Filter out Epics which don't have any Issues added to it. There is a need from a prospect to make this possible as this was a feature he used in Jira and is missing in GitLab.
<!-- What problem do we solve? -->
### Target audience
<!--- For whom are we doing this? Include a [persona](https://design.gitlab.com/research/personas)
listed below, if applicable, along with its [label](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=persona%3A),
or define a specific company role, e.g. "Release Manager".
Existing personas are: (copy relevant personas out of this comment, and delete any persona that does not apply)
- Parker, Product Manager, https://design.gitlab.com/research/personas#persona-parker
- Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
- Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha
- Devon, DevOps Engineer, https://design.gitlab.com/research/personas#persona-devon
- Sidney, Systems Administrator, https://design.gitlab.com/research/personas#persona-sidney
- Sam, Security Analyst, https://design.gitlab.com/research/personas#persona-sam
-->
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### What does success look like, and how can we measure that?
<!-- 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. -->
### What is the type of buyer?
(Which leads to: in which enterprise tier should this feature go
see https://about.gitlab.com/handbook/product/pricing/#four-tiers )
### Links / referenceshttps://gitlab.com/gitlab-org/gitlab/-/issues/9798When closing an MR have the ability to select a different branch easily from...2019-11-05T18:32:46ZPete RaumannWhen closing an MR have the ability to select a different branch easily from MR via a dropdown.### Problem to solve
When closing an MR and want to merge to a different branch, you need to edit the MR, select a different branch then save and you can now merge to that newly selected branch. Instead of having to edit the MR, could t...### Problem to solve
When closing an MR and want to merge to a different branch, you need to edit the MR, select a different branch then save and you can now merge to that newly selected branch. Instead of having to edit the MR, could there be a dropdown on the MR page where it displays the "Request to merge -branchname- into master"? The the word "master" in this case would be a dropdown displaying the other branches.
### Target audience
- Parker, Product Manager, https://design.gitlab.com/research/personas#persona-parker
- Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
- Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha
- Devon, DevOps Engineer, https://design.gitlab.com/research/personas#persona-devon
<!--- For whom are we doing this? Include a [persona](https://design.gitlab.com/research/personas)
listed below, if applicable, along with its [label](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=persona%3A),
or define a specific company role, e.g. "Release Manager".
Existing personas are: (copy relevant personas out of this comment, and delete any persona that does not apply)
-->
### Further details
<!--- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
<!--- How are we going to solve the problem? Try to include the user journey! -->
### What does success look like, and how can we measure that?
<!--- 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 -->
### What is the type of buyer?
(Which leads to: in which enterprise tier should this feature go
see https://about.gitlab.com/handbook/product/pricing/#four-tiers )
### Links / references