<!--Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks. https://www.learning-styles-online.com/style/visual-spatial/--> ### Problem Feature flags remain in codebase for months / years after enablement in production. This leads to technical debt, increasing complexity of codebase over a period of time. <table> <tr> <th>Doc recommendation</th> <th>Suggestions</th> </tr> <tr> <td> * GitLab development docs recommend [feature flags to be short lived in codebase](https://docs.gitlab.com/ee/development/feature_flags/#feature-flags-in-gitlab-development) and [to be removed as soon as it is not required](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) * FF cleanup is already included as a [checklist item](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/.gitlab/issue_templates/Feature%20Flag%20Rollout.md?ref_type=heads#release-the-feature) in the rollout plan template </td> <td> 1. Introduce a way to enforce the flags are removed from codebase and deleted before the rollout issue is closed 2. Implement a triage report such as the one in [GitLab](https://gitlab.com/gitlab-org/quality/triage-reports/-/issues/5480) that reports feature flags that have been enabled in the codebase for 2 or more releases. We can ping the respective team or create a Slack notification to encourage cleaning up in upcoming milestones </td> </tr> </table> ### Proposal <!--Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved.--> Gitlab uses [gitlab-feature-flag-alert](https://gitlab.com/gitlab-org/gitlab-feature-flag-alert/) project which unfortunately is [specific to the GitLab project](https://gitlab.com/gitlab-org/gitlab-feature-flag-alert/-/blob/533ec3024be56a498e425f85f92be0dad3fc54a2/lib/gitlab/feature_flag_alert/monitor.rb#L12). Gitlab uses a [different strategy](https://gitlab.com/gitlab-org/gitlab-feature-flag-alert/-/blob/533ec3024be56a498e425f85f92be0dad3fc54a2/lib/gitlab/feature_flag_alert/monitor.rb#L77) to maintain feature flags ([Unleash](https://docs.gitlab.com/ee/operations/feature_flags.html)), and so it may not be straightforward to extend it to CDot. We could potentially build a simple solution such as running a CI schedule that [retrieves Feature flags](https://docs.gitlab.com/ee/api/feature_flags.html#list-feature-flags-for-a-project) in CDot project that are enabled in production for more than a certain period of time. The result can be output to a triage issue and maybe ping PMs/EMs. Ideas shared by @vvempati: * In addition to providing the list of feature flags that need cleaning up, its worth including the list of issues that don't have an issue/epic specified in the description in the triaging issue. This would ensure we periodically make sure the feature flags have an issue attached to them. With regular triaging, this will get easier once we've addressed the existing feature flags that don't have any issues. * As its not easy to figure out who owns a feature flag, as a future iteration, we could potentially fetch the group labels from the linked issues in the description (using [resource label events API](https://docs.gitlab.com/api/resource_label_events/)) to figure out the ownership of the feature flags and ping stakeholders accordingly. ### Result ### Next steps (if any) ### How will we measure success?