Issue description templates
|Target version:||Unplanned backlogs|
When opening new issues it would help guiding the user to be as detailed as possible if an administrator could create a predefined template per tracker (per project?). Such a template need only be displayed as stand in text in the description field so that the user can then replace template parts with the actual input.
#1 Updated by Thomas Lecavelier about 12 years ago
I don't think it's a "want-have" feature:
Even if it should be a good idea to teach BTS usage to new users, they soon will be proficient in using it, so entering an issue using n pages will become time-consuming. Organizing a small meeting presenting the tool with some real-usage of the tool for each attendee should be more valuable.
(or maybe I haven't understand your idea :) )
#2 Updated by Ale Muñoz about 12 years ago
+1 for this.
What he is suggesting is this:
- When the user clicks on "New Issue", the description field is pre-filled with a text like this:
What you did
Please describe what you were doing when you found the issue
What were you expecting to happen?
What happened instead
Please tell us what is your operating system, version, browser, etc...
(or words to that effect)
Check http://twitter.com/help and you will understand. That form is a masterpiece of design, and is used a lot like a good example of how things should be done : )
#4 Updated by Adam Bates over 11 years ago
I was wondering if this suggestion would be revisited, as for a consistency reason it would a great feature. We have three very different trackers which have three different purposes. It would be good to provide a template for the user to provide verbose responses within a structure.
#6 Updated by Mischa The Evil over 9 years ago
- Subject changed from Description templates to Issue description templates
- Category changed from UI to Issues
#7 Updated by Erwin Mueller over 9 years ago
It would be great if you can specify a template per project and one to each issue category (bug/feature/support).
For example, what I like to have for issue type feature:
You can't have this with custom fields, because if you add custom fields, they will be under the description text field, below the standard fields, above the files upload field.
#24 Updated by Matthew Houston over 6 years ago
Not sure if the template ticket should have been closed as duplicated. http://www.redmine.org/issues/12807
I think this particular ticket is already addressed by the custom fields. If that info is required then a custom field can be created and set as required?
Templates on the other hand are a different matter. For instance we are managing store installations with Redmine and to be able to have a template with pre-filled relationships and sub-tasks based on different criteria that the user could select would be great.
At the moment we just have an existing issue with all sub-issues created and linked, but it doesn't cover nearly enough, having the user select from a list would be awesome! While it is handled currently by a plugin, the rapid rate of releases is seeing a lot of these plugins just fall by the wayside unfortunately...
#27 Updated by Ilya Demenkov over 6 years ago
We are currently using http://www.r-labs.org/projects/issue-template plugin as advised by John McBade at #11210 for this, but its features are limited, not not mention it's better to have such feature built-in.
As I've described in #11210, such feature should allow to set default values for most fields of an issues, not just for its description.
#31 Updated by Jan from Planio www.plan.io over 6 years ago
We've discussed this at Planio at lengths and the verdict was we don't think it's a good idea. It will create large chunks of unstructured text and possibly boilerplate content that cannot be queried against or otherwise be used.
In my opinion, the world should be as structured as possible and we already have custom fields for that: all the questions one would ask in these "issue templates" should actually become custom fields. What's even better: you can make them mandatory, searchable and things will just generally be much better than with templates.
#32 Updated by TridenT Job over 6 years ago
I would like to use template for my 'backlog' and 'story' bug trackers.
Today, the template is store in a wiki page, and is copy/paste every time.
- help the submitter to structure the feedback
- Give directions, advices to submitter
- same format for ticket
- better than custom fields as it is open to any formatted text
#33 Updated by Christian Dähn about 6 years ago
There are reasons for, but even against custom fields.
E.g. if you have different types of tickets like "service case" and "feature request".
For "service case" the description has to answer some questions, which are EVERYTIME free text answers (what did the customer report? what are possible reasons for the problem? what are the next steps? what is the solution?). When we search for keywords it's not predictable in which of these questions/sections (or: custom fields) these keywords occurr. Therefore we just search the issue description to filter our results - which is efficient for searching, as for creating/editing.
For "feature request" non of the above questions/sections (or: custom fields) can be reused - there are different questions which are entered as free text. So it's very hard to find custom fields, which match all or even most of the description sections of different ticket types.
Further we discussed this topic with our devs and users - with some experiences with issue templates and many custom fields in our previous Trac system. As result the users were happy that they didn't have to face with the big number of form input fields like in Trac (where we splitted our discription into different custom fields) and love the (by url passing filled) description template, where they only have to replace some placeholders with the content.
So: For some cases custom fields is the cleaner and more effective approach, for some cases issue templates do a really better job (covering more than just the description).
Hope this point of view helps a little.
#34 Updated by Fred B over 3 years ago
This can be done in sharepoint when creating project. A project template can be choosed and it create task, user, etc.
In Redmine, this would be particulary usefull to have a template for particular issues, that would auto create sub-tasks and checklists.
This would be a really valueable feature.
#42 Updated by Greg Christopher 6 months ago
This feature has been asked for in excess of 10 years.
Several duplicate bugs have been logged, showing wide support for the ask.
I see this is moved to unplanned backlog if I understand correctly. It should be a must-fix.
The description field is free-form. Thus,from many different customers and each customer having different users, I see about 20 different ideas about what forms a complete description. And none of them are what we need, which is expressed perfectly in comment #2. The problem is that with B2B deployments, there is no control over what someone enters into redmine and the reduced verbal/human interaction makes this difficult to do.
Although we are using this as a B to B solution, a larger company like IBM would experience similar issues with a geographically diverse set of users with different styles.
Trackers/Projects tend to have the same types of issues. The ask is only for including per project so it is only used when necessary. And putting a concise template per tracker will not hurt search- it will help.
Some misconceptions in the processing by the Redmine team:
-The conception that a company internal discussion can solve consistency issues in the description field. Not only do project-internal groups vary in size and location from case to case (sometimes different time zones), the whole reason for web forms with mandatory fields is to ensure consistency. This field - the most important one - has no way to do that today. Forms are meant to ensure minimum necessary information in the absence of a human being present.
-The conception that Template text will fill the Redmine description database with identical template text. This is not true, templates are meant to be replaced with the text they template. As an example:
A [Problem your business is experiencing]
1 [1st step to reproduce]
2 [2nd step to reproduce]
Expected Result:[what you expected to see]
Most of this text is replaced with wording specific to the problem as suggested by the use of brackets.
My team wastes literally 100 hours a month due to inconsistency in problem reporting from our customers. We have increased the # of mandatory and custom fields, but there is no way to create a set of custom fields to handle a 1 to N set of problem steps. This MUST be done with templates.
This was as much a must-fix 10 years ago as it is today.
#43 Updated by Yuuki NARA 6 months ago
Can you solve it by using the following plug-in?
This plugin is very popular among Japanese Redmine users.
#44 Updated by Greg Christopher 3 months ago
Sorry for the late reply- of course that plugin should work.
The issue is that our redmine instance is cloud hosted. We are negotiating with the providers to see if we can get it added, thank you.
The cloud hosting situation underscores why it's important that this feature be available by default. Not everyone has the freedom to add plugins.
#45 Updated by Akiko Takano about 1 month ago
Hi, thanks for all and all the contributions to the long-term success of Redmine.
I maintain the small plugin mentioned above, but personally I would be very happy if this feature was implemented in Redmine itself :)
Recently, I added an experimental feature in the latest version that sets the core fields and custom fields as well as descriptions.
But I don't know if this feature will meet everyone's needs.
Could you try out the new features of this plugin if interests?
I'm glad if everyone finds it really worth it and would like to send more detailed feedback and patches to Redmine instead of the plugin.