### The problem Feature flags are currently reported on in several places discoverable by infrastructure: 1. [Logs](https://nonprod-log.gitlab.net/goto/e9ea2610-2455-11ed-af31-918941b0065a) 2. The [feature-flag-log](https://gitlab.com/gitlab-com/gl-infra/feature-flag-log/-/issues) issue tracker However, it's not easy to go from there, to a feature flag issue that could have been created in several places depending on the project. The feature flag issues that are created [based on the template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20Flag%20Roll%20Out.md) contain a lot of checkboxes that aren't always relevant, and therefore not always used. This makes it hard for people to discover what was changed when, and what impact it could have had. ### Proposal Generate feature-flag issues as change issues in the production issue tracker. We could use woodhouse to generate an appropriate issue, asking for relevant information to the engineer planning the feature flag rollout: - feature flag name - short description about what the feature flag does - merge request that introduces the feature flag - Criticality (default ~C4) This would create a new change issue in the production issue tracker that is in a place that makes it easier to find for SREs during incidents. Since this issue is linked from [source code](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/feature_flags/development), chatops can also find the issue every time a flag is changed to add the change to the event log in the change description. Making sure that this information is always correct without engineers having to remember about updating the issue.