## Summary Roll out [the feature](https://gitlab.com/gitlab-org/gitlab/-/issues/597919) currently behind the `mr_ai_overview` feature flag. - DRI: @marc_shaw - Team Slack channel: `TODO` The flag does not turn the new experience on by itself. It makes a **Try the new overview** item appear in the merge request overflow menu; each user opts in and out for themselves, and the opt-in is a `mr_ai_overview_enabled` cookie that lasts a year. Same shape as Rapid Diffs. Introduced by !252481, built up over !252997, !252998 and !252999. > [!note] > Process and guidance live in the docs - this issue is just the commands and a place to track the rollout. > [Feature flag controls](https://docs.gitlab.com/development/feature_flags/controls/) · [Feature flag lifecycle](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle) ## What could go wrong? **Blast radius is a single opted-in user at a time.** With the flag on and nobody opted in, the only change to the merge request page is two `false` data attributes on the overflow menu container. Verified by rendering all four merge request tabs with the flag off and diffing against the merge base: the only other differences were per-request values (correlation id, CSP nonce, two timestamps). **The opt-in replaces the whole Overview tab.** No merge widget, no discussion thread, no issuable sidebar, so an opted-in user cannot merge or read discussions without switching back. That is the deliberate design, not a defect, but it is the main reason someone would opt straight back out. **Two known gaps while a user is opted in.** Both need watching during the rollout, neither throws: 1. `window.gl.mrWidgetData` is never defined, because the partial that creates it is the merge widget. The Pipelines tab therefore mounts with a null merge request id and empty project paths, so the GraphQL pipelines table and "run pipeline" lose their inputs. 1. The sticky header's thread counter is hidden on the Overview tab, because only `init_notes.js` and the classic diffs app emit `fetch-notes-data`, and the notes app is not mounted. It appears once the user opens Changes. **What to measure before this flag changes type or goes wider:** - Whether opted-in users stay opted in, or flip back within a session. That is the actual signal this flag exists to collect. - The cost of the `mrAiOverview` GraphQL query per Overview view. It reads only existing `MergeRequest` fields, but it is one extra request per page view that the classic tab does not make. - Whether the two gaps above generate reports, and whether either needs fixing before the flag widens beyond internal use. ## Rollout The feature actor is the project's **root ancestor**, so target groups rather than projects or users. **Non-production** ``` /chatops gitlab run feature set mr_ai_overview true --dev --pre --staging --staging-ref ``` **Production** - this flag is for internal feedback first, so start with `gitlab-org` rather than a percentage: ``` /chatops gitlab run feature set --group=gitlab-org,gitlab-com mr_ai_overview true ``` Only move to a percentage rollout once the experience is worth showing to customers: ``` /chatops gitlab run feature set mr_ai_overview <percentage> --actors ``` ## Before global rollout This is a `wip` flag and the experience is not finished, so global rollout is not the near-term plan. Before it ever goes to 100%: - Change the flag type from `wip` to `beta`, which is what makes the wider rollout checklist apply at all - [Docs + version history](https://docs.gitlab.com/development/documentation/feature_flags/) updated - Both gaps above either fixed or accepted in writing - The merge widget question answered - either the new overview grows one, or opted-in users are expected to switch back to merge ## Cleanup Remove the flag once [deemed stable](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle) - see [cleaning up](https://docs.gitlab.com/development/feature_flags/controls/#cleaning-up). Removing the flag also means deciding what happens to the cookie and the toggle: either the new overview becomes the only overview and both disappear, or the toggle becomes a real user preference rather than a cookie. ``` /chatops gitlab run release check <merge-request-url> <milestone> /chatops gitlab run feature delete mr_ai_overview --dev --pre --staging --staging-ref --production ``` ## Rollback ``` /chatops gitlab run feature set mr_ai_overview false # production /chatops gitlab run feature set mr_ai_overview false --dev --pre --staging --staging-ref # non-production /chatops gitlab run feature delete mr_ai_overview --dev --pre --staging --staging-ref --production # remove entirely ``` Turning the flag off is enough on its own - a user with the cookie still set falls straight back to the classic Overview tab, verified on GDK.