Parameterized issue/MR templates

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

  • Close this issue

Description

Consider these issue templates used at GitLab:

  • https://gitlab.com/gitlab-org/release/tasks/blob/master/.gitlab/issue_templates/Exception-request.md
  • https://gitlab.com/gitlab-org/release/tasks/blob/master/.gitlab/issue_templates/QA-task.md
  • https://gitlab.com/gitlab-com/migration/blob/master/.gitlab/issue_templates/failover.md

They all have in common the idea that a user needs to change certain placeholders in the template text into actual values. However, especially when a placeholder is used multiple times, or there are a large number of them, it becomes difficult to manage this manually. It may also be unclear what sort of value is expected for a given parameter.

Proposal

Our issue templates are markdown, and markdown can have metadata. There's a few ways to do this, but the most common is to have a hash at the very top of the markdown file, organized as follows:

---
foo: bar
baz:
  x: y
  y: z
---

# Actual markdown here

Text...

A parameterized template would be one that specifies certain placeholders, for instance:

---
placeholders:
  "@FOO": The value of foo
  "@BAR": Some value antithetical to "foo"
---

# A template

@FOO is antithetical to @BAR

When given a template like this, the GitLab frontend could prompt the user to enter values for each parameter, showing the help text, and update the template automatically before filling the new issue description.

We could also use metadata (or the <h1> equivalent element, #) to specify a default issue / MR title, using the same parameters. This is of no use at present, but with parameterization, has a great deal of value (as we see in the exception request template).

Links / references

/cc @victorwu

Edited Aug 28, 2025 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading