Pourquoi les utilisateurs ne peuvent pas créer eux-mêmes des issues

• Dans le dépôt Ghostty, les utilisateurs ne peuvent pas créer directement des issues et doivent d’abord lancer une discussion dans les GitHub Discussions
• Le projet n’utilise pas le tracker d’issues pour discuter des bugs ou des demandes de fonctionnalités ; toutes les discussions se déroulent dans Discussions
• Lorsqu’une discussion est suffisamment précisée pour devenir un élément exploitable, un mainteneur la convertit en issue
• Cette méthode constitue une structure qui aide les mainteneurs et les contributeurs à repérer rapidement les issues réellement exploitables
• Comme la plupart des signalements concernent des problèmes d’environnement utilisateur, des malentendus ou des demandes de fonctionnalités non implémentées, cette procédure est importante pour la gestion de la qualité du projet

---

Politique de restriction de création d’issues

• Dans le dépôt Ghostty, les utilisateurs ne peuvent pas créer eux-mêmes des issues
  • Ils doivent d’abord partager leur problème ou leur proposition dans les GitHub Discussions
  • Si un mainteneur examine la discussion et confirme qu’il s’agit d’un problème clairement reproductible, elle est convertie en issue
• Cette méthode sert à faire en sorte que le tracker d’issues ne contienne que des éléments réellement exploitables
  • Comme toutes les issues sont déjà concrétisées, les contributeurs peuvent commencer à travailler immédiatement

Principes de fonctionnement du tracker d’issues

• Ghostty n’utilise pas le tracker d’issues pour les débats ni pour les demandes de fonctionnalités
  • Les demandes de fonctionnalités et les questions générales sont traitées dans Discussions
  • Les issues ne contiennent que des bugs clairement définis ou des tâches directement exploitables
• Cette approche est un principe de fonctionnement construit à partir de l’expérience de maintenance de projets open source
  • D’après l’expérience passée, 80 à 90 % des signalements utilisateurs n’étaient pas de vrais bugs, mais des malentendus ou des problèmes d’environnement
  • La plupart du reste correspondait à des demandes de fonctionnalités non implémentées, qui nécessitaient souvent des spécifications supplémentaires

Amélioration de l’efficacité de maintenance

• En passant par l’étape Discussions, les mainteneurs peuvent ne gérer sous forme d’issues que les problèmes validés
  • Cela réduit les doublons inutiles et les faux rapports de bugs
  • La liste des issues reste centrée sur des éléments immédiatement exploitables
• Les utilisateurs n’ont pas de travail supplémentaire à faire même s’ils ont identifié un problème valable
  • Un mainteneur le convertit directement en issue et le prend en charge

Document de référence

• La procédure détaillée et les consignes de contribution sont disponibles dans le fichier CONTRIBUTING.md
• Ce document précise la manière de participer aux Discussions et les critères de conversion en issue

[GN⁺]

Réactions sur Hacker News

• Tout à fait d’accord. Quand il s’agit du projet de quelqu’un d’autre, le pouvoir de décider ce qui mérite d’être un ticket lui appartient entièrement
  Plus le projet est gros, plus on voit de gens qui ne lisent pas les messages, qui font des demandes absurdes, voire qui gonflent des CVE avec l’IA

  • Je ne comprendrai jamais les gens qui ne lisent pas les messages d’erreur
    Même si l’utilisateur ne comprend pas leur signification, il doit au moins dire quel message d’erreur est apparu
    Je me souviens d’un test où j’avais indiqué explicitement une “broken pipe error”, et l’ingénieur a fermé le ticket comme “impossible à reproduire”, avant de dire que c’était justement cette même erreur qui empêchait la reproduction
  • Github Issues a des limites comme bug tracker
    La plupart des trackers permettent des états comme “unconfirmed”, alors que GitHub est un simple système de discussion, donc difficile à gérer
  • J’ai déjà reçu un rapport CVE juste après la sortie de ChatGPT
    J’ai passé 4 heures à réfuter point par point avec du code et des preuves, et la seule réponse a été “shrugs AI”
  • Beaucoup d’utilisateurs veulent juste le résultat sans prendre le temps d’apprendre à utiliser correctement l’outil
    La “Facebookization” a créé l’idée que quelques clics suffisent, et avec la “LLMization”, ça risque d’empirer
    Cette approche ne convient pas aux logiciels spécialisés, mais les attentes sont déjà formatées ainsi
  • Un bon issue tracker devrait avoir des fonctions pour filtrer ce bruit
    Le fait que Ghostty classe les demandes via des discussions est une approche originale mais efficace

