Code de conduite

Ce code protège deux groupes de deux dangers. Il protège les utilisateurs — y compris les non-techniciens, les non-anglophones, le débutant entré par hasard — d’être traités comme des programmeurs ratés. Et il protège les gens qui font le travail de la pression d’une foule qui les dépasse en nombre de mille contre un. La plupart des codes de conduite ne regardent que dans une direction ; celui-ci refuse de choisir, parce que le projet a vu ce que coûte chacune des deux.

Ce que ce code ne régit pas

Le désaccord technique n’est pas un problème de conduite, et ce code ne servira jamais à en faire un. La critique du projet — sa conception, ses décisions, son code, ses priorités — n’est jamais sanctionnée comme conduite, si tranchante soit-elle, si dérangeante soit-elle, et qui qu’elle vise. Seule la façon dont on traite les personnes relève de ce code.

La ligne entre les deux n’est pas la température d’un message, et elle n’est pas dans l’œil de celui qui regarde : c’est l’objet de l’énoncé, et il se vérifie sur les mots eux-mêmes. Un énoncé sur le travail — le code, la décision, la conception, le registre — peut recevoir une réponse par les preuves : corriger le code, produire le registre, concéder le point. Un énoncé sur la personne — sa nature, sa valeur, ses motifs, son droit d’être là — ne peut recevoir d’autre réponse que la défense de son caractère, et c’est précisément pourquoi il n’a pas sa place dans une discussion de travail. Le test : si améliorer le travail ou produire le registre peut répondre à la phrase, c’est de la critique, et elle est protégée ; si seule la défense de soi le peut, c’est une attaque, et elle est modérée. Le sentiment de quiconque d’avoir été traité avec mépris, et le sentiment de quiconque d’être resté poli, ne changent rien à ce sur quoi porte une phrase.

Trois conséquences, dites sans détour :

• La colère visant le travail est un témoignage, pas une infraction. « Cette version a rompu une promesse et je suis furieux » est un énoncé sur le travail, si brûlant soit-il. Ce code ne sera pas l’instrument par lequel on esquive le fond d’une critique en poursuivant sa forme.
• Corriger une personne est protégé ; la congédier ne l’est pas. « Ça ne peut pas être si difficile, ajoutez juste une option » est une affirmation sur le travail — et sa réfutation aussi. Dire à quelqu’un que son image des rouages internes est fausse, sans détour et avec les raisons, engage l’affirmation et c’est protégé, si mal venu que ce soit : si vous affirmez comment le logiciel fonctionne, vous avez fait une affirmation technique, et vous assumez ce qui arrive ici aux affirmations techniques — elles reçoivent une réponse par le registre. Ce qui échoue au test, c’est le congédiement qui remplace la correction : « vous ne comprenez visiblement pas comment marche un logiciel », point final, n’engage rien et ne vise que la personne. Les mêmes mots suivis de l’explication réelle sont une réponse ; seuls, ils sont une sortie. Et la version polie — la condescendance qui n’explique rien — échoue au même test, seulement plus lentement.
• Un message mixte reçoit deux traitements. Un diagnostic juste enrobé d’une pique est deux énoncés : la pique est modérée, le diagnostic reçoit une réponse. Aucun des deux n’annule l’autre — modérer la forme ne dispense jamais de répondre au fond, et avoir raison sur le travail n’autorise jamais l’énoncé sur la personne.

Les règles

1. Écrivez dans la langue que vous pouvez. L’anglais approximatif convient ; ne pas utiliser l’anglais aussi. La modération est garantie en anglais et en français, au mieux en allemand, et par traduction automatique ailleurs — dites-le si une traduction vous fait dire autre chose.
2. Personne n’est blâmé de ne pas connaître les ordinateurs. Un utilisateur qui ne parvient pas à suivre une instruction technique a trouvé un problème de documentation ou de conception, pas commis une faute personnelle. Le savoir du métier est autre chose : Ansel attend de ses utilisateurs qu’ils apprennent le métier (portée), donc répondre à une question de photographie ou de couleur en nommant le bon chapitre de la documentation est une aide, pas un congédiement. C’est le geste qui fait la différence : « voyez le chapitre sur X » enseigne ; « lisez le manuel », sec, congédie — et le silence avec une étiquette congédie deux fois.
3. Les autres logiciels se discutent librement. Comparer Ansel à n’importe quel éditeur, commercial ou libre, est légitime et souvent la façon la plus rapide de décrire un problème. Personne n’est un étranger ici pour les outils qu’il utilise par ailleurs, et aucune censure ne sera exercée sur les discussions présentant ou recommandant d’autres applications, même perçues comme concurrentes.
4. La discussion existe pour aboutir à des décisions. Énoncez le problème, ajoutez de l’information, convergez. Le bavardage, les « moi aussi » et les remerciements sans contenu vont sur les canaux de chat — non que la chaleur soit malvenue, mais les fils sont la mémoire et l’index de recherche du projet. Trop de communication nuit aussi, et mène à la fatigue informationnelle.
5. Un fil, un sujet. Pour le lecteur qui viendra après vous, et pour le moteur de recherche qui le servira.
6. Définissez les problèmes par le but, pas par le remède. « Je veux que mon image ait l’air plus X » est exploitable ; « ajoutez un bouton qui fait Y » ne l’est pas (pourquoi).
7. Pas d’attaques contre les personnes. Ce que quelqu’un est — son identité, sa compétence en tant que personne, ses motifs supposés — n’est jamais le sujet. Une contribution peut être fausse ; démontrez-le sur la contribution.
8. Pas de siège. Un signalement clair suffit. La répétition, les déferlements collectifs, les ultimatums adressés à des bénévoles, et l’exigence polie mais sans fin de justifications qui ne s’arrête que lorsque sa cible craque — ce sont des tactiques de pression, et elles sont traitées comme telles, quelle que soit la courtoisie apparente de chaque message pris isolément.

