Issue description templates
|Target version:||Candidate for next major release|
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 over 9 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 9 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 8 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 almost 7 years ago
- Subject changed from Description templates to Issue description templates
- Category changed from UI to Issues
#7 Updated by Erwin Mueller over 6 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 almost 4 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 3 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 3 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 3 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 over 3 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.
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.