<!--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=24112) </details> <!--IssueSummary end--> ### Problem to solve GitLab ships with built-in vendor project templates. In addition, with https://gitlab.com/gitlab-org/gitlab-ce/issues/48043 we are introducing project templates, allowing to bootstrap a new project based on prepared configuration and boilerplate code.\ Since the amount of out-of-box templates and custom templates can become large quite fast, we should implement a way to allow enabling/disabling built-in vendor templates. Right now, these are * Ruby on Rails * Spring * NodeJS Express ### Proposal Let's add the option for Administrators to enable/disable the built-in templates in the Admin Area. ### Solution _tbd_ ### Earlier designs #### Enable/disable templates **Admin area → Project templates → Built-in templates** | List | Empty | Undefined | |------|-------|-----------| |  |  |  | ### What does success look like, and how can we measure that? **For the team (internal):** * Administrators can enable or disable built-in project templates globally via Admin Area settings * The setting is also manageable via API for organizations that manage configuration programmatically **For customers (measurable after the feature ships):** * Adoption of the setting by organizations with custom template libraries (target: upward trend among self-managed Ultimate customers) * Reduction in feedback and requests related to template confusion or accidental use of built-in templates