Yvan MICHEL
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
Chaque plugin ou module doit disposer de son propre projet Redmine. Cela garantit une gestion claire, un historique propre et une meilleure traçabilité.
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.
Règle n°5
La description doit contenir toutes les informations utiles au traitement du ticket :
- Détail de la demande ou du problème, et son contexte,
- Description :
- Pour un bug : les étapes pour reproduire l’anomalie,
- Pour une demande d’amélioration ou d’évolution : le résultat attendu avec si possible des captures d’écrans
- Exemples de données de test,
- Environnement concerné, et si besoin url d’accès/comptes de test pour tester sur cet environnement,
- Liste des Plugins et modules dépendants,
- Fichier pom.xml associé,
- Précision sur le périmètre : Front-Office, Back-Office ou les deux.
Règle n°6
L’illustration de la demande par des captures d’écran ou des fichiers de logs est indispensable, en particulier pour les anomalies.
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 doit commencer par l’identifiant du ticket Redmine concerné (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 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…).