Nicolas Jouanne
Règles d’utilisation de Redmine
Table des matières
- Règle n°1
- Règle n°2
- Règle n°3
- Règle n°4
- Règle n°5
- Règle n°6
- Règle n°7
- Règle n°8
- Règle n°9
- Règle n°10
- Règle n°11
- Exemple de description
Règle n°1
La demande doit être créée dans le projet Redmine correspondant au plugin ou module concerné. Si plusieurs plugins ou modules sont impliqués, il convient de créer une demande distincte dans chaque projet concerné.
Règle n°2
Le champ “Tracker” doit être sélectionné avec discernement. Le cycle de traitement de la demande peut en effet varier selon le type de tracker choisi.
Règle n°3
Le sujet du ticket doit être court, précis et rédigé exclusivement en anglais. Il doit permettre une identification rapide du contenu du ticket.
Règle n°4
La description du ticket doit être rédigée en anglais et en français avec le préfixe – EN – pour le chapitre en Anglais, et le préfixe – FR – pour le chapitre en Français (voir l’exemple en bas de page).
Règle n°5
La description doit contenir toutes les informations utiles au traitement du ticket :
- Le détail de la demande ou du problème, et son contexte,
- La description :
- Pour un bug : les étapes pour reproduire l’anomalie,
- Pour une demande d’amélioration ou d’évolution : le résultat attendu.
- Des exemples de données de test si besoin,
- L’environnement concerné (recette, production, …) et les urls d’accès à cet environnement,
- Le lien GitHub ou GitLab vers le fichier pom.xml de l’instance concernée,
- Une précision sur le périmètre : Front-Office, Back-Office, ou les 2
Règle n°6
La demande doit être illustrée par des captures d’écran et/ou des fichiers de logs, pour les anomalies, et si besoin des maquettes de l’UI cible ou tout autres descriptifs visuels en cas de demande d’amélioration ou d’évolution.
Règle n°7
Les champs “Priorité” et “Urgence” doivent être renseignés de manière réaliste. L’équipe se réserve le droit de les ajuster si besoin.
Règle n°8
Chaque commit sur Git doit commencer par l’identifiant du ticket Redmine en question (ou plusieurs si le commit concerne plusieurs tâches).
Règle n°9
Les identifiants Redmine mentionnés dans les commits doivent appartenir au même projet que le code source modifié, afin d’assurer leur affichage correct dans le changelog du projet.
Règle n°10
Tout ce qui n’est pas dans Redmine n’existe pas. Une anomalie non déclarée dans Redmine ou mal décrite ne pourra pas être traitée.
Règle n°11
Aucune information sensible ne doit apparaître dans le ticket, que ce soit dans la description, les captures d’écran ou les pièces jointes (ex. : mots de passe, données personnelles…).