Comment la critique est triée

Toute conversation difficile ici tombe dans l’un de trois cas, et chacun a son traitement. La distinction se fait sur les énoncés, jamais sur la personne qui les produit — la même personne peut produire les trois dans la même semaine :

• Une attaque contre une personne est modérée (règle 7) — qui que soit son auteur, qui que soit sa cible.
• Une demande hors de la portée du projet est refusée en citant la portée — c’est un souhait légitime, légitimement décliné, et le décliner n’est un problème de conduite dans aucun des deux sens. Aucun outil ne peut prétendre couvrir tous les cas d’usage et toutes les catégories d’utilisateurs sans devenir un fardeau pour ses mainteneurs comme pour ses utilisateurs. Faire des choix et ordonner des priorités fait partie de la bonne conception dans un monde aux ressources finies.
• Une critique qui tient le projet à ses propres engagements — vous avez promis ceci, le registre montre cela — est l’apport le plus précieux que ce projet reçoive. Elle reçoit une réponse sur le fond ou elle est concédée ; elle n’est jamais modérée, et jamais requalifiée en « toxicité » parce qu’elle était insistante ou en colère.

Les mêmes règles pour tous

Un comportement garde son nom quelle que soit la position de qui le manifeste. La frustration du mainteneur relève de la règle 7 exactement comme celle d’un nouveau venu ; l’ancienneté achète de l’autorité sur le code, jamais l’immunité sur la conduite. Si vous pensez que la modération a été appliquée de façon asymétrique, dites-le publiquement en citant cette section : la réclamation recevra une réponse par le registre, pas par un verrouillage.

Les régularités comptent

Ces règles jugent des énoncés, pas des personnes — à l’échelle d’un échange. Sur une longue série, le registre lui-même devient le sujet : quelqu’un qui, des mois durant, ne reconnaît jamais une erreur, n’absorbe jamais une réponse, et revient avec la même exigence quoi qu’on lui ait expliqué, n’est plus en train de converser — et nommer cette régularité, références datées à l’appui, est une synthèse légitime, pas une attaque. La même chose vaut pour nous : si le projet manque de façon répétée à ses propres engagements, le registre daté de ces manquements est un argument recevable, et le pacte existe pour être cité.

Application et appel

Les sanctions sont graduées, et chaque palier est notifié avec sa raison : d’abord un rappel public de la règle enfreinte ; puis le masquage ou le verrouillage du contenu concerné ; puis un blocage temporaire ; puis, pour les abus soutenus seulement, un bannissement. Les sanctions visent des comportements, sont aussi bornées dans le temps que les outils le permettent, et chacune peut faire l’objet d’un appel. Les appels s’adressent aux mainteneurs actuels du projet — répondez à la notification de modération, ou ouvrez un fil dans les Discussions  en référençant ce code ; si la sanction elle-même vous bloque l’accès, utilisez le canal de contact publié par le dépôt . Quand il existe plus d’un mainteneur, l’appel est examiné par quelqu’un qui n’a pas pris la décision d’origine. La réponse traitera vos arguments, pas votre valeur. Les actes de modération sont publics partout où la plateforme le permet : une disparition inexpliquée est un échec de modération, pas un style de modération.

Lieux : ce code s’applique sur le dépôt GitHub  (issues, pull requests, discussions), les canaux Matrix, et tout espace officiel que le projet ouvrira. Le texte canonique vit sur cette page ; le dépôt pointe ici.