Tuto-:-utiliser-les-issues-pour-signaler-des-bugs.md

@@ -52,7 +52,7 @@ NOM DU MODULE : problème rencontré
 #### >2.2 Ajoutez une description
 La description du bug doit être la plus précise possible. Indiquez bien comment reproduire le bug et n'hésitez pas à copier-coller les messages d'erreurs qui pourraient potentiellement apparaitre.
 
-ATTENTION : cette description sera interprétée en **Markdown**. N'oubliez pas de laisser une ligne vide pour vos retours à la ligne et de vérifier le rendu de vos description dans l'onglet "Preview" ci-dessus (cf. Chapitre 1. Généralités sur Gitlab et points d'attention)
+ATTENTION : cette description sera interprétée en **Markdown**. N'oubliez pas de laisser une ligne vide pour vos retours à la ligne et de vérifier le rendu de vos description dans l'onglet "Preview" (cf. Chapitre 1. Généralités sur Gitlab et points d'attention)
 
 #### >2.3 Assignez un Milestone
 Le Milestone permet d'indiquer la version de l'application à laquelle l'issue fait référence.
@@ -70,7 +70,7 @@ Gitlab offre la possibilité d'assigner plusieurs labels par issue. **Dans notre
 
 **ATTENTION : si vous avez la possibilité de créer ou de supprimer des labels, merci de ne pas le faire et d'utiliser uniquement ceux déjà proposés.**
 
-#### >2.5 Cliquez sur "Submit issue"
+### >3 Cliquez sur "Submit issue"
 Et voilà, l'issue est créée et Gitlab vous montre ce à quoi elle ressemble. Elle apparait maintenant dans la liste des issues.
 
 Vous pouvez modifier votre issue, les milestones et les labels à tout moment. **Merci de ne modifier que vos propres issues**.
@@ -81,8 +81,34 @@ Vous pouvez modifier votre issue, les milestones et les labels à tout moment. *
 
 ## 2.2 - Cas 2 : commenter une issue existante
 
-*Rédaction en cours...*
+Lorsque vous voulez signaler un bug, vous pouvez vérifier si celui-ci n'a pas déjà été signalé. Si c'est le cas, il n'est pas nécessaire de créer une nouvelle issue. En revanche, vous pouvez indiquer que vous rencontrez aussi ce bug, ajouter des précisions sur le bug, ou même indiquer que ce bug ne se produit pas pour vous. Pour ça, vous pouvez commenter une issue.
 
+De même vous pouvez commenter une issue que vous avez vous même ouverte, pour apporter des précisions ou indiquer une évolution. Ça permet de garder une trace de l'évolution des discussions autour d'un bug, sans perte de contenu.
 
+Pour commenter une issue, suivez ces différentes étapes :
 
+### >1 Sélectionnez l'issue à commenter dans la liste
 
+![comment_issue](uploads/cd057ca4fb273439db5ba3d5fb0235be/comment_issue.png)
+
+### >2 Encodez votre commentaire
+
+Comme pour les issues indiquer les commentaires les plus précise possible.
+
+ATTENTION : comme pour les issues, le commentaire sera interprétée en **Markdown**. Vous pouvez vérifier le rendu de votre commentaire dans l'onglet "Preview" (cf. Chapitre 1. Généralités sur Gitlab et points d'attention).
+
+ATTENTION : petit rappel, **il ne faut jamais clore une issue**.
+
+![encode_comment](uploads/e34d94d5e2cd91aa75ebc5a586d6e508/encode_comment.png)
+
+### >3 Postez votre commentaire
+Le commentaire est ajouté à l'issue.
+
+Il est ensuite possible de commenter un commentaire, ou d'ajouter de nouveaux commentaires à une issue.
+
+Les règles doivent simplement toujours être les mêmes :
+* ne modifier que ce qu'on a créé, si c'est vraiment nécessaire.
+* si possible préférer un nouveau commentaire à une modification du texte original.
+* ne jamais clore une issue.
+
+Bons tests !
\ No newline at end of file