Que faire des problèmes abandonnés dans GitHub?
Si quelqu'un ouvre un problème sur GitHub mais que plus d'informations pour reproduire l'erreur sont demandées et jamais fournies, quelle est la procédure normale? Exemple .
Ici, l'auteur déclare que le "nav se casse". Bien que je pense que ce soit corrigé, j'aimerais que Word de l'auteur s'assure que nous parlons de la même chose. Mais parfois, le journaliste du numéro disparaît. Est-ce une bonne pratique/courante de définir une date d'expiration pour les problèmes abandonnés?
Quelque chose comme ces conditions:
- Une question est posée sur la question pour pouvoir la déboguer.
- Plus de 2 à 6 mois se sont écoulés depuis la dernière question/commentaire sans réponse de l'équipe de développement.
- Le bug ne peut pas être reproduit au moment de sa fermeture (pour une raison quelconque, il est possible qu'il ne puisse jamais être reproduit).
- Un avertissement est émis 2 semaines avant sa fermeture.
Que font normalement les projets? Je n'ai rien trouvé sur Google. Aussi, comment pourrais-je documenter cela? Une simple note dans le fichier README.md détaillant les points ci-dessus et un commentaire dans le problème expliquant pourquoi il est fermé suffisent-ils?
Remarque: c'est différent de cette question car le bogue peut toujours être pertinent (ou non), mais il y a un manque d'informations.
C'est un dilemme: vous ne pouvez pas fermer le problème comme "corrigé", car vous ne savez pas réellement si il a été corrigé, ou du moins même si certains le problème a été corrigé , vous ne savez pas vraiment si c'était le problème dont parlait le journaliste. D'un autre côté, vous ne voulez pas laisser un problème qui aurait pu être résolu ouvert, surtout si vous ne pourrez jamais le fermer car vous n'obtiendrez jamais de confirmation.
Donc, vous devriez le fermer, mais probablement pas comme "fixe". Vous pouvez inventer une raison de fermeture personnalisée "peut être corrigée" ou "correction non confirmée" si vous voulez être positif ou "annulé" si vous ne le faites pas. Vous pouvez également simplement dire "impossible de se reproduire" et attendre que le même bug apparaisse pour un journaliste plus réactif.
Cependant, vous ne devez pas dépenser de ressources sur un bogue pour lequel vous ne saurez jamais s'il a été corrigé ou non.
Votre question principale a déjà reçu une réponse, mais vous avez également demandé comment documenter le processus et qui doit également être répondu.
La solution que j'ai vue dans de nombreux projets n'est pas de le mettre dans le fichier README.md du projet, mais dans un fichier spécial contribution README - a README pour les contributeurs). Ce fichier décrit tout ce que vous voulez que les personnes contribuant à votre projet sachent - qu'il s'agisse du code (conventions de dénomination, organisation des modules, etc.) ou du processus (comment écrire des commits, comment gérer les tickets, etc.). Ce fichier peut être un autre .MD fichier dans le projet, ou placé dans un référentiel entièrement différent (afin qu'il puisse être partagé entre tous vos projets). N'oubliez pas de vous y connecter depuis le principal README.md!
Le point de séparer cette information de la principale README est qu'en général seulement une fraction de l'utilisateur du projet y contribue directement. La plupart des utilisateurs n'ont pas besoin de s'ennuyer avec cette information - ils il suffit de savoir ce que fait votre projet et comment l'utiliser, et c'est ce que le principal README devrait contenir. Dans le cas de votre projet, la section contribution est très petite donc il n'encombre pas le principal README - mais si vous documentez tous les workflows que vous voulez que les contributeurs suivent, il ne rentrera plus aussi bien ici ...
Notez que n'importe quel utilisateur peut ouvrir un bogue, donc si vous avez des exigences particulières concernant l'ouverture d'un bogue, vous devez les mettre dans le README principal (essayez de le garder court cependant - contrairement aux contributeurs de code, les rapporteurs de bogues seront probablement moins disposés à aller très loin) étudier et se conformer à vos règles). Cependant, la personne qui corrige réellement le bogue et ferme le ticket (que ce soit vous ou l'un des contributeurs que vous avez confirmé) est un contributeur direct et on peut s'attendre à ce qu'il lise la contribution README - donc le processus de fermeture des tickets lorsque le journaliste ne répond pas doit y être décrit.
J'ai lu cela comme une question plus sur les pratiques concernant la gestion d'un bogue non vérifié (en utilisant le suivi des problèmes de github) qu'autre chose.
Pour moi, c'est une réponse assez simple basée sur d'autres trackers de problèmes que j'ai utilisés. Github ne force personne à utiliser n'importe quel workflow, ce qui le rend très flexible ... et plutôt inutile dans sa configuration par défaut.
En regardant le workflow par défaut de Bugzilla, nous obtenons:
Je vais souligner ici une chose très importante - elle est résolue comme fixée avant qu'il ne soit fermé après avoir été vérifié . Le flux de travail Github de base affiche uniquement les états rouge (ouvert) et vert (fermé).
Ainsi, une approche consiste à utiliser les étiquettes dans Github ( les étiquettes de votre application ) pour essayer d'afficher les informations supplémentaires. Vous pouvez créer une paire d'étiquettes "non vérifiées" et "vérifiées" à appliquer une fois le problème résolu. Notez qu'il ne s'agit que d'une seule approche - si vous effectuez une recherche, vous pouvez trouver des dizaines d'approches différentes de l'utilisation des étiquettes. Ici, la question Comment gérer les problèmes de github pour (priorité, etc.)? résout ce problème.
Vous l'avez corrigé, du point de vue d'un développeur, c'est fait. Fermez le problème sur Github. Apposez-y l'étiquette "non vérifiée". Une fois que quelqu'un familiarisé avec le bogue de la version précédente dit "oui, cela l'a corrigé", vous pouvez changer le libellé en "vérifié". S'ils disent que non, alors vous le rouvrez.
Notez également qu'il existe d'autres états résolus en plus de "fixes". Il y a "wontfix" (le correctif est quelque chose qui ne peut tout simplement pas être fait avec la structure actuelle) et "worksforme" (le bug ne peut pas être reproduit) et "invalide" (vous déposez un bug sur le système d'exploitation, pas les choses de type application).
Je prendrais l'un des deux points de vue, selon mon degré de confiance dans le fait que je parlais de la même chose que le journaliste d'origine:
1) Puisque le reporter n'est plus disponible, estimez que le bug en question signifie ce qu'il a été corrigé. Si cela peut vous aider, joignez des cas de test pour indiquer clairement les échecs que vous avez trouvés. Décrivez en détail sur le rapport de bogue ce que vous avez corrigé et laissez une note comme, "Je crois que c'est ce que signifie" nav breaks ", veuillez rouvrir ou soulever un nouveau bogue si ce n'est pas ce que vous vouliez dire". Marquez le bug comme corrigé.
2) Étant donné que le journaliste n'est plus disponible, estimez que le bogue ne peut pas être (connu pour être) reproduit, car seul le mot du journaliste confirmera qu'il s'agit de la même chose qu'ils ont signalée. Soulever un nouveau bogue pour décrire la chose que vous avez corrigée, pour le mérite de mentionner qu'il a été observé dans les conditions décrites par le journaliste absent, notez à la fois qu'ils peut être des doublons, marquez le nouveau bogue corrigé et marqué celui-ci comme invalide ou non reproductible avec une note comme, "Je ne peux pas comprendre ce que vous entendiez par" nav breaks ", mais j'ai résolu le problème que j'ai trouvé. Veuillez rouvrir ou soulever un nouveau bogue si la navigation se brise toujours, décrivant plus en détail ce qui ne va pas ".
Quant au calendrier, je pense qu'il devrait dépendre du projet. Si vous êtes très réactif et traitez ce bogue dans les jours suivant son apparition, alors les gens doivent comprendre que vous n'attendrez pas des semaines pour une réponse avant de résoudre le problème. D'un autre côté, s'il est sur votre tas de neige fondue depuis des mois, il peut rester ouvert pendant un mois ou deux sans vous causer de problème.
Pour cette raison, je ne pense pas qu'il y ait une limite de temps particulière qui constitue une "bonne pratique", ou que vous devez publier votre politique et la respecter. Vous ne voudriez certainement pas noter que le journaliste ne peut pas être contacté avant d'avoir fait un effort pour le contacter. Mais je ne vois pas non plus l'intérêt de laisser plusieurs avertissements compter jusqu'à une date limite: soit ils revisiteront le bogue et voudront dire quelque chose, soit ils ne le feront pas.