• L’enquête sur la fuite mémoire est dispersée sur plusieurs plateformes
  Lien X 1, Lien X 2, Discussion 1, Discussion 2
  Ce n’est toujours pas passé au rang d’issue officiel

  • J’ai fini par abandonner Ghostty à cause de la fuite mémoire
    Même sur un système avec 8 Go, lancer le terminal quelques fois suffisait à provoquer un manque de mémoire
    Foot avait moins de fonctionnalités, mais était bien plus stable
  • D’après le premier lien, l’auteur dit que ce problème n’a été signalé que deux fois
    Le deuxième lien ressemble juste à une tentative de polémique
  • J’ai moi aussi signalé ce problème dans une discussion, mais je n’ai eu aucune réponse
    J’ai temporairement corrigé le souci en analysant les logs avec Claude Code, et maintenant je n’arrive à le reproduire qu’une fois sur dix
    J’espère que ça aidera quelqu’un si une enquête plus poussée est menée
  • La compatibilité GPU est aussi délicate
    Il y a des problèmes même avec des GPU intégrés, mais c’est toujours mis sur le dos de GTK ou de Nvidia
  • Les contributeurs semblent avoir jugé qu’il manque encore des conditions de reproduction claires pour en faire une issue

• Je trouve la distinction entre “Issues” et “Discussions” inefficace
  Il faut faire des recherches en double, et on ne peut pas déplacer les tickets
  Si on fait le suivi par e-mail, on perd les notifications
  C’est pour ça que j’ai désactivé Discussions dans mon projet

  • Discussions est utile comme espace pour les questions simples ou les problèmes d’installation
    Si c’est un vrai bug, on peut alors le convertir en issue
  • Ce genre de processus peut aussi se faire avec un système de labels
    Il suffit qu’un administrateur ajoute le label “bug”
  • Pas besoin de vérifier les doublons
    Une fois la discussion clarifiée, on peut créer l’issue à ce moment-là
  • En réalité, les issues et les discussions peuvent être converties l’une en l’autre
    Les notifications sont aussi conservées
  • Comme dans la structure de Ghostty, le fait que tout le monde puisse ouvrir des Discussions, tandis que les Issues sont gérées par les mainteneurs, me semble une séparation raisonnable

• Certains grands projets de la communauté Python utilisent aussi cette méthode
  Mais du point de vue d’un power user, le processus de signalement de bug est pénible
  L’attitude qui donne l’impression de dire “notre projet est parfait” paraît arrogante

  • J’ai du mal à comprendre ce reproche
    La plupart des drive-by bug reports ne servent à rien et ne font qu’ajouter du bruit
    Si l’on veut vraiment contribuer, il vaut mieux corriger un bug déjà défini
  • Arrogants ? Au contraire, ce sont des gens qui donnent gratuitement de leur temps et de leurs efforts
    Il est normal qu’ils imposent des limites sur la manière de signaler
  • Si vous trouvez des bugs aussi souvent, vous pourriez aussi participer directement au projet
  • À l’inverse, être convaincu que “c’est évidemment un bug” peut aussi relever d’une certaine arrogance
  • Ouvrir une discussion est vraiment plus pénible qu’ouvrir une issue ? Je ne sais pas

