Utilisation des issues

bastienrobert/la-ferme/issues

Lexique

• Repository (ou repo): contient tout le code et le versionne : il est toujours possible de consulter l'historique d'un fichier pour consulter les modifications qui ont été apportées. Sur Github, les issues et les projects y sont directement rattaché.
• Issue : ticket.
• Project : outil de gestion de projet automatisé, en Kanban.

Pourquoi ?

Pour écrire une nouvelle fonctionnalité ou pour corriger un bug. Un ticket permet de lancer une discussion et de suivre son évolution facilement.

Comment ?

Pour rajouter un ticket, il suffit d'aller dans l'onglet "issues" sur le repo.

Les issues doivent être écrites en Français.

Le markdown

Le langage utilisé pour écrire une issue s'appelle le Markdown. Il sert uniquement à formatter du texte et est très simple à appréhender. Une cheat-sheet explique les différents caractères simples qui permettront d'ajouter des titres, de mettre en gras ou encore d'insérer des liens.

Pour ajouter une image sur Github, il suffit de la glisser dans la zone de texte.

Être pertinent

• Écrire un titre clair qui permette d’identifier rapidement le problème
• Écrire une description la plus détaillée possible, qui donne le contexte et décrit bien le problème. Dans l’idéal, il faudrait renseigner (quand c’est pertinent) :
  • le nom et la version du navigateur utilisé ou du téléphone et de la version de son OS
  • l’intention initiale
  • ce que vous avez fait (les étapes permettant de reproduire le problème)
  • le résultat obtenu
  • le résultat qui était attendu
  • une ou plusieurs captures d’écran qui illustrent le problème
• Dans la cas d’une nouvelle feature, préciser le raisonnement si besoin
• Ne pas faire d’issues “fourre-tout” qui contiennent plusieurs problèmes : faire une issue par problème
• Noter, si besoin, dans la colonne de droite :
  • La ou les personnes concernés par le ticket (ils seront notifiés par mail)
  • Les labels (cf. Liste des labels)
  • Le project concerné (Bug report si c'est un bug)
  • Le milestone (sprint)

Liste des labels

Labels indispensables

Pour chaque nouvelle issue, merci de préciser :

• package:* : Le paquet concerné (mobile, serveur ou composant)
• priority:* : La priorisation du ticket (low, medium ou high)

Labels communs

• Design : Problème qui ne concerne pas une fonctionnalité mais du layout
• Critic : Bug urgent à traiter en priorité
• Bug : Bug à traiter
• Accessibility : Concerne l'accessibilité
• Duplicate : Une autre issue à ce sujet existe déjà (penser à référencer l'issue en question en commentaire avant de la fermer)
• Feature : Nouvelle fonctionnalité
• Invalid : Ticket non viable en l'état
• Question : Plus d'informations demandées
• Wontfix : Ne sera pas traité

Labels développeurs

• Documentation : Documentation manquante ou incomplète
• Test : Les tests unitaires/fonctionnels sont manquants
• Chore : A propos de l'architecture de l'application ou des environnements. Ne concerne pas de code utile en prod