<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=629143) </details> <!--IssueSummary end--> This issue collects what we learned while `hide_unpinned_sidebar_items` was enabled for GitLab team members, and defines what has to be true before we turn it on again. ## What happened We enabled `hide_unpinned_sidebar_items` for GitLab team members on **2026-08-21 at 14:30 EDT** and disabled it on **2026-09-01 at 03:12 EDT** — 10 days and 13 hours. During that window the left sidebar showed only pinned items; every other feature moved behind the `More features` feature catalog modal. Feedback came in through [#604008](https://gitlab.com/gitlab-org/gitlab/-/work_items/604008), which collected 160 comments from roughly 50 team members. The feature flag worked as intended, allowing us to turn off the feature and continue to improve the experience in preparation for broader rollout. ## Feature details ### Pinning The left sidebar shows default pins unless a user manually customized their pins. Pins persist across namespace type (group/project). Default pins include the following: | Group | Project | | --- | --- | | Members | Members | | Work items | Work items | | Issue boards | Branches | | Merge requests | Merge requests | | Epic boards | Pipelines | ### Feature catalog The feature catalog (`feature_library_modal`) is on for everyone and stays on. Only tailored navigation was rolled back.&#32; ## What the data says Customers use the sidebar at scale and almost never customize it, so they live on whatever ships by default. The default set should be built from customer behavior. Team members are not a stand-in for customers, but the forced rollout gave us a look at how engaged users curate when they have to choose. ### Customers use the sidebar heavily, and rarely customize it Over the last 30 days on gitlab.com, at least **31% of active customers** (686,631 users) navigated by clicking the sidebar. That is a floor, because ad blockers drop some frontend events, so real usage is higher. Just **~617,000 customers** (2.4% of active users) have ever engaged with pins. Only **~2.1% of customers pinned anything in the last 30 days** (46,720 users), and **34,402 unpinned** in the same window. #### What users click and pin most Both signals put **Merge requests and Pipelines** far ahead, followed by the code cluster (Repository, Commits, Branches, Issues). All gitlab.com users, last 28 days: **Most-clicked project sidebar items** | Item | Users | | --- | --- | | Merge requests | 338,743 | | Pipelines | 238,574 | | Overview | 207,546 | | Branches | 174,924 | | Commits | 120,158 | | Members | 115,077 | | Repository | 109,255 | | Issues | 69,694 | **Most-pinned project items** | Item | Users | | --- | --- | | Merge requests | 4,370 | | Pipelines | 3,461 | | Issue boards | 2,006 | | Repository | 1,445 | | Commits | 1,270 | | Tags | 1,126 | | Branches | 1,126 | | Issues | 846 | Click counts are a floor (frontend events lost to ad blockers); pin counts are exact (logged server-side). The two lists agree on the core, with two differences worth noting: **Issue boards** ranks high in pins but not clicks, and **Overview** and **Members** rank high in clicks but not pins. Customers rely on the default structure rather than tailoring it. ### What the forced pinning window revealed Putting team members into a pinned-only sidebar resulted in roughly **1 in 5 team members** customizing, and most who did built a **focused set of about five items** rather than recreating the full nav. They pinned the core workflow plus advanced tooling, with **42% of customizers pinning an AI or security feature**. ### Ultimate features AI and security features have low click rates overall, yet **Ultimate customers use security features**, and **team members pinned AI or security heavily when placed into forced pinning** (42% of those who customized). This suggests latent demand among entitled users that a tailored nav could surface. It is a hypothesis worth testing, not a proven pattern. ## Path to re-enable The data validates the default pins: customers navigate the sidebar heavily and rely on defaults, and the core items (Merge requests, Pipelines, code cluster) match what they click. The forced rollout revealed that having the right defaults is not enough. Five problems emerged that gate re-enablement: | What breaks | Who it hits | Root cause | | --- | --- | --- | | Features a user relies on every day are missing from their sidebar | Everyone; worst for users with one or two existing pins | If a user had pinned previously, they lost the default list. | | Users do not understand what happened to their sidebar or why | Everyone, on first load | Nothing guided the user through the navigation shift, users did not feel in control. | | Users cannot get back to a full sidebar without pinning one item at a time | Support, SAs, workshop leads | There was no way for users to opt out or keep their existing navigation | | Users with many pins cannot quickly find the item they want | P90+ (ten or more pins); 12 people raised it | Category headers disappeared | | Users cannot find Settings or the pages inside it | Everyone who needs a settings page | Settings moved outside of where other namespace nav items live |