Comment 1 by Sindre Myren, May 1, 2009

Issue 'Template' suggestion:
Also defining default labels would be nice.

And, defining more the one default, so that a bug reporter can add 
different 'types' of issues (or 'Issue Templates'):

Example Templates:
- bug: (some initial labels) (some initial text)
- feature request: (some initial labels) (some initial text)

Possible implementation:
- New types, could be added with a normal 'New Issue' form!

- An special label, 'Template', could be added, working a bit like 
'Featured' work for documentation.

- The normal issue form could get an additional drop-down field 
called 'type', containing all issues marked with the label 
'Template'.

- Choosing a new type, should alter initial labels and, if the text 
field has not been modified by user, change the text field.

Alternative implementation:
- Use the same idea with an extra 'Template' label at the database 
level, but have the Template Issues managed under the Admin tab.

Comment 2 by Loïc d'Anterroches, May 1, 2009

Ok a bit like the GoogleCode templates. The only problem I see is 
that it requires another option when submitting the issue. 

Anyway, you are many requesting a way or another to achieve this 
kind of results. 

I still think that a smart bayes filter/keywords approach to 
automatically set the labels would be better as it would not require 
the need to for the end user to think and would be more flexible on 
the long run. I will need to dig further into this as soon as the 
dev branch is merged.

Comment 3 by Mehdi Kabab, May 1, 2009

As we come to speak of the labels who are automatically added when I 
create a Issue, after updating the Issue labels of a project, when I 
create a new one, InDefero proposed me two default labels who are no 
longer exists.

The GoogleCode approach elegantly solves this problem.

In french, sorry:
Pour illustrer ce commentaire, j'héberge un projet où les 
rapporteurs de bugs sont des utilisateurs lambda, non développeurs 
et non sensibilisé au vocable qui nous est propre. De ce fait, nous 
avons traduit les valeurs et labels de tickets. Lorsqu'un membre du 
projet crée un nouveau ticket, les étiquettes « Type:Defect » et « 
Priority:Medium » sont automatiquement proposées. Hors, ces deux 
étiquettes n'existes plus :)

Il s'agit d'un détail, mais gérer des templates avancés (contenu par 
défaut du champ de description, étiquettes personnalisées proposées 
automatiquement, etc) renforcerait la cohérence et l'usabilité du 
gestionnaire de tickets.

Comment 4 by Armand Abric, May 9, 2009

Je me permet de rajouter mon cailloux à cette suggestion qui me 
semble être une bonne idée (mais je n'ai malheureusement pas le 
vocabulaire suffisant pour le faire en anglais).

Je suis entièrement d'accord avec le fait que cela permettrait à des 
non spécialistes d'utiliser le système avec beaucoup plus de 
facilité.

L'insertion d'un texte par défaut dans le champ 'Description' 
pourrait effectivement donner des informations personnalisés en 
fonction de chaque projet de manière très simple. Mais le problème 
de pré-remplir une zone de saisie de type textarea est que les 
consignes (ou plan conseillé) peuvent-être effacées de manière 
involontaire.
Une autre possibilité (qui me semble meilleure) serait de permettre 
à l'administrateur d'un projet d'ajouter un nouveau bloc 
d'instruction en plus du bloc de texte actuel explicatif (le bloc 
gris), ou de modifier le bloc actuel. Cela libèrerait l'intérieur de 
la zone de saisie, et rendrait le texte permanent. Mais en contre 
partie risque d'alourdir légèrement l'interface.

Comment 5 by William Martin, Jan 2, 2011

This feature has been implemented.
Can close.