We encourage engineers to add feature flags in many scenarios in order to safely roll out some of our work - but when the feature flags stay in the codebase over a period of time, we accrue tech debt and are never able to release the work that we have already done. The more stale feature flags left in the system, the less customer value we have provided.
Manage has 60+ feature flags in the codebase that are older than 2 months. A recent conversation has surfaced around whether or not we are taking action on the monthly feature flag reports, which has raised my own questions.
Group
# of Flags
Notes
Auth
30
- Some are under "manage::access", "access" and "authentication and authorization" - Most of them are disabled, a total of 24
Workspace
14
- All of them are disabled.
Import
12
- Some are under "import" and others are under "group::import" - 7 of them have been default enabled for ~2 years (I would think these are safe to remove by now)
Yes! thank you for consolidating the list of FFs, I wasn't aware of the full set in disabled state. Will come back with ones we can remove or enable in the near future vs ones that are really old and need additional work to complete the feature. I'd argue if we haven't enabled a functionality for more than 6-8 months, it has likely has fallen off the priority.
@m_gill Thanks for the ping. In fact, we have an issue for consolidating the feature flags in ~"group::import" that need to be cleaned up: gitlab-org/gitlab#345293
However, we need to prioritize this again as we didn't spend too much time on this recently. I'll work with the team on this.
The reason for having older feature flags is that they belong to two complex features (auto-disable webhooks, Jira proxy) that have been slipping a few milestones.
I went through the Auth team FFs and there is a mix of:
Legacy + new FFs that were not enabled (in prod or as default)
Few that are incorrectly reported in the yml file. I'll update those
Being used as configuration options but really should be an app setting.
Authentication team owned
These will need scheduling and a discussion with product on their removal. I'll work through getting them as our regular maintenance work in the next few milestones.
This feature is not a priority anymore and the original issue requiring this work was resolved via \
\
https://gitlab.com/gitlab-com/support/internal-requests/-/issues/8288
dynamic_nonce
No issue
Disabled
An additional encryption method that we will review and schedule for \
\
https://gitlab.com/gitlab-org/gitlab/-/commit/1914a1e3493f8b87cc1948d5b29f755af7a72c20
These are already owned by the workspace team, and I will update the respective .yml files so that they surface in the triage reports. @mksionek Definitely let me know if you see any of the ones I am mistaken about.
Potentially owned by Workspace team based on features
These issues would fall into the workspace team based on the feature grouping, but similarly @mksionek let me know if you see otherwise. If any of them have context with engineers across auth team that help in removal, we can keep it in auth. I'll update the .yml for these as well