<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=26214) </details> <!--IssueSummary end--> ### Problem to solve Currently, gitlab.com users with multiple projects have to iterate through all projects in order to disable auto devops. Furthermore, as we rollout our staggered enablement of the feature some users may get _some_ of their projects enabled and not others. ### Further details (Include use cases, benefits, and/or goals) ### Proposal Provide a mechanism through which users can disable auto devops for the gitlab.com projects. Furthermore, if the setting is set to disable, our staggered rollout should ignore the user's projects and not enable. #### Userspace level This flow should follow the group level flow. Settings will be under `profile/preferences`  Users will be able to turn off the setting, removing the `instance enabled` badge and disabling the Auto DevOps pipeline on all projects that haven't been explicitly set. #### Userspace with Auto DevOps setting off, instance enabled removed  #### Project that was enabled via the instance level is no longer enabled  If a user turns off the instance enablement at a userspace level and then turns it back on, the badge under projects should read `userspace enabled`  If a user turns off the userspace enablement at a project level, then the badge should be removed. ### What does success look like, and how can we measure that? (If no way to measure success, link to an issue that will implement a way to measure this) ### Links / references Re: https://gitlab.slack.com/archives/CB07X8AQ3/p1539092581000100