<!--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=423373) </details> <!--IssueSummary end--> <!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ### Problem to solve Instance-wide Project templates only show Projects directly under the Group that is configured globally. When maintaining multiple versions of a given type of templates, it can quickly grow and become hard to browse. To illustrate, Built-in templates for Netlify suffer from the same problem.  ### Proposal Instance templates should render the Sub-groups of the Group that is configured to hold its templates. This would make organizing templates far more intuitive as we could have a hierarchy. Building on the Netlify example, the instance could be configured to use the group **Gitlab Templates**. That groups would have a **Netlify** sub-group which will in turn hold the Projects **Hugo**, **Jekyll**, **Plain HTML**, **GitBook** and **Hexo**. An example of how it would look like can already be seen in Group templates, under the condition that you create a Project from Template from outside of a Group.  By doing so, the tab will include all the Group Templates from Groups you are member of. However, these templates cannot be used outside of said group, which make them unusable for more general-purpose templates. ### Intended users * [Parker (Product Manager)](https://about.gitlab.com/handbook/product/personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/product/personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/product/personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/product/personas/#priyanka-platform-engineer) * [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) * [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/product/personas/#cameron-compliance-manager)