Redmine issue templates solve a specific problem bug report quality determines how quickly bugs get fixed. A report with a clear summary, reproduction steps, expected behaviour, and actual behaviour gives a developer everything they need. In contrast, a report that says “the thing doesn’t work” sends the developer back with questions a round-trip that adds hours or days to resolution.
However, Redmine has no built-in issue templates. Reporters create new issues from a blank form. Some fill in the relevant fields. Many do not. As a result, issue quality is inconsistent across the project and development teams spend part of every sprint gathering information that should have arrived with the issue.
The Redmineflux Issue Template Plugin fixes this. In short, it adds pre-filled issue templates by tracker type Bug, Feature, Task, Support. When a reporter creates a new bug issue, the description field contains the template structure: Summary, Steps to Reproduce, Expected Result, Actual Result, Environment. The reporter fills in the blanks. The structure is already there.
The short answer: Redmine has no built-in issue templates. New issues are created from a blank form. The Redmineflux Issue Template Plugin adds configurable templates per tracker type Bug, Feature, Task, and any custom trackers your project uses. When a reporter opens a new issue, the template pre-fills the description field with the required structure. Every issue arrives with the right fields present, reducing back-and-forth between reporters and developers.
In practice, some teams write template instructions in the project wiki and ask reporters to copy-paste them into new issues. This approach depends entirely on reporters remembering to do it. Consequently, it does not work consistently at scale, and it does not work at all for occasional contributors or clients submitting issues directly.
The Redmineflux Issue Template Plugin adds template management to Redmine at the project and global level.
Each Redmine tracker can have its own template. A bug tracker template includes reproduction steps and environment fields. A feature request template includes user story format, acceptance criteria, and priority justification. A support tracker template includes client name, affected system, and urgency.
Specifically, templates are defined by the project administrator and apply automatically when a reporter selects that tracker type on a new issue. The reporter does not need to find the template it appears in the description field automatically.
Templates are written in Redmine’s text formatting syntax. Administrators structure the template with section headers, placeholder text, and required fields. A typical bug report template:
**Summary:**
[One-sentence description of the bug]
**Steps to Reproduce:**
1.
2.
3.
**Expected Result:**
[What should happen]
**Actual Result:**
[What actually happens]
**Environment:**
- Redmine version:
- Browser / OS:
- Affected project:Reporters work through the template section by section. As a result, nothing arrives blank. The developer receives consistent, structured information on every issue.
Additionally, for organisations managing multiple projects in Redmine, global templates apply across all projects without per-project configuration. A global bug template ensures that every bug report across every project regardless of which team created it follows the same structure.
This is particularly valuable for cross-team projects, client-facing issue submission, or organisations that have a quality standard for all reported work.
A single tracker can have multiple templates for different use cases. A bug tracker might have separate templates for: frontend bugs, backend bugs, and performance issues. A feature tracker might have templates for: new feature requests, enhancement requests, and UX improvements.
When a reporter creates a new issue, they select the tracker and then choose the relevant template from a dropdown. Specifically, the selected template loads into the description field immediately.
Templates are versioned. When a template is updated, the update applies to all new issues created after the change. Existing issues retain the version of the template that was active when they were created. Administrators can view and revert to previous template versions.
In practice, software agencies and product teams that accept bug reports from clients benefit most immediately from issue templates. Without a template, client-submitted bugs vary enormously in quality. With a template, the client is guided through the required information before submission. As a result, the development team receives actionable reports without a follow-up round-trip.
Combined with the Help Desk Plugin for client-facing ticket intake, templates ensure that both the submission form and the issue structure guide reporters toward complete, useful reports.
Similarly, QA teams submitting bugs from the Testcase Management Plugin benefit from a consistent bug report template that links the bug to the test case that found it, the environment it was tested in, and the steps to reproduce from the test run. The template structure captures all of this without requiring QA engineers to remember what to include.
Additionally, product managers and stakeholders submitting feature requests use a template that captures: the user problem being solved, the proposed solution, the expected business value, and any constraints. Consequently, every feature request arrives with the information needed for prioritisation not just a description of what the requester wants to build.
No. Redmine creates new issues from a blank form. The Redmineflux Issue Template Plugin adds configurable templates per tracker type. When a reporter selects a tracker to create a new issue, the template pre-fills the description field with the required structure sections, placeholder text, and required fields.
Yes. The Issue Template Plugin supports separate templates for each tracker type Bug, Feature, Task, Support, and any custom trackers. A single tracker can also have multiple templates for different use cases, selectable from a dropdown when creating a new issue.
Yes. The plugin supports global templates that apply across all projects in the Redmine instance. Project-level templates are also supported and override global templates for the specific project they are configured in.
Yes. Template updates apply to new issues created after the change. Existing issues retain the description content from when they were created. Previous template versions are stored and accessible to administrators.
The Redmineflux Issue Template Plugin supports Redmine 5.0.x, 5.1.x, and 6.0.x. Teams running Redmine 4.x should contact support before purchasing to confirm compatibility.
In short, every incomplete bug report is a communication failure between the reporter and the developer and the developer pays the cost. Issue templates do not add bureaucracy. They remove the uncertainty that creates back-and-forth, and they set the reporter up to provide what the developer needs. Specifically, the Issue Template Plugin makes that structure automatic.
Related Reading
