### Problem to solve There is no way to easily maintain consistency of issue and merge request templates across many projects. This leads to wasted time and effort. #### Job Story > When I'm updating a description template, I need to make the updates across all projects where the template is being used, so that consistency and standards can be maintained. It is highly inefficient to require users to make an update in every single project that uses a given issue or merge request template. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Group level issue and merge request templates. - Specify which project within a group serves as the canonical source of templates across all projects and subgroups within the group. Ideally, extend File Templates to support Description Templates. - The specified repo is inherited from the instance to groups. - The specified repo is inherited from groups to subgroups. - Projects look to their nearest parent group to determine which repository to get their templates from. ### UX There is no net-new UX here. This feature will leverage the File Templates UI. <details> #### Option B - Use Markdown Frontmatter Config - Within a given template, add the ability to set a `group: true` or similar type boolean config. - All templates that are `true` would bubble up to the group level. - Provide a list of these on the group level somewhere so that it's easier to track down the template source. Pros: - Pretty flexible in that various projects can all bubble up different group level templates. - No need to "configure" anything at the group level. Cons: - Same as Option A #### Option C - Templates Interface Add interface for managing description templates on the group level. The interface would support: - Adding, editing, removing description templates. - Changelog per template Pros: - First class user experience. - Provides a good foundation for future template improvements. Cons: - More expensive to build and will take longer. - Requires creating new API endpoints/functionality. </details> ### MVC Breakdown - Add support for Description templates in the File Templates repo and ensure proper inheritance for the selected repo across instance > group > subgroup > project. - Add support for Epic description templates the same way Issue/MR description templates work. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> - They should mirror the same permissions for File Templates. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> - Yes ### Testing <!-- What risks does this change pose? 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? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> - Yes ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> #### Success Metrics - People get more time back by having a centralized location to manage templates across subgroups and projects (Difficult To Measure). - Count of group level description templates created. - Count of issues being created from group level templates. #### Acceptance Criteria - The same repo that is set for File Templates can also store description templates - The selected repo is inherited across instance > group > subgroup > project. - Description templates successfully populate from the specified file templates repo. ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> - According to our [pricing model](https://about.gitlab.com/handbook/product/pricing/#four-tiers), solving for this use case most likely aligns with the Director or above, putting this into ~"GitLab Premium" ### Links / references **Original Description:** <details> Let me preface my suggestion by saying, to me at least, the very idea of a template is to allow one standard structure to be applied in multiple places, keeping the base consistent across the board. That said, could we perhaps have the ability to set up issue and merge request description templates per group? Using a common template for all projects in a group would create beautiful consistency, especially in Java environments where an application is made up of many modules, each of which are stored in their own repository. </details> #### Description Templates Inheritance Solution Validation We have the `File Templates` feature, that can be setup at [group](https://docs.gitlab.com/ee/user/group/index.html#group-file-templates) or [instance](https://docs.gitlab.com/ee/user/admin_area/settings/instance_template_repository.html#instance-template-repository) level and be inherited by any project within given instance or group. We also have issue and merge request [description templates](https://docs.gitlab.com/ee/user/project/description_templates.html#description-templates) that currently can only be applied at the level of the project that defines these templates in its repository. - Example of file templates dropdown with templates repository defined at multiple group levels:  - Example of description templates dropdown within same project:  Although these are described as different features in our docs, both are basically templates, and more than that both sources of the templates leave within the project repository, with only difference that each lives within its own folder(s). I think it would make sense to combine file and description templates setting at the group level by reusing already existing file templates setting to define from which (single) templates repository should all the projects within the group pull both file and description templates. If the group hierarchy has multiple subgroups each of the subgroups, would be able to define its own templates repository which would add to the list to already existing templates. So then the description templates dropdown would look similar to file templates, but listing the issue or merge request templates instead:  #### Tasks - [ ] (Weight: 3) [BE]: Refactor/reuse/unify file templates implementation feature implementation to make use of `Template Repository` setting at the group level and let the projects within the group or its subgroups inherit the issue, merge request, epic description templates from given `Template Repository`, POC: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46222 There are 3 implementations for fetching templates data on BE as well - [ ] issuables_helper generates code for HAML - [ ] templates_controller - used on edit issue page - [ ] templates REST API - used by file templates I think - [ ] (Weight: 3) [BE]: Fix an issue with file templates pulling same content for templates with same names from different paths. - [ ] (Weight: TBD) [FE]: Cleanup FE code for rendering templates dropdown, as currently we have 3 different implementations I think: - [ ] Haml based when rendering new issue page - [ ] A combination of vue + js when rendering edit issue page, I think - [ ] I think a partly different implementation for rendering dropdown for file templates - [ ] (Documentation: TBD) [DOC]: Update documentation about inherited issue and merge request templates. - [ ] Inheritance of description templates rolls-up to instance now - [ ] Inheritance of description templates depends on group file templates settings, ie. update corresponding documentation to reflect that as well - [ ] https://gitlab.com/gitlab-org/gitlab/-/issues/293717 this issue also touches partly on templates documentation update