Auto-creation of issues for alerts off by default (#217034) · Issues · GitLab.org / GitLab

Auto-creation of issues for alerts off by default

Problem to solve

Currently, the setting that enables issues to automatically generate when an alert comes into the generic alert endpoint is set to be on by default. We've heard from many users that they are not using this feature because it is risky and cannot be customized. We need to change it to be off by default.

Intended users

Proposal

Change the default state of the auto-issue creation setting for new projects created in GitLab.

Further details

This work supports the direction of the Alert Management product category.

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

### Problem to solve
Currently, the setting that enables issues to automatically generate when an alert comes into the generic alert endpoint is set to be on by default. We've heard from many users that they are not using this feature because it is risky and cannot be customized. We need to change it to be off by default.

### Intended users

* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
* [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops)

### Proposal
Change the default state of the auto-issue creation setting for new projects created in GitLab.

### Further details
This work supports the direction of the [Alert Management](https://about.gitlab.com/direction/monitor/debugging_and_health/alert_management/) product category.

### Permissions and Security

### Documentation

<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change

* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
* If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html -->

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

### What does success look like, and how can we measure that?

### What is the type of buyer?

### Is this a cross-stage feature?

### Links / references

Edited May 13, 2020 by Sarah Waldner

Discussion
Designs