Recommandations pour le suivi des problèmes

Ce document décrit la méthode standard de gestion des nouveaux problèmes dans les projets d’UBports. À ne pas confondre avec le guide de rédaction d’un bon rapport de problème.

Où sont suivis les problèmes ?

Étant donné que notre assurance qualité dépend énormément de la communauté, nous essayons de faire le suivi des problèmes là où l’utilisateur irait naturellement, au lieu de le faire séparément pour chaque dépôt. Cela veut dire que les problèmes concernant à peu près tous les composants distribués avec l’image système sont suivis dans le gestionnaire de suivi pour Ubuntu Touch. Les applications Click sont une exception car elles peuvent être mises à jour de façon indépendante via l’OpenStore.

La plupart des autres dépôts font un suivi des problèmes localement. Si vous n’êtes pas sûr(e) de savoir si un dépôt utilise son propre suivi ou non, consultez le fichier README.md. Les dépôts qui ne suivent pas les problèmes localement ont leur système de suivi de problèmes désactivé.

Cette page concerne principalement le système de suivi de problèmes d’Ubuntu Touch, mais la plupart de ces principes s’appliquent de manière similaire aux autres projets.

Note

La pratique l’emporte sur la théorie ! Des exceptions peuvent être justifiées et doivent être décrites dans le fichier README.md des projets.

Les projets GitHub

Pour améliorer transparence et communication, les projets GitHub (tableaux kanban) sont utilisés partout où cela est pertinent du point de vue pratique. Dans le cas de github.com/ubports/ubuntu-touch, un seul projet est utilisé pour tous les suivis de problèmes. Les projets comportent un filtrage par mots-clés, afin que les suivis qui concernent une équipe spécifique ou un matériel spécifique puissent être recherchés et consultés facilement.

Voici les colonnes standards :

  • None (awaiting triage) (Aucun, en attente de tri) : Le problème a été approuvé par un membre de l’équipe de l’assurance qualité et attend une vérification par l’équipe de développement concernée. Si le problème est un bogue, les instructions pour le reproduire sont incluses dans la description du problème. Si le problème est une demande de fonctionnalité, il a passé une première vérification par l’équipe de l’assurance qualité mais n’a pas encore été accepté par l’équipe de développement concernée.
  • Accepted (Accepté) : Le problème a été accepté par l’équipe de développement concernée. Si le problème est un rapport de bogue, l’équipe a décidé qu’il pouvait être corrigé et en accepte la responsabilité. Si le problème est une demande de fonctionnalité, l’équipe pense que celle-ci peut être implémentée telle que décrite.
  • In Development (En développement) : un correctif est en développement. Cela signifie généralement qu’un développeur est assigné à ce problème.
  • Quality Assurance (Assurance qualité) : le correctif est finalisé et a passé les premiers tests. L’équipe de l’assurance qualité va maintenant le tester sur tous les matériels et fournir un retour. Si des dysfonctionnements sont trouvés, le problème est rétrogradé à l’état « Accepted » (Accepté).
  • Release Candidate (Version admissible) : le correctif a passé l’assurance qualité et il est prêt pour la publication. Dans le cas de paquets deb inclus dans l’image système, le correctif sera intégré dans la mise à jour suivante du canal rc, et, si tout se passe bien, dans la version suivante du canal stable.
  • None (removed from the project) (aucun, retiré du projet) : si le problème est ouvert et marqué « help wanted » (aide souhaitée), des contributions de la communauté sont nécessaires pour résoudre le problème. S’il est clos, alors soit un correctif a été fourni sur le canal stable (un commentaire sur le problème devrait alors être joint au correctif), soit le problème a été rejeté (marqué « wontfix » : ne sera pas corrigé).

Mots-clés

Tous les problèmes - même ceux qui sont clos - devraient être étiquetés pour permettre l’utilisation du filtrage global de GitHub. Par exemple, voici tous les problèmes étiquetés « enhancement » (amélioration) dans @ubports. Consulter les pages d’aide de GitHub pour plus d’informations sur les recherches et le filtrage.

Voici une liste des mots-clés qui sont normalement utilisés par tous les dépôts.

  • needs confirmation (confirmation nécessaire) : le problème demande une confirmation et / ou un complément d’information par les utilisateurs concernés.
  • bug (bogue) : ce problème est confirmé être un bogue. S’il est reproductible, les étapes nécessaires à sa reproduction sont décrites.
  • opinion (opinion) : ce problème nécessite une discussion plus importante.
  • enhancement (amélioration) : ce problème est une demande de fonctionnalité.
  • question (question) : ce problème est une demande de support ou une question d’ordre général.
  • invalid (invalide) : ce problème ne peut être confirmé ou a été signalé au mauvais endroit.
  • duplicate (doublon) : ceci a déjà été signalé à un autre endroit. Veuillez fournir un lien et clôturer.
  • help wanted (aide recherchée) : ce problème peut être pris en charge par un développeur de la communauté.
  • good first issue (bon premier problème) : ce problème n’est pas critique et est relativement facile à corriger. Il est réservé aux nouveaux contributeurs pour démarrer.
  • wontfix (ne sera pas corrigé) : il est inutile de corriger ce problème car il se résoudra sûrement de lui-même ; ce problème demande beaucoup trop de travail ; ce problème n’est pas réparable ou un composant d’une couche inférieure changera bientôt.

