Un dépôt maintenu le soir ou le week-end peut avoir autant de mal à trier ses demandes qu’un projet d’entreprise. Une régression, une idée de fonctionnalité et une tâche de documentation arrivent dans la même liste. Depuis l’annonce de GitHub du 11 novembre 2026, les dépôts détenus par des comptes personnels peuvent employer les types et champs de tickets pour introduire une distinction plus lisible. L’intérêt se mesure au temps gagné pour choisir la prochaine tâche.
Ce que GitHub a ouvert aux comptes personnels
Le changelog officiel de GitHub annonce la disponibilité générale des types et champs de tickets pour les dépôts appartenant à des comptes personnels. Le réglage se fait dans la section Planning du compte. Les types proposés d’emblée sont Bug, Task et Feature. Du côté des champs, GitHub cite notamment la priorité, l’effort et des dates de début ou de cible. Le mainteneur peut personnaliser ces deux ensembles et rendre certains champs disponibles aux tickets sans type.
Cette distinction change le tri. Un type répond à la question « de quelle sorte de demande s’agit-il ? ». Un champ conserve une information que l’on aimerait comparer entre plusieurs tickets. La priorité, par exemple, peut être haute pour une anomalie et pour une documentation devenue indispensable à la prochaine version. Elle a donc une place distincte du type.
Les interfaces GitHub ont évolué sur plusieurs fronts. Le rôle présenté dans notre article sur le rôle Moderate pour les tickets relève de la modération. La nouveauté de novembre concerne la description des demandes et leur classement au quotidien.
Partir d’un exemple que deux personnes classeraient de la même manière
Imaginons un outil qui transforme des listes en fichiers à imprimer. Un ticket indique que le résultat coupe la dernière ligne lorsque le document tient exactement sur deux pages. Un deuxième propose une option pour modifier la marge. Un troisième demande de vérifier les exemples avant la prochaine version. Les trois types de tickets par défaut suffisent à faire le premier tri.
Essayez ensuite de donner une définition courte à la priorité. Une priorité haute peut signaler qu’une fonction courante est inutilisable et qu’il n’existe pas de solution de contournement simple. Elle peut aussi qualifier une demande attendue pour une livraison identifiée. L’équipe gagne à préciser ces critères dans une phrase que les nouveaux contributeurs peuvent retrouver. Sinon, chacun interprète le même mot selon son urgence du jour.
La question de l’effort est différente. Si les personnes qui contribuent ne connaissent pas assez le code, mieux vaut accepter qu’un ticket reste sans estimation pendant son examen. Une fausse précision coûte du temps lorsqu’il faut corriger toutes les estimations avant de choisir le contenu d’une version.
Un passage sur dix tickets ouverts suffit à tester la méthode. Demandez à deux personnes de classer les mêmes cinq demandes sans se consulter. Quand leurs choix divergent, regardez le texte du ticket et la définition du type. Il manque parfois une reproduction, un objectif ou une formulation qui distingue une correction d’une extension.
Garder les étiquettes qui apportent un autre renseignement
Les étiquettes peuvent encore préciser le composant concerné, la plateforme ou la nécessité d’obtenir des informations. Le type sert alors à poser la nature de la tâche. Une combinaison comme Bug et export rend la demande plus facile à retrouver. Un autre ticket peut porter Feature et export tout en restant visible dans la même vue de composant.
Avant de convertir tout l’historique, gardez un échantillon de tickets fermés qui se lit bien. L’ancienne organisation peut rester utile lorsqu’un utilisateur revient sur une version antérieure. Pour les tickets actifs, créez une vue de tri qui fait apparaître ce qui demande une décision. Une demande sans type, une priorité vide sur un problème confirmé ou une date devenue irréaliste sont de bons points de départ.
Notre article sur le passage de l’idée au prototype avec Replica aborde une étape plus en amont. Quand une idée devient assez concrète pour rejoindre un dépôt, un ticket devrait permettre de dire qui l’utilisera et comment reconnaître un résultat acceptable.
Après quelques semaines, retirez les champs que personne n’utilise pour décider. Gardez ceux qui ont évité un aller-retour ou qui permettent de retrouver une demande oubliée. Ce sont les meilleurs candidats à inscrire dans la méthode du projet.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