• À propos de l’idée selon laquelle toutes les issues doivent être prêtes à être traitées,
  quelqu’un a demandé : “dans ce cas, pourquoi ne pas mettre un tag ‘ready-to-be-worked-on’ ?”

  • Mais GitHub ne permet pas de définir la vue par défaut sur “triage”, et dans les gros projets, la gestion des issues est inefficace
    Ce système a été bien plus efficace
  • L’approche par tags demande plusieurs allers-retours de feedback, et les détails se retrouvent dispersés dans les commentaires
  • Si tout le monde peut commenter, cela crée du bruit inutile
    C’est pour cela qu’ils ont séparé l’espace des développeurs et celui des utilisateurs
  • Même si on ferme les mauvaises issues, elles peuvent être rouvertes, donc au final la liste des issues devient ingérable
  • Il n’y a pas lieu d’imposer à la workflow de quelqu’un d’autre l’idée que “ma façon est meilleure”

• Les Issues deviennent ingérables quand l’échelle augmente
  Utiliser Discussions comme filtre est efficace

  • Mais au final, les mainteneurs doivent quand même tout lire et tout classer, donc la charge de travail est similaire
    Les deux fonctions de GitHub ont presque la même interface
    La différence, c’est que Discussions a une fonction d’upvote
  • Il y a aussi eu une réaction sarcastique du genre : “ce ne serait pas plus efficace de fermer automatiquement toutes les issues après 2 semaines ?”
  • Même un gros projet comme Curl n’a que 5 issues ouvertes
    curl/curl/issues

• Certains pensent aussi que cette méthode devrait être le réglage par défaut
  Une structure où la communauté gère les discussions et les contributeurs les issues serait idéale

  • Mais ce n’est au fond qu’un simple déplacement du processus, le fond reste le même
    Le système de labels de GitHub suffit largement aussi
    Documentation de gestion des labels GitHub
  • Plutôt que de définir un “par défaut”, il vaut mieux que chaque projet expérimente naturellement pour trouver la méthode qui lui convient
    Un peu comme une expérience naturelle

• Je suis d’accord avec cette politique sur les soumissions des utilisateurs
  Quand on regarde les discussions fermées, cela ressemble à des issues fermées, mais au moins ça réduit le bruit dans l’onglet Issues
  Liste des discussions fermées de Ghostty

  • Tous les signalements d’utilisateurs commencent dans Discussions, puis sont déplacés vers Issues s’ils sont confirmés comme de vrais bugs
    Beaucoup de discussions n’arrivent jamais à ce stade, mais les problèmes des utilisateurs sont tout de même résolus
    Je trouve cette séparation assez intelligente

• En réalité, le fait de “ne pas pouvoir ouvrir d’issue” n’est pas une fonction GitHub,
  c’est simplement un message de template disant “n’ouvrez pas de nouvelle issue, utilisez Discussions à la place”

• J’ai déjà vu cette méthode dans d’autres projets,
  et une structure où la discussion sert de point de départ me paraît assez raisonnable
  Beaucoup de projets n’ont toutefois pas encore activé GitHub Discussions

[iolothebard]

Quelle est au juste la différence entre cette discussion et une issue ? Une issue n’est pas un « bug ». Qu’il s’agisse d’un bug, d’une proposition de fonctionnalité, d’une PR… s’il y a matière à discussion, c’est une issue.
S’il n’y a pas matière à discussion, il suffit de la fermer.

[nemorize]

Ce n’est pas parce que les discussions et les issues sont différentes, mais simplement parce que le fait de les séparer en onglets distincts correspondait sans doute mieux à leurs préférences.

Publier à la fois une sorte de todo list et les discussions dans l’onglet des issues, puis les gérer avec des tags
vs
utiliser l’onglet des issues uniquement comme todo list, et les discussions uniquement comme discussions