Un bon ticket GitHub se rédige plus facilement tant que le bug est encore à l’écran. L’enchaînement exact est frais. La ligne étrange de la console reste visible. Vous vous souvenez du contournement qui a échoué et de ce qui a changé après la dernière version.
Puis vous ouvrez l’éditeur, et le rapport devient : « La connexion ne marche pas dans Safari. »
La dictée vocale aide à éviter cette perte précise. Elle ne transforme pas d’elle-même une observation vague en rapport rigoureux. Elle permet de conserver plus vite les preuves, l’ordre et les limites que vous connaissez déjà, avant de les réduire à un titre et une phrase.
Les tickets GitHub servent à suivre des bugs, améliorations, tâches et autres informations de projet. Leur corps utilise GitHub Flavored Markdown, avec titres, listes de tâches, liens et blocs de code. Ce n’est donc pas un simple message, mais un petit dossier de travail qu’une autre personne doit pouvoir examiner, reproduire et fermer.
La structure stable reste dans le modèle, les faits variables passent par la voix
La plupart des équipes connaissent déjà les rubriques nécessaires :
- Résumé
- Étapes de reproduction
- Résultat attendu
- Résultat obtenu
- Environnement
- Critères d’acceptation
Taper ces libellés coûte peu. Reconstituer ce qui s’est passé sous chacun d’eux demande l’effort réel.
Une séparation efficace consiste à garder un modèle Markdown dans le dépôt, puis à dicter les preuves qui changent. GitHub prend en charge les modèles Markdown et les formulaires de ticket. Les questions stables peuvent donc être présentes dès l’ouverture de l’éditeur. Votre voix apporte les faits du jour : le quatrième clic, la version du navigateur, l’ancien jeton, l’écran inattendu et le test qui devra réussir après la correction.
Le modèle empêche aussi la dictée de devenir un long récit sans forme. La structure tient le rapport ; l’enregistrement remplit les cases.
Les étapes de reproduction ont besoin d’un ordre et d’un point de rupture
« Le téléversement échoue parfois » laisse trop de questions. Quel fichier ? Quelle page ? Avant ou après la connexion ? Un nouvel essai fonctionne-t-il ? Que voit-on au moment de l’échec ?
Dictez les étapes dans l’ordre et indiquez le premier endroit où le comportement observé diverge :
- Partez d’un état connu.
- Nommez l’action effectuée.
- Dites ce qui apparaît après chaque action importante.
- Arrêtez-vous au premier résultat incorrect.
- Précisez si l’échec se répète.
Par exemple :
Partez d’un compte connecté sans photo de profil. Ouvrez Réglages, choisissez un PNG de plus de cinq mégaoctets et appuyez une fois sur Enregistrer. La barre atteint cent pour cent, puis l’ancien avatar revient sans message d’erreur. Après actualisation, la nouvelle image n’apparaît toujours pas. Le même parcours réussit avec un PNG plus petit.
Ce paragraphe contient un cas de comparaison, un résultat visible et une vérification de répétabilité. Ce sont souvent les premiers détails supprimés quand le rapport est tapé dans l’urgence.
Séparez l’observation de l’explication
Un ticket devient plus difficile à enquêter lorsqu’une hypothèse est présentée comme une preuve.
« L’invalidation du cache est cassée » peut être juste, mais reste un diagnostic. « La deuxième requête renvoie l’ancienne URL de l’avatar après une réponse 200 du point d’envoi » est une observation. Elle donne un élément vérifiable même si la cause se trouve ailleurs.
À l’oral, marquez les limites :
- « J’ai observé… » pour le comportement visible.
- « Je m’attendais à… » pour le contrat supposé.
- « Mon hypothèse actuelle… » pour une explication provisoire.
- « Je n’ai pas vérifié… » pour une question ouverte.
La parole facilite l’ajout d’une théorie, puisque vous racontez le problème tel que vous le comprenez. La nommer comme théorie garde le ticket utile si elle s’avère fausse.
Tapez les jetons exacts et dictez ce qu’ils prouvent
La voix convient à la chronologie et au raisonnement. Elle convient moins lorsque chaque caractère compte.
Utilisez le clavier pour :
- les hash de commit et numéros de ticket
- les chemins et identifiants
- les URL avec paramètres
- les commandes shell et expressions régulières
- les traces et extraits de journaux
- les versions qui ne diffèrent que d’un chiffre
Collez journaux et code dans des blocs délimités plutôt que de les lire à voix haute. GitHub affiche ces blocs et peut appliquer une coloration syntaxique si un langage est indiqué. Un court extrait original est souvent plus utile qu’une paraphrase, car espaces, ponctuation et ordre des lignes peuvent constituer la preuve.
Dictez ensuite le contexte autour du jeton exact : d’où vient le journal, quelle action l’a produit et quelle ligne importe. Le clavier préserve l’artefact. La voix préserve sa signification.
Les critères d’acceptation donnent une ligne d’arrivée
Un ticket peut décrire précisément l’échec tout en restant difficile à fermer. « Corriger l’envoi de l’avatar » ne dit pas s’il faut afficher une erreur, accepter les gros fichiers, retenter la requête ou mettre l’image à jour immédiatement.
Ajoutez des critères vérifiables après le changement. Les listes de tâches GitHub utilisent des cases Markdown, ce qui maintient les résultats visibles pendant le travail.
Pour l’exemple :
- Une image prise en charge affiche le nouvel avatar sans actualisation manuelle.
- Une taille non prise en charge produit une erreur visible.
- Un envoi échoué ne remplace pas l’avatar existant.
- Le test de non-régression couvre la limite de taille en échec.
Les dicter est souvent plus simple, car vous pouvez répondre à une question directe : « Que dois-je voir pour accepter que le bug est corrigé ? » La liste décrit des résultats, pas une implémentation, sauf si cette implémentation fait partie de l’exigence.
Clean garde le rapport fidèle, Raw garde toute la prise
TalkTalkType enregistre tant que vous maintenez Option-Espace, puis renvoie le résultat dans le champ qui avait le focus. Dans l’éditeur GitHub, le contexte du dépôt, le modèle et les commentaires restent visibles pendant que vous parlez.
Clean effectue un nettoyage léger et fidèle. Il conserve tous les mots, leur ordre, votre registre et la brièveté voulue. Il retire seulement les hésitations sans ambiguïté et renvoie une ligne. Il ne transforme pas silencieusement le rapport en un autre modèle et n’invente aucun fait manquant.
Raw n’effectue aucun nettoyage et garde la transcription complète, faux départs compris. Il convient si vous prévoyez une forte révision ou si un nom propre inhabituel risque d’être modifié.
Aucun mode ne rend fiable la dictée de texte technique exact. Relisez le brouillon avant l’envoi, puis remplacez versions, noms, chemins et nombres incertains par des valeurs copiées. Dictée dans n’importe quelle app sur Mac explique la remise au champ actif et le repli par le presse-papiers.
Un champ pratique ne rend pas les secrets publiables
Un rapport peut se trouver dans un dépôt public, un dépôt privé d’entreprise ou un projet qui deviendra public. La destination fait partie de la frontière des données.
Ne prononcez pas de clé API, cookie de session, jeton d’accès, donnée privée de client ou identifiant de production. Masquez aussi les journaux collés. La dictée réduit l’effort de saisie ; elle ne change pas les personnes capables de lire le ticket final.
TalkTalkType ne conserve pas l’audio, la transcription brute ni le texte nettoyé dans un historique serveur. Le texte final est toutefois envoyé à GitHub lorsque vous créez le ticket. Dictée privée sur Mac suit l’enregistrement et la transcription dans les étapes précédentes.
Commencez par le ticket que vous alliez repousser
Ouvrez le modèle du dépôt tant que le bug est encore reproductible. Tapez le titre et les identifiants exacts. Dictez ensuite en une prise l’état initial, les actions ordonnées, le premier résultat incorrect, la répétabilité, le comportement attendu et l’incertitude actuelle.
Relisez une fois. Collez le plus petit extrait de journal utile. Ajoutez une liste qui définit la fin du travail.
Le but n’est pas d’écrire un ticket plus long. Il s’agit de conserver assez de ce moment pour qu’une autre personne puisse agir une fois le moment passé.