Utilisation des issues - demarches-simplifiees/demarches-simplifiees.fr GitHub Wiki

Création d'une nouvelle issue

• É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é
  • 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

• Si la remontée vient d'un utilisateur, préciser qui il est (organisme + initiales, numéro de ticket HelpScout...)

• Ne pas faire d’issues “fourre-tout” qui contiennent plusieurs problèmes : faire une issue par problème

• Renseigner les labels qui s'appliquent à l'issue

  • API : concerne notre API
  • a-communiquer : lorsqu'il faut avertir des utilisateurs qui avaient demandé la fonctionnalité / modification (l'issue doit mentionner qui sont les utilisateurs en question)
  • breaking-change : changement brutal (interface, modèle de données ou autre) qui impact la compréhension que les utilisateurs ont de l'outil et sur lequel on doit communiquer
  • bug
  • cleaning : ménage interne de l'application ou du design
  • critique : problème prioritaire impactant la prod à traiter d'urgence
  • design
  • engagement : issue pour laquelle on s'est engagé pour une date précise
  • feature : nouvelle fonctionnalité
  • idea
  • legal : obligation légale
  • nouvelle-ui
  • ops
  • quick-win : se fait rapidement
  • retour-utilisateur
  • sentry : issue pour laquelle on a une issue correspondante dans Sentry
  • sugar
  • tech : modification technique / interne
  • test-manquant

• Noter, si besoin, les personnes à notifier

  • soit le numéro du ticket HelpScout, ex : #231
  • soit le prénom, l'initiale du nom, et l'organisme du demandeur, ex : H. Duflot (DGSE)

• Quand on note les personnes / organisations à notifier, ne pas écrire de données de contact publiques ou des infos trop précises précises qui permettraient d'identifier l'interlocuteur. Noter simplement le nom de l'organisme et éventuellement les initiales de la personne à contacter.

Gestion des issues

• En cas de fermeture d'une issue non résolue, préciser en commentaire la raison de la fermeture.

• Une fois qu'une issue avec le label a-communiquer a été mise en prod, elle se trouve généralement dans la colonne "À communiquer" du project, et il faut alors :

  • prévenir les personnes concernées
  • enlever le tag a-communiquer de l'issue
  • enlever l'issue de la colonne "À communiquer" du project (flèche en haut à droite de la carte, puis "Remove from project")

• Faire une passe régulière sur les issues fermées avec le tag sentry :

  • marquer l'issue de Sentry correspondante comme résolue
  • enlever le tag sentry de l'issue
  • contacter les personnes touchées par le problème (cf. la partie "User" sur Sentry) pour les informer de sa résolution