<!-- 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 --> <!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ### Problem to solve As an app dev team lead, I want to see how quality is trending in my projects, so I can prevent escaped defects and spend time shipping features not bug fixes. ### Additional information / use cases Hypothesis: If we provide high level data from more features to team leads, they will get their team to use the features driving usage. Experiment: Add data views for data we have about test execution and code coverage, add teaser links that can be tracked for other categories to inform what to develop next. ### User experience goal of this iteration <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> The user should be able to navigate to the page that will hold data implemented as part of &5430 ### Proposal 1. Create a tab on the existing Analytics -> CI/CD page for a Quality Summary page 1. Create the empty page 1. Add documentation for the new page (place holder) 1. Wrap it all in a feature flag? #### Technical proposal - Create a new blank vue component that we'll build the project summary in, something like `ee/app/assets/javascripts/project_quality_summary/components/app.vue` - Put the new component inside of a new `<gl-tab>` with the title `Project Quality` in [`~/projects/pipelines/charts/components/app.vue`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/assets/javascripts/projects/pipelines/charts/components/app.vue) - Add a new feature flag called `:project_quality_summary`, push it to the frontend, only display the tab/contents if it's enabled ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> Create some place holder documentation for the new page about what will be on it, this can be iterated on in later issues in the epic. ### What does success look like, and how can we measure that? #### Acceptance Criteria * The page is created - See https://gitlab.com/gitlab-org/gitlab/-/issues/337307 for design. * The page/tab is available when feature flag is set to display it * The page/tab is NOT available when the feature flag is set to not display it * UX review done cc @gdoyle * Page has a breadcrumb to navigate back to other parts of the site ### Available Tier ~"GitLab Ultimate" ### Links / references <!-- Label reminders - you should have one of each of the following labels. Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ --> * [Design Iteration issue](https://gitlab.com/gitlab-org/gitlab/-/issues/337307)