Des mots-clés spéciaux supplémentaires peuvent être définis. À titre d’exemple, voici les mots-clés utilisés dans le suivi d’Ubuntu Touch :

  • critical (devel) (critique, développement) : ce problème critique qui ne se produit que sur le canal développement bloque la publication de l’image de la version admissible suivante.
  • critical (rc) (critique, version admissible) : ce problème critique qui ne se produit que sur les canaux développement et version admissible bloque la publication de la version stable suivante. Sont généralement étiquetés de cette manière les problèmes qui ne peuvent simplement être déplacés vers une version différente et ont le pouvoir de retarder la publication.
  • device: [DEVICE CODENAME] (appareil : [NOM DE CODE]) : ce problème ne touche que le ou les appareil(s) spécifié(s).
  • team: [TEAM NAME] (équipe : [NOM DE L’ÉQUIPE]) : ce problème concerne une équipe spécifique (hal, middleware, UI).

Note

Si un dépôt qui suit des problèmes localement définit ses propres mots-clés, ils doivent être documentés dans le fichier README.md.

Jalons

Les jalons (milestones) sont utilisées pour les versions stables OTA seulement. En général, les étapes sont définies pour la version OTA en cours et la suivante. La date estimée d’arrivée est déterminée dès qu’on commence à travailler sur la version (dans les 6 semaines à partir de la date de démarrage), mais peut être modifiée après coup. Consultez le planning de publication pour plus d’informations.

Cessionnaires

Pour voir de façon claire qui travaille sur un problème, le développeur doit être assigné à cette tâche. Cela permet l’utilisation du système de filtrage global de GitHub comme une sorte de liste de choses à faire. Par exemple, voici tout ce qui est assigné à mariogrip dans @ubports.

On demande aux développeurs de veiller à garder une liste courte et de mettre régulièrement à jour le statut de leur différentes tâches.

Exemples

Le cycle de vie d’un problème

Note

Le même principe s’applique pour les demandes de fonctionnalité. La seule différence est qu’à la place du mot-clé bug (bogue), le mot-clé enhancement (amélioration) est utilisé. Le mot-clé needs confirmation (demande confirmation) n’est pas applicable dans le cas des demandes de fonctionnalité.

  • Un Utilisateur poste un nouveau problème en utilisant le modèle de suivi de problème.
  • L’équipe de l’assurance qualité ajoute le mot-clé needs confirmation (demande confirmation) et essaye de travailler de concert avec l’utilisateur pour confirmer le problème et ajouter les éventuelles informations manquantes au rapport. Une fois que le rapport est complet un team-label (étiquette d’équipe) sera ajouté au suivi du problème et il sera mis sur la liste d’attente de tri du projet (awaiting-triage-list). De plus le mot-clé needs confirmation sera remplacé par bug (bogue).
  • L”équipe dédiée effectuera un tri du problème, à la suite duquel le problème sera soit rejeté (c’est à dire marqué wontfix : ne sera pas corrigé, puis fermé et retiré du projet) soit accepté pour correction. L’équipe décide si le problème sera corrigé en interne (statut passé en « accepted » : accepté, et affecté à un membre de l’équipe) ou si elle attend qu’un membre de la communauté de développeurs le prenne en charge (statut passé en help wanted : aide souhaitée, dans ce cas le problème est retiré du tableau du projet tout en fournissant des indications sur la méthode de résolution et en fournissant si nécessaire des détails sur l’implémentation du correctif). Pour des problèmes non critiques qui sont évidents à résoudre, le mot-clé good first issue (bon premier problème) peut également être ajouté.
  • Une fois qu’un développeur est assigné et commence à travailler sur le problème, celui-ci est déplacé dans « In Development » (En développement). Dès qu’une solution est disponible, le problème est déplacé dans « Quality Assurance » (Assurance Qualité) pour obtenir un retour. Si c’est nécessaire, le développeur peut fournir des pistes sur la façon de tester son correctif dans un commentaire sur le problème.
  • L’équipe de l’assurance qualité teste le correctif sur tous les appareils et fournit un retour au développeur. Si des problèmes sont trouvés, le problème retourne dans « Accepted » (Accepté), sinon il est déplacé dans « Release Candidate » (Version Candidate) pour être intégré dans la prochaine version.
  • Si ce n’est pas déjà fait, le problème est ajouté dans le prochain jalon. Une fois le jalon franchi, le problème est retiré du tableau de suivi du projet.