Signaler les bugs

Un signalement de bug est un témoignage : ce que vous avez fait, ce qui s’est passé, ce que vous attendiez. C’est tout ce que le projet vous demande — la traduction en causes, en diagnostics et en correctifs est notre travail, pas le vôtre. Vous ne serez jamais blâmé de ne pas connaître les ordinateurs, d’écrire un anglais imparfait, ou d’un signalement qui se révèle être un problème de documentation : un utilisateur qui ne parvient pas à suivre une instruction technique a trouvé un défaut de conception ou de documentation, pas commis une faute personnelle (code de conduite).

Avant de signaler

1. Mettez d’abord à jour. Si vous le pouvez, vérifiez si le problème existe encore dans la dernière version de développement  — beaucoup de signalements sont déjà corrigés.
2. Cherchez dans les issues existantes . Si votre problème est déjà signalé, ajoutez-y vos informations — un contexte de plus a de la valeur ; un fil de plus est du bruit. Ne déterrez pas de vieux fils qui ne font que ressembler à votre problème : un fil, un sujet.
3. Triez ce que vous avez. Une régression est quelque chose qui marchait puis a cassé — dites quelle version marchait encore, cela raccourcit énormément la chasse. Un bug est quelque chose qui n’a jamais marché. Une question (« comment faire… ? ») va dans les Discussions , pas dans le traqueur — y demander n’est pas une contribution de seconde zone, et les cas ambigus sont bienvenus où que vous les mettiez : le triage existe pour trier, pas pour juger.

Écrire le signalement

Utilisez le formulaire de signalement  et suivez la culture de résolution de problèmes. Le fond :

• ce que vous avez fait — les étapes exactes, sur quelle image, dans quel ordre ;
• ce qui s’est passé — y compris les messages d’erreur exacts, des captures d’écran, ou le fichier produit ;
• ce que vous attendiez — c’est là que votre témoignage est irremplaçable : personne d’autre que vous ne sait à quoi ressemble « correct » pour votre travail ;
• votre contexte — version du logiciel et origine, système et version, pilotes graphiques, marque et génération du GPU, et le genre de photographie que vous faites quand cela compte ;
• joignez les pièces quand c’est pertinent : le fichier RAW et son historique de retouche .xmp attachés directement à l’issue, jamais derrière un lien tiers qui mourra avant qu’on y arrive.

Écrivez dans la langue que vous pouvez ; l’anglais approximatif convient, le français aussi — et la traduction automatique est un outil accepté des deux côtés.

Ce qui se passe ensuite

Votre signalement entre dans le protocole de triage : il reçoit une nature (régression, bug, amélioration…), une priorité, et un jalon quand il implique des ruptures de compatibilité. Les priorités sont des règles, pas des humeurs — les régressions avant les améliorations, les pertes de données et les plantages avant le confort, l’impact large sans contournement avant les cas de niche qui en ont un. Deux avertissements honnêtes, pour que le silence ne se lise jamais comme du mépris :

• La capacité est petite et la file est réelle. Pas encore de réponse veut dire « pas encore atteint », jamais « vous ne comptez pas ». Le tableau Kanban  montre ce qui est en cours.
• Aucun robot ne fermera votre signalement pour cause d’ancienneté. Une issue se ferme quand elle est corrigée, refusée avec une raison, ou établie comme invalide ou doublon — jamais par le balayage automatique d’un robot de péremption. Si elle se ferme, vous saurez pourquoi, et vous pouvez le contester avec des preuves.

Ce qu’un signalement ne peut pas faire

Un signalement énonce un problème ; il ne commande pas une solution. Si votre signalement est en réalité un souhait de fonctionnalité, il sera redirigé vers les Discussions  et mesuré à la portée — le refus, là, est le projet qui tient son périmètre, pas un jugement sur vous. Et si ce que vous avez trouvé est réel mais hors de notre portée — un défaut de bibliothèque tierce, un pilote en amont —, le signalement le dira et pointera où cela se règle, plutôt que de prétendre que nous pouvons réparer ce que nous ne pouvons pas.

Tester les versions de développement et confirmer les corrections est la contribution la plus utile qu’un non-programmeur puisse faire à ce projet : c’est le pacte qui joue dans votre sens.