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 ?

Since our quality assurance depends heavily on the community, we try to track issues where the user would expect them, instead of separated by repository. This means, that issues of almost all components that are distributed as with the system-image are tracked in the Ubuntu Touch tracker. An exception of this are click-apps that can be updated independently through the 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

To increase transparency and communication, GitHub projects (Kanban-Boards) are used wherever practical. In case of github.com/ubports/ubuntu-touch, a single project is used for all issues. Projects support filtering by labels, so that only issues that belong to a specific team or affect a specific device can be viewed.

Voici les colonnes standards :

  • None (awaiting triage): The issue has been approved by a member of the QA team and is awaiting review from the responsible development team. if the issue is a bug, instructions to reproduce are included in the issue description. if the issue is a feature request, it has passed a primary sanity check by the qa-team but has not yet been accepted by the responsible development-team.
  • Accepted: The issue has been accepted by the responsible development-team. If the issue is a bugreport, the team has decided that it should be fixable and accepts the responsibility. If the issue is a feature request, the team thinks it should be implemented as described.
  • 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: This issue is a confirmed bug. If it’s reproducible, reproduction steps are described.
  • 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é.
  • Once a developer is assigned and starts working on the issue, it is moved to “In Development”. As soon as they have something to show for, the issue is closed and automatically moved to “Quality Assurance” for feedback from the QA team. If necessary, the developer will provide hints on how to test his patch in a comment on the issue.
  • 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.