Règles d'utilisation de JIRA
Règle n°1 : Tout plugin ou module doit avoir son propre projet dans JIRA
Règle n°2 : Le fichier POM du plugin ou du module doit déclarer les propriétés jiraProjectName et jiraComponentId (avec ses propres valeurs ! pas de copier-coller)
<!-- pom.xml --> <properties> <jiraProjectName>PROJECTKEY</jiraProjectName> <jiraComponentId>12...</jiraComponentId> ... </properties>
Règle n°3 : Toutes les fiches doivent être écrites en anglais.
Règle n°4 : Le champ Fix version/s est OBLIGATOIRE dès la création de la fiche (sinon l'anomalie n'apparait pas dans la roadmap)
Règle n°5 : Les champs Type et Priority doivent être sélectionnés avec beaucoup d'attention et de rigueur. Il est par exemple important de voir dans le changelog qu'un bug critique ou bloquant a été corrigé dans une version donnée.
Règle n°6 : Il est fortement recommandé de saisir les champs Affects Version/s et Description. Une copie d'écran ou une pile d'erreur (Stack Trace) sont souvent les bienvenues.
Règle n°7 : Tout commit doit comporter un identifiant JIRA dans son message (voire plusieurs dans certaines conditions). Exceptions : formatter:format, license:format.
Règle n°8 : Les identifiants JIRA mis dans les commits doivent correspondre au même projet que les sources commités (pour que les modifications apparaissent dans le changelog du projet)
Règle n°9 : Les releases des versions dans JIRA doivent être toujours synchronisées avec le repository Maven
Règle n°10 : Tout ce qui n'est pas dans JIRA n'existe pas ! Toute anomalie ne figurant pas ou étant incorrectement saisie dans JIRA n'est pas supposée être prise en compte.
Règle n°11 : Aucune information à caractère sensible (mots de passe, informations nominatives, ...) ne doit être fourni dans la description, les copies d'écran ou les pièces jointes d'une anomalie.