<!-- The format of the title should be Title should follow the format `Breaking change exception: Description`--> # Breaking Change Exception Request ## Executive summary <!-- Three to five sentences. Needs to be easy to follow by C-Level executives. Focus on customer impact --> The `abuse_report_labels` and `abuse_report_notes` feature flags were added years ago, but never released to any customers or instances, so they represent dead code. Maintaining them introduces ongoing maintenance cost, adds complexity, and adds tech debt. We propose removing both flags and all associated code. Since no one is using them, there is effectively zero customer impact. This removal simplifies the codebase and helps future maintainability. * https://gitlab.com/gitlab-org/gitlab/-/issues/517640#note_2743794123 * https://gitlab.com/gitlab-org/gitlab/-/issues/553431 * https://gitlab.com/gitlab-org/gitlab/-/issues/553432 ### Does your breaking change meet one of these three criteria? 1. The impact of the breaking change has been **fully mitigated via an automated migration** that requires no action from the customer. 1. The breaking change will have **negligible customer impact** as measured by actual product usage tracking across Self-Managed, GitLab.com, and Dedicated. For instance if it impacts less than 1% of the GitLab customer base. 1. The breaking change is being implemented due to a **significant security risk**- Severity 1 or 2. * No migration needed; the features were never enabled or in use. * Effectively 0% impact: never released, never used. * Not applicable; this is more about code health and cleanup than a security issue. ## Impact assessment ### How many users and customers are impacted? What Tier/ARR of customer? Estimated impacted users/customers: None. Since both feature flags were never enabled anywhere, there are no customers relying on them. Tiers / ARR: No customer tiers (Free, Premium, Ultimate, Self-Managed or GitLab.com) are using them. #### Usage of `abuse_report_labels`  #### Usage of `abuse_report_notes`  ### Can we get the same outcome without a breaking change? <!-- What other alternatives were considered? --> Alternatives considered: * Leaving the code and feature flags "disabled forever" -> retains maintenance overhead, confusion, possible future bugs/tests failing because code is "dead". * Archiving the code behind the flags and leaving everything in place -> still has code to maintain/test. * None of these alternatives provide the same benefit of code simplification and removal of unused dead code. So no, to get the full benefit we need to remove both flags and associated code. ### When do you want to make the breaking change? Proposal: Remove in the next minor release once this exception is approved and preparations are complete. ### What is the alternative for customers to do the same job the change will break? Since no customers were using either flag or the associated functionality, there is no alternative needed. If someone discovered use: they would have been using code behind the flags, which has no production exposure. ### How difficult is it for customers to migrate to the alternative? Is there a migration plan? Migration difficulty: none, because no one is using either feature. Plan: Delete both feature flags, remove related code, tests, YAML definitions, and remove any references in documentation. Clean up any database schema related to `abuse_report_labels` and `abuse_report_notes` if unused (though that may require separate issues). ## Rollout & Communication plan ### Have we handled similar breaking changes in the past? What can we learn from the success or failure of those methods? Yes, GitLab has a history of removing unused feature flags, such as feature_flags_new_version etc. The process tends to work smoothly when the flags are known to be unused. Key learnings: * Ensure thorough search for references (code/tests/docs). * Use deprecation or removal MRs flagged clearly so reviewers see the breaking change. * Basic communication (internally) to warn teams. ### Are you employing any strategies to lessen the customer or support impact? <!-- Gradual/phased changes, brownouts, staggering of customers. --> <!-- Gradual/phased changes, brownouts, staggering of customers. --> Because there's no customer impact, strategies are more about internal risk mitigation: * Code reviews with attention to ensuring no latent dependencies are missed. * Feature flags removal will only be enabled after approval; perhaps feature flags remain disabled until removal to ensure safe path. ### Internal Communication - Engineering, Product, Security, Customer Success, and Sales: What questions do you anticipate they will have? What is it important that they know? Anticipated questions: * Could there be hidden usage or undocumented customers relying on these features? * Are there any database table/data cleanup needed for both features? * What is the rollback plan if something breaks unexpectedly? It's important they know: these are "dead code" features, never released; removal is low risk; plan includes internal testing and review. - Support: What guidance will the support team need to handle customer tickets related to this change? - Once you receive approval to proceed with the breaking change you should create a [Support Preparedness issue](https://gitlab.com/gitlab-com/support/support-team-meta/-/blob/master/.gitlab/issue_templates/Support%20Preparedness.md?ref_type=heads) with instructions on how to handle customer queries and concerns. * Guidance: how to respond if a customer reports "abuse report labels are not working" or "abuse report notes are not working" (they shouldn't, because the features were never enabled). * Prepare support article or internal note: these were never available, no action required. ### Customer Communication What form will this take? <!-- You can use a banner, targeted customer email, customer newsletter mention, CSM outreach, blog post, or a combination of those methods. --> <!-- You can use a banner, targeted customer email, customer newsletter mention, CSM outreach, blog post, or a combination of those methods. --> Can you inform the impacted customers directly rather than sharing a generic message to those who may not need to take action? * Since no customers are using either feature and they were never released, no external customer communication is necessary. * If desired, could mention in release notes: "Removed dead unused feature flags `abuse_report_labels` and `abuse_report_notes`. No existing usage; no customer action required." * If internal CSMs or account managers ask: reassure them it's internal only; no external impact. If you are sharing communications with customers, the plan and written copy must be approved by the **Corporate Communications** team and the **Customer Success** Team. ## Approval Process - [ ] Tag in the appropriate Product Director and Engineering Director for your product area. They may ask for further clarifications. - [ ] Approved by **Product Director**: TBD https://handbook.gitlab.com/handbook/engineering/development/sec/software-supply-chain-security/authorization/ - [x] Approved by **Engineering Director**: @mmishaev - [ ] Once you have approval from both Directors, add the label "Breaking Change: Awaiting VP Approval" and remove the prior label. - [ ] This will be added to the agenda for Prod + Eng Weekly Strategy meeting to be reviewed. If it is granted VP approval they will add the "Breaking Change: VP Approved" label. - [x] Approved by **Product VP**: TBD - [x] Approved by **Engineering VP**: @maw - [ ] Seek approval on any customer comms from the **Corporate Communications** and **Customer Success** teams