Triage des problèmes

Cette page est écrite pour les personnes aidant à trier les problèmes sur le traqueur de problèmes Github.

Préambule

• Tout projet a des ressources limitées, la différence entre les projets sera le seuil.
• Tout projet doit avoir des objectifs clairs. Pour Ansel, c’est gérer, éditer et exporter des collections d’images RAW sur un ordinateur de bureau par un utilisateur final qui n’est pas un utilisateur CLI mais qui met la qualité visuelle de l’image au-dessus de tout.
• Tout projet a des frais généraux, qui sont des actions demandées pour atteindre les objectifs, bien qu’ils ne soient pas directement l’objectif et doivent donc rester minimaux. Pour Ansel, c’est la maintenance du site Web, la documentation, les serveurs, les packages construits quotidiennement, le nettoyage du code, le débogage, les tests de régression, le support multi-OS, le tri des problèmes, etc.
• Les objectifs et les frais généraux doivent être exprimés en termes de tâches à effectuer pour résoudre des problèmes (problèmes). S’il n’y a pas de problème à résoudre, alors pas de travail à faire : le statu quo est très bien aussi, ne créez pas de travail pour le plaisir.
• en raison de la limitation des ressources, les tâches doivent être ordonnées en fonction de leur priorité.

Le document suivant vise à définir cette priorité.

Ansel a été forké sur Darktable car Darktable n’a pas d’objectif clair, pas de gestion des priorités, et les frais généraux augmentent chaque année, ce qui est le marqueur des usines de burn-out et est insoutenable à moyen terme.

Définir de bons problèmes

La gestion de projet fonctionne mieux avec des tâches SMART. S.M.A.R.T. signifie :

• Spécifique (ex : trouver l’URI des images exportées par Ansel sur le système de fichiers et les ouvrir)
• Mesurable (ex : nombre de clics/étapes nécessaires, temps CPU pour effectuer la tâche sur une plateforme cible)
• Actionnable/Réalisable (ex : peut être intégré dans la base de code actuelle avec seulement quelques réécritures mineures, nécessite seulement quelques centaines de lignes de code)
• Pertinent/Raisonnable (ex : fait partie d’un flux de travail photographique assez général, serait utilisé par une partie significative des utilisateurs)
• Limité dans le temps (ex : nécessite au maximum 70 heures-homme).

Un bon problème est celui qui conduit à une tâche SMART. Pour Ansel, cela signifie des problèmes se concentrant sur un problème clairement défini affectant une étape clairement définie du flux de travail d’édition d’image (“J’ai des difficultés à faire X parce que Y et je voudrais Z”).

Les questions et discussions générales doivent se faire sur https://community.ansel.photos.

Les mauvais problèmes sont :

• trop larges (“automatiser le flux de travail”, “améliorer l’UX”),
• se concentrant sur les moyens (“utiliser un réseau neuronal”, “étendre la courbe de tonalité”) au lieu de l’objectif (“masquer le ciel”, “contrôler la saturation de manière sélective”),
• hors scope (“porter sur Android”, “passer à Qt”, “passer à Vulkan”)
• affectant des bibliothèques/projets tiers (Rawspeed, Libraw, Exiv2, Lensfun, GPhoto2, Gtk, etc.),
• trop subjectifs (“veuillez faire les choses comme cet autre logiciel que j’ai utilisé dans le passé et que j’aime beaucoup”). Ce qu’utilisateur A aime serait détesté par utilisateur B, nous ne pouvons pas travailler avec ça.

Note de fin : certains problèmes peuvent sembler nécessiter plus de code, alors qu’ils ont réellement besoin d’une meilleure documentation des fonctionnalités actuelles, ou de légères améliorations de l’interface utilisateur (changement des étiquettes, réorganisation des widgets), c’est donc quelque chose à garder à l’esprit avant de tirer sur les armes.

Définir les priorités

Dans un monde idéal, les tâches (alias bons problèmes) seraient ajoutées à la liste de choses à faire de manière linéaire, à mesure que les jalons sont atteints, et leur produit en code serait testé pendant quelques semaines tandis que le code est autrement gelé, jusqu’à ce qu’il soit prouvé que tout tient, auquel cas nous dégèlerons le code et passerons à la tâche suivante dans la liste des choses à faire.

Le problème est que cela implique que tout le monde soit sur le pont pour la phase de test, afin qu’elle ne gèle pas le code trop longtemps. Parce que cela n’arrive pas (les gens prennent des vacances, ont des enfants, déménagent, changent de travail, ont une vie…), nous devons paralléliser le test du produit des tâches précédentes pendant que nous travaillons sur la prochaine, pour être efficaces.

Cela signifie que la liste des tâches à faire n’est pas linéaire et que certaines choses importantes peuvent être ajoutées ou supprimées dynamiquement, en fonction de ce qui se passe. Le problème est alors de déterminer ce qui constitue quelque chose d’assez important pour perturber le planning.

Il n’y a pas de règle définitive ici, donc vous devrez utiliser votre meilleur jugement, mais il y a quelques règles de base :

• quelque chose récemment cassé (une régression) est plus facile à repérer et à réparer plus tôt que plus tard, donc dans le grand schéma des choses, cela pourrait être moins de travail de le faire plus tôt,
• quelque chose qui empêche le logiciel de fonctionner totalement (crash, fichiers de sortie corrompus, perte de données) est suffisamment critique pour prendre le pas sur des améliorations et des corrections plus cosmétiques,
• quelque chose qui impacte un grand nombre d’utilisateurs et pour lequel aucune solution de contournement ne peut être trouvée prendra également le pas.

