## 💬 Problem to solve <!-- 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)." --> After pushing their changes to the repository, [Sasha](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) or [Devon](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) might identify that the pipeline is possibly taking longer than they expect to, or might just want to check on the health of a few jobs they're skeptic about. To achieve this, they have to click on a job in their pipeline, go to a completely new page, view the logs very carefully to identify the problems if any. The process is tedious and takes a long time and also does not provide a quick way to act upon the identified bottlenecks to optimize the pipeline. The information is scattered across GitLab and so are the actions related to it, leaving users tired and confused, if not frustrated. Supporting insights: TBD ## ⚡️ Proposal _This effort is a visionary concept_ ### Link to video with explanation: https://youtu.be/Nzar8xZMdSk?t=1188 <!--| Design and Interactions | |----------------| |  |--> | Components and associated issues/epics | |----------------| |  | | Number | Component | Issue | |--------|-------|-------| | 2. | Selected job in the list view, users wants to view the detail for | | | 3. | A slide-out panel that opens upon selecting the job, the title is the name of the job | https://gitlab.com/gitlab-org/gitlab/-/issues/280772 | | 4. | The logs organised as collapsible sections. The failed section appears with highlighted shell script that broke the job | https://gitlab.com/gitlab-org/gitlab/-/issues/289917 | | 5. | All the actions associated with the selected job | | ## :footprints: Next Steps Once a direction is finalised for the overall plan, break it down into iterations and create new issues