Les rapports de bugs en doublon sont des données, et les fusionner les détruit

Le deuxième rapport d’un bug que vous avez déjà reçu est fermé comme doublon, ce qui est généralement une bonne gestion administrative mais parfois une erreur coûteuse.

C’est une erreur en raison de ce que le deuxième rapport contient que le premier n’a pas. Deux personnes rencontrent le même échec sur des machines différentes, des comptes différents, des réseaux différents et à des moments différents. Le bug est ce qu’ils ont en commun. Tout le reste à leur sujet est la variation, et c’est la variation qui vous permet de le trouver.

Fermer le doublon sans le lire et vous avez conservé l’énoncé et rejeté l’expérience.

Ce qu’un deuxième rapport vous dit qu’un premier ne peut pas

Un rapport vous donne une description. Deux vous donnent une comparaison, et les comparaisons sont ce dont le diagnostic est fait.

Ce n’est pas la configuration d’une seule personne. La façon la plus commune dont une enquête s’enlise est le soupçon silencieux que le rapporteur a quelque chose d’étrange sur sa machine. Une deuxième personne, sans rapport, supprime ce soupçon en une ligne, et le supprime beaucoup plus de manière convaincante que le premier rapporteur insistant pour dire qu’il a vidé son cache.

L’intersection la réduit. Si les deux sont sur Safari et que tout le reste les différencie, vous avez un bug du navigateur. Si les deux sont au même niveau de compte et que rien d’autre ne correspond, vous avez un bug d’autorisations ou de plan. L’attribut partagé est la liste de suspects, et il faut deux rapports pour en avoir une.

La différence la réduit aussi, de l’autre côté. Si l’un est sur Windows et l’autre sur Android, le système d’exploitation est innocenté. Chaque axe sur lequel deux rapports diffèrent est un axe que vous pouvez arrêter d’examiner, ce qui vaut généralement plus que l’axe qu’ils partagent.

Le calendrier vous dit s’il se propage. Deux rapports à une heure d’écart après un déploiement est un incident en direct. Deux rapports à trois semaines d’écart est un ancien cas limite que personne n’a rencontré. Symptôme identique, réponse complètement différente, et vous ne pouvez pas dire lequel vous avez d’un seul rapport.

Faible

Fermé comme doublon de #4412.

Meilleur

Doublon de #4412. Les deux sur Safari, des comptes différents, des pays différents, tous deux après la version de mardi. Safari uniquement et a commencé avec ce déploiement. Détails ajoutés à #4412.

Que faire à la place, ce qui prend environ une minute

Vous le fermez toujours. Le suivi ne devrait pas avoir deux tickets ouverts pour un bug, et personne n’argumente contre cela.

Ce qui change est l’ordre. Lisez-le, prenez ce qu’il ajoute, mettez-le sur l’original, puis fermez-le en pointant vers l’original. En pratique, cela signifie copier quatre choses:

• L’environnement, même quand il correspond, car une correspondance est elle-même une découverte.
• L’horodatage, qui transforme deux rapports en une fréquence.
• Tout ce que le premier rapport n’avait pas: une erreur de console, une URL avec des paramètres différents, une étape que le premier rapporteur n’a pas mentionné d’avoir prise.
• Le fait qu’il y en ait maintenant deux, ce qui est la partie la plus souvent perdue, car un ticket qui dit « rapporté deux fois, indépendamment » est trié différemment d’un qui ne l’est pas.

Le problème de comptage en dessous

Il y a un deuxième coût, et il est plus lent à remarquer.

Les doublons sont le seul signal que la plupart des équipes ont sur la fréquence réelle d’un bug. La gravité est un jugement sur la gravité d’une occurrence; la fréquence est un fait sur le nombre qu’il y a. Un suivi qui fusionne les doublons sans les compter conserve le jugement et rejette le fait, puis priorise sur la moitié qu’il a conservée.

C’est ainsi qu’un bug que onze personnes ont signalé se retrouve sous un que quelqu’un d’influent a signalé une fois. Pas de mauvaise foi. Par une politique de fusion qui a traité le onzième rapport comme du bruit administratif.

Si votre suivi peut compter les doublons, comptez-les. S’il ne peut pas, une ligne sur l’original disant « signalé par 11 personnes entre le 3 et le 27 septembre » fait le même travail et survit à la lecture par quelqu’un qui n’était pas là.

Ce qu’il faut en tirer

Un doublon est une deuxième mesure du même événement, et la deuxième mesure est où se trouve l’information utile, car la première n’avait rien à comparer.

Fermez-les, mais lisez-les d’abord et emportez ce qu’ils ajoutent. Et gardez le comptage, car la fréquence à laquelle quelque chose se produit est un fait que votre suivi n’enregistre d’ailleurs nulle part, et c’est la moitié de chaque décision de priorisation que vous prenez.