Au contraire, tout ce qui impacte un petit nombre d’utilisateurs, ou des fonctionnalités secondaires/de niche, ou des désagréments mineurs qui ont des solutions de contournement, ne sont pas suffisamment critiques pour justifier de perturber le planning. Ceux-ci seront ajoutés à la queue selon un mode premier entré/premier sorti.

Ansel a 4 niveaux de priorités, définis en tant que tags de problèmes :

• priorité : critique : Affecte les fonctionnalités de base et principales du logiciel d’une manière qui empêche son fonctionnement total,
• priorité : haute : Affecte les fonctionnalités de base et principales du logiciel d’une manière qui dégrade sévèrement l’utilisabilité,
• priorité : moyenne : Affecte les fonctionnalités de base et principales du logiciel d’une manière qui dégrade légèrement l’utilisabilité (solutions de contournement disponibles),
• priorité : faible : Affecte les fonctionnalités optionnelles et de niche

Définir les jalons

Les paramètres des modules sont sauvegardés sous forme de blobs binaires. Nous traitons cela en manipulant leur taille en bits. Lorsqu’un nouveau paramètre est ajouté, nous devons écrire du code pour gérer la conversion, c’est-à-dire la taille en bits différente du blob de paramètre, et nous augmentons la version interne des paramètres des modules. Aucun code n’est écrit pour la rétrocompatibilité, donc les photos éditées avec des modules plus récents ne peuvent pas être ouvertes dans des modules plus anciens. Les paramètres des modules sont également utilisés dans les styles, les préréglages et les fichiers XMP.

Pour ces raisons, tout problème qui entraînerait l’ajout de paramètres dans les modules (que ce soit les modules de traitement d’image dans le laboratoire, ou les modules de table lumineuse traitant de l’export et des métadonnées) briserait la rétrocompatibilité et doit être planifié pour la prochaine version majeure du logiciel (1.0, 2.0, 3.0, etc.). Cela signifie que seuls les changements d’interface graphique et de comportement sont autorisés au sein d’une même version majeure, et peuvent être planifiés pour la prochaine version mineure (0.1, 0.2, 0.3, puis 1.1, 1.2, 1.3, etc.).

Ansel n’a que 2 jalons à tout moment : la prochaine version mineure et la prochaine version majeure.

Définir la difficulté

La difficulté est directement liée à la quantité de travail requise par une tâche, c’est-à-dire :

• le nombre de lignes de code à écrire,
• le nombre de fichiers à changer,
• la probabilité de casser des fonctionnalités existantes, entraînant un travail de test supplémentaire,
• l’existence de fonctionnalités similaires ou de théories écrites pour réaliser la tâche,
• la surcharge liée à faire en sorte que les changements et les fonctionnalités fonctionnent de manière fiable sur tous les systèmes d’exploitation.

Estimer correctement la difficulté est quelque chose que seul un développeur expérimenté peut faire.

Définir la nature

La nature des problèmes est gérée avec des étiquettes. Nous avons :

• régressions (choses qui fonctionnaient mais ont été cassées par des changements récents),
• bugs (choses qui n’ont jamais fonctionné ces dernières années),
• améliorations (choses à améliorer ou ajouter),
• ne pas corriger (pas un bug, mais un choix de fonctionnalité ou de design ou une nécessité imposée par des dépendances tierces),
• question (ne devrait pas être sur Github, mais sur https://community.ansel.photos),
• doublon (problème déjà signalé),
• peu clair (problème incompréhensible),
• invalide (problème est “mauvais” selon la définition ci-dessus d’un bon problème).

Les priorités sont relatives

Voir https://www.youtube.com/watch?v=8fnfeuoh4s8 . Devoir réparer la voiture pour pouvoir changer l’ampoule de phare est une excellente métaphore de coder sur un logiciel vieux de 12 ans ayant des centaines de milliers de lignes de code écrites par des gens qui ne se parlaient pas et qui ne documentaient pas leurs changements. Réparer la voiture n’est pas prioritaire jusqu’à ce que cela devienne le pré-requis pour réparer le voyant de haute priorité.

Votre travail de triage

En fin de compte, seul un développeur expérimenté sera en mesure de trier les problèmes de manière précise. Mais la raison exige qu’un développeur expérimenté soit employé pour faire des choses que seul un développeur expérimenté peut faire : écrire un code simple pour résoudre efficacement des problèmes techniques nécessitant une certaine théorie et design.

Le compromis est d’avoir des trieurs pour aider à prioriser les problèmes évidents afin que les développeurs n’aient qu’à traiter les problèmes les moins évidents et à se concentrer sur le codage.

1. ne labellez que les problèmes que vous comprenez et pour lesquels vous vous sentez à l’aise pour trier. Vous n’avez pas à tous les faire, c’est bien si vous ne savez pas.
2. pour les problèmes que vous comprenez :
   • attribuez un label de priorité si vous le pouvez,
   • attribuez un label de nature si vous le pouvez,
   • attribuez un jalon si vous le pouvez,
   • fermez immédiatement le problème s’il est invalide ou en doublon.
3. pour les problèmes que vous ne comprenez pas :
   • essayez de poser plus de questions à l’auteur,
   • assurez-vous que les auteurs remplissent toutes les informations pertinentes (OS, matériel, étapes de reproduction des bugs),
4. il vaut mieux ne rien faire que de le faire mal : les problèmes sans étiquettes sont plus faciles à repérer que les problèmes avec de mauvaises étiquettes.
5. n’hésitez pas à organiser des réunions vidéo : mieux vaut s’asseoir ensemble pendant 30 minutes pour avoir une discussion productive et ajuster les décisions que d’échanger des fils interminables de messages inutiles.

Merci !