L’évolution de GitHub Issues (aperçu public)

• Diverses améliorations ont été dévoilées, dont les sous-issues, les types d’issue et la recherche d’issues

Gérer les issues de manière plus détaillée avec les sous-issues

• Les sous-issues permettent de découper et d’organiser les issues selon une hiérarchie parent-enfant
• Il est possible de créer des sous-issues à partir de n’importe quelle issue, et d’utiliser une structure imbriquée pour suivre l’avancement et identifier le travail restant
• Il est facile de suivre la progression des sous-issues dans les projets

Organiser le travail avec les types d’issue

• Les types d’issue permettent de classer et gérer les issues avec un langage commun partagé entre tous les dépôts d’une organisation
• Cela permet de voir rapidement l’avancement du backlog de bugs, de retrouver toutes les initiatives de haut niveau sur lesquelles l’équipe travaille et de mieux comprendre la classification du travail dans un projet

Trouver exactement ce que l’on cherche avec la recherche avancée

• Sur la page des issues d’un dépôt, il est possible de construire une recherche avancée avec les mots-clés AND et OR, ainsi que des parenthèses pour les recherches imbriquées
• Il devient possible de construire des filtres plus complexes afin de trouver précisément l’ensemble d’issues recherché

Mise à jour de l’interface des issues

• Une nouvelle barre de filtre avec autocomplétion et coloration syntaxique a été ajoutée à la page d’index des issues
• La création de plusieurs issues est plus rapide grâce à l’option « Create More », qui permet de revenir rapidement à l’écran de création
• Les formulaires et modèles d’issue, affichés par ordre alphabétique selon le nom de fichier, peuvent être configurés plus facilement dans l’ordre souhaité
• Un nouveau bouton « Copy Link » permet de partager facilement l’URL d’une issue
• Pour les longues issues, l’option « Load More » charge désormais 150 événements au lieu de 50

Augmentation du nombre d’éléments dans les projets GitHub

• Auparavant, une bêta privée avait été annoncée pour augmenter la limite d’éléments par projet de 1 200 à 50 000
• Aujourd’hui, cette limite augmentée est étendue à davantage de cas
• Depuis la bêta privée, la prise en charge des slices, des swimlanes et de l’API GraphQL a été ajoutée, des rapports de bugs prioritaires ont été corrigés et les performances ont été améliorées
• Si vous êtes administrateur de projet et que votre projet approche de la limite d’éléments sans utiliser les insights — la seule fonctionnalité qui n’est pas encore prise en charge — une bannière s’affichera en haut du projet
• Cette mise à jour s’applique par projet, et non par organisation ; il est donc possible de participer en cliquant sur le bouton « Join Waitlist » dans les projets éligibles

Avis de GN⁺

• Cette mise à jour semble faire franchir une étape supplémentaire aux outils classiques de suivi d’issues et pourrait grandement améliorer la collaboration des équipes de développement logiciel
• L’utilisation de sous-issues présente l’avantage de détailler le travail tout en facilitant la compréhension de l’avancement global, mais une hiérarchie trop profonde peut au contraire nuire à la lisibilité
• La possibilité de définir des types d’issue afin de gérer les issues avec un langage unifié au sein de l’organisation est particulièrement notable. Cela devrait améliorer la communication et la compréhension entre équipes
• La recherche avancée sera utile pour retrouver rapidement l’information souhaitée parmi un grand volume d’issues. Toutefois, il faudra au préalable former les utilisateurs à la rédaction de requêtes complexes
• Le relèvement de la limite d’éléments de projet devrait être d’une grande aide pour la gestion de projets de grande ampleur. Cependant, il n’est pas souhaitable de regrouper trop d’éléments dans un seul projet

[GN⁺]

Avis Hacker News

• Le plus gros point faible de GitHub Issues est que, lorsqu’on visite une page d’issue, le rapport d’origine est affiché comme contenu principal

  • Il est possible qu’on ne comprenne pas encore le vrai problème et qu’on ne décrive que les symptômes
  • Il est possible que l’auteur initial ne sache pas bien rédiger un rapport de bug
  • Il se peut qu’une issue reste ouverte parce qu’un détail mineur n’a pas été résolu, même après la résolution du problème principal
  • Il serait utile d’avoir, en haut de la page, un espace expliquant la compréhension actuelle du problème et son état

• J’avais envie d’utiliser GitHub Issues, mais je suis déçu de le voir devenir plus complexe

  • J’ai peur qu’il finisse aussi complexe qu’ADO, Jira ou Asana

• Si les Issues étaient limitées aux mainteneurs du dépôt, il serait plus facile de contribuer aux projets FLOSS

  • Aujourd’hui, le focus se dilue à cause des demandes de support, des suggestions et des discussions
  • La « jirafication » des Issues ne m’intéresse pas

• J’ai conçu la dernière grande mise à jour de GitHub Issues il y a 10 ans, et j’en attendais davantage

  • Ça donne l’impression d’un développement à coups de cases à cocher
  • Il y a du React dedans

• Il faudrait ajouter des statuts comme "closed - duplicate", "closed - won’t fix", "our bot closed this because no one commented on it for 6 weeks"

  • Quand on trouve un problème, il est souvent déjà fermé, ce qui est frustrant

• Je ne comprends pas les réactions négatives

  • Pour les utilisateurs en entreprise, c’est une excellente mise à niveau
  • C’est simplement une mise à niveau pour rattraper GitLab Issue ou Linear

• Il y a déjà des labels, donc je ne vois pas bien à quoi sert le type d’issue

• Ajouter plusieurs problèmes dans les commentaires d’une issue les rend difficiles à suivre

  • Il existe un moyen d’ajouter des cases à cocher [ ], mais on ne sait pas clairement qui a terminé quoi
  • Il y a aussi la possibilité d’ajouter des commentaires de review à la pull request du code, mais on ne peut pas indiquer la personne assignée

• Le plus gros problème de GitHub Issues, c’est que les grands projets open source ne peuvent pas facilement mettre en avant les issues prioritaires

  • Une modération agressive est possible, mais elle risque de créer de l’anxiété chez l’auteur de l’issue
  • Il faut un moyen de distinguer le backlog de ce qui est réellement à faire

• J’aimais bien la refonte des listes de tâches que j’avais utilisée par le passé

  • J’appréciais cette approche organique de la gestion de projet
  • J’ai été déçu de voir cela remplacé par des sous-tâches explicites