cd / ;
apropos ;
find * ;
Importé depuis:
https://www.gnurou.org/writing/smartquestionsfr/
(Ou comment poser les questions de façon intelligente)
Traduction en français du document original de Eric S. Raymond. Conforme à la révision 3.10 du 21 mai 2014.
document original de Eric S. Raymond
http://www.catb.org/%7Eesr/faqs/smart-questions.html
Dans le monde des hackers (N.d.T. : Une version traduite de ce document est disponible), le type de réponses que vous recevez pour vos questions d'ordre technique dépend autant de la façon dont vous formulez la question que de la difficulté à développer la réponse. Ce guide va vous apprendre à poser des questions de façon à maximiser vos chances d'obtenir une réponse satisfaisante.
Maintenant que l'usage du logiciel libre (ou open source) s'est généralisé, vous pouvez souvent obtenir d'aussi bonnes réponses de la part des utilisateurs expérimentés que des hackers. C'est une bonne chose ; les utilisateurs ont tendance à être légèrement plus tolérants envers les erreurs commises par les débutants. Néanmoins, traiter ces utilisateurs expérimentés de la même manière que les hackers dont nous parlons ici est généralement la meilleure façon d'obtenir de bonnes réponses de leur part.
La première chose à comprendre est que les hackers aiment les problèmes compliqués et les bonnes questions qui font travailler les méninges. Si vous nous donnez une question intéressante en pâture nous vous en serons reconnaissants ; les bonnes questions sont un stimulant et une aubaine. Les bonnes questions nous aident à développer notre propre compréhension, et révèlent souvent des problèmes que nous n'avions pas remarqués et auxquels nous n'aurions pas pensé autrement. Entre hackers, « Bonne question ! » est un compliment fort et sincère.
Malgré cela, les hackers ont la réputation de traiter les questions simples avec hostilité ou arrogance. Parfois, il semble que nous sommes inconditionnellement hostiles envers les débutants ou ignorants. Ce n'est pas tout à fait vrai.
Nous sommes en fait hostiles aux gens qui ont l'air de ne pas avoir réfléchi au problème et n'ont pas fait leur propre travail de recherche avant de poser des questions. De telles personnes sont des gaspilleurs de temps --- ils prennent sans donner en retour, et gaspillent du temps que nous aurions pu passer sur une autre question plus intéressante pour une autre personne qui mérite, elle, une réponse. Nous appelons ces gens-là des "losers" (N.d.T. : perdants) (et pour des raisons historiques nous l'écrivons parfois "lusers").
Nous savons bien que beaucoup de personnes veulent juste utiliser les logiciels que nous écrivons, et n'ont aucune envie de s'investir dans les détails techniques. Pour la plupart des gens, un ordinateur n'est rien de plus qu'un outil, un moyen et non pas un but ; ils ont d'autres choses beaucoup plus intéressantes à faire et leur propre vie à mener. Nous comprenons cela, et ne nous attendons pas à ce que tout le monde s'intéresse aux détails techniques dont nous sommes passionnés. Néanmoins, notre style de réponse est adapté aux gens qui sont intéressés et veulent participer activement à la résolution des problèmes. Cela ne changera pas, et de toute façon il n'y a aucune raison pour que cela arrive ; autrement nous deviendrions moins efficaces dans ce que nous savons faire le mieux.
Il faut comprendre que nous sommes (pour la plupart) des volontaires. Nous prenons du temps sur nos vies déjà bien remplies pour répondre à des questions dont nous sommes parfois submergés. Par conséquent, nous n'avons aucun remords à les filtrer. En particulier, nous rejetons les questions de personnes qui ont l'air de losers pour passer notre temps de support de manière plus efficace, sur les "winners" (N.d.T. : gagnants).
Si vous trouvez cette attitude odieuse, condescendante ou arrogante, repensez-y. Nous ne vous demandons pas de vous mettre à genoux devant nous --- en fait, la plupart d'entre nous ne demandent pas mieux que de traiter d'égal à égal avec vous et de vous accueillir dans notre culture, si vous faites l'effort nécessaire pour que ce soit possible. Mais il n'est tout simplement pas efficace pour nous d'apporter notre aide à des gens qui ne veulent pas s'aider eux-mêmes. Il n'y a pas de mal à être ignorant ; mais il y en a à faire l'idiot.
Par conséquent, s'il n'est pas nécessaire d'être déjà techniquement compétent pour attirer notre attention, il *est* en revanche nécessaire de montrer une attitude susceptible d'amener à cette compétence --- être attentif, réfléchi, observateur, consentant à être un partenaire actif au développement de la solution. Si vous ne pouvez pas vivre avec cette sorte de discrimination, nous vous recommandons de payer quelqu'un pour un contrat de support commercial au lieu de demander aux hackers de donner de leur personne pour vous.
Si vous décidez de nous demander de l'aide, vous ne voudrez pas faire partie des losers. Vous ne voulez sans doute pas non plus avoir l'air d'en être. La meilleure manière d'obtenir une réponse rapide et enthousiaste est de poser votre question comme une personne intelligente, confiante, ayant des indices sur son problème et qui a juste besoin d'un coup de pouce sur un point particulier.
(Les améliorations à ce guide sont les bienvenues. Vous pouvez écrire vos suggestions à esr(at)thyrsus(point)com ou respond-auto(at)linuxmafia(point)com. Veuillez cependant noter que ce document n'a pas vocation à être un guide général à la netiquette et que nous rejetons les suggestions qui ne concernent pas l'obtention de réponses utiles sur un forum technique.)
(N.d.T. : Notez bien que les éventuelles erreurs de ce document sont peut-être dues au traducteur, et non à l'auteur. Si vous avez une amélioration à transmettre, essayez de vérifier si elle est toujours pertinente sur le document original --- si ce n'est pas le cas, ou si l'anglais n'est pas votre fort, contactez plutôt le traducteur à gnurou(arobase)gmail(point)com. En particulier, les corrections orthographiques et grammaticales sont les bienvenues. Merci aux nombreuses personnes qui ont apporté des corrections, et en particulier à Guillaume Estival pour sa seconde traduction.)
Avant de poser une question par email, dans les groupes de discussion, ou dans le forum de discussion d'un site web, assurez-vous d'avoir fait les choses suivantes :
Quand vous posez votre question, mettez en avant le fait que vous ayez déjà fait ces choses ; cela aidera à établir que vous n'êtes pas un pique-assiette qui fait perdre du temps aux autres. Mieux, mettez en avant ce que vous avez appris en faisant ces choses. Nous aimons répondre aux questions de ceux qui ont prouvé qu'ils peuvent apprendre à partir de réponses.
Utilisez des tactiques telles que faire une recherche Google sur le texte ou le message d'erreur que vous obtenez (recherchez sur Google groupes en plus des pages Web). Cela risque fort de vous amener directement vers la bonne documentation ou vers un fil de liste de diffusion qui répond à votre question. Et même si ça n'est pas le cas, la phrase « j'ai recherché cette phrase sur Google mais ça ne m'a rien montré d'intéressant » est toujours bonne à inclure dans un email ou un message demandant de l'aide.
Préparez votre question. Pensez-y bien. Les questions précipitées reçoivent des réponses précipitées, voire rien du tout. Plus vous montrez que vous avez fait des efforts pour résoudre votre problème avant de demander de l'aide, plus vous avez de chances d'être aidé.
Faites attention à ne pas poser la mauvaise question. Si vous en posez une basée sur des assertions erronées, le hacker moyen va sûrement vous envoyer une réponse qui vous prendra au mot tout en pensant « Quelle question stupide... », et espérera vous donner une leçon en vous donnant non pas ce dont vous aviez besoin, mais ce que vous aviez demandé.
Ne pensez pas que vous êtes redevable d'une réponse. Ce n'est pas le cas ; après tout, vous ne payez rien pour le service rendu. Vous recevrez une réponse, si vous en recevez une, en posant une question qui est riche, intéressante, et qui fait travailler les méninges --- une question qui contribue implicitement à l'expérience de la communauté au lieu d'exiger passivement l'aide des autres.
Rendre clair le fait que vous êtes capable et avez la volonté d'aider au développement de la solution est un très bon début. « Quelqu'un peut-il me donner un tuyau ? », « Que manque-t-il à mon exemple ? » et « Y a-t-il un site que j'aurais dû aller voir ? » ont beaucoup plus de chances d'avoir une réponse que « Dites-moi exactement ce que je dois faire, merci. » parce que vous mettez en évidence le fait que vous voulez bien finir le travail si quelqu'un vous indique simplement la bonne direction.
Voici quelques points à tenir en compte au moment de rédiger votre question:
Choisissez l'endroit où vous poserez votre question avec soin. Vous avez toutes les chances d'être ignoré, ou de passer pour un loser, si vous :
Les hackers rejettent les questions qui ne sont pas bien ciblées de manière à protéger leurs canaux de communication d'un envahissement de messages hors-sujet. Vous ne voulez pas que cela vous arrive non plus.
La première étape est par conséquent de trouver le bon forum. À nouveau, Google et les autres moyens de recherche sur internet sont vos amis. Utilisez-les pour trouver la page Web du projet le plus proche du matériel ou du logiciel qui vous cause des difficultés. Généralement, vous trouverez des liens vers une liste de FAQs (Foire Aux Questions), et vers les listes de diffusion du projet ainsi que leurs archives. Ces listes de diffusion sont les endroits ultimes où rechercher de l'aide, si tant est que vos propres efforts (qui incluent la lecture de ces FAQs que vous aurez trouvées) ne vous aient pas sorti d'affaire. La page du projet peut également comporter une procédure pour rapporter les bugs, ou comprendre un lien vers elle. Si c'est le cas, suivez-la.
Balancer un email à une personne ou un forum qui ne vous est pas familier est très risqué. Par exemple, ne vous imaginez pas que l'auteur d'une page informatique a envie d'être votre consultant gratuit. Ne faites pas de pronostics optimistes sur l'accueil que recevra votre question --- si vous n'être pas sûr, envoyez-la ailleurs, ou retenez-vous de l'envoyer.
Lorsque vous choisissez un forum, un groupe de discussion ou une liste de diffusion, ne faites pas trop confiance à son nom ; vérifiez sur une FAQ que votre question correspond au sujet de discussion. Lisez quelques-uns des messages récents avant d'envoyer votre message histoire d'avoir une idée de comment les choses se déroulent. En fait, c'est une très bonne idée que de faire une recherche avec les mots-clé correspondant à votre problème dans les archives du groupe discussion avant d'envoyer votre message. Vous pourriez trouver ainsi une réponse, ou sinon une meilleure manière de formuler votre question.
Ne tirez pas à vue sur tous les canaux d'aide en même temps, c'est similaire à hurler et irrite les gens.
Connaissez votre sujet de discussion! Une des erreurs les plus classiques est de poser des questions sur l'interface de programmation Unix ou Windows dans un forum dédié à un langage ou à une bibliothèque. Si vous ne voyez pas où se trouve la boulette là-dedans, vous feriez mieux de ne pas poser de questions du tout jusqu'à ce que vous ayez compris.
En général, une question posée sur un bon forum public a plus de chances d'obtenir des réponses utiles que la même question sur un forum privé. Il y a plusieurs raisons à cela. L'une d'entre elles est simplement le nombre de gens susceptibles de vous aider. Une autre est le nombre de personnes composant l'audience ; les hackers ont plutôt tendance à répondre à des questions qui peuvent en apprendre à beaucoup de gens plutôt qu'à des questions utiles pour peu de personnes.
Il est compréhensible que les hackers talentueux et les auteurs de logiciels populaires reçoivent déjà largement leur part de messages mal adressés. En vous ajoutant au flux, vous pourriez dans le cas extrême être la goutte d'eau qui fait déborder le vase --- il est déjà arrivé que des contributeurs à des logiciels populaires abandonnent leur support parce que les dommages collatéraux causés par les emails indésirables sur leurs adresses personnelles sont devenus ingérables.
Votre groupe local d'utilisateurs, ou votre distribution Linux font peut-être la promotion d'un forum Web ou d'un canal IRC permettant aux débutants d'obtenir de l'aide. Ce sont de bons endroits à interroger, en particulier si vous pensez que votre problème est relativement simple à résoudre. Un canal IRC bien promu est une invitation à y poser des questions pour souvent obtenir des réponses en temps réel.
En fait, si le programme qui vous pose problème vient d'une distribution Linux (comme c'est souvent le cas aujourd'hui), il est probablement mieux de poser votre question sur le forum ou la liste de votre distribution avant plutôt que ceux du projet du programme. Les hackers du projet risquent de vous répondre : utilise notre binaire.
Avant de poster sur un forum Web, vérifiez s'il dispose d'une fonction de recherche. Si oui, essayez de faire quelques recherches par mot-clé pour quelque chose qui se rapproche de votre problème ; cela pourrait vous aider. Si vous avez déjà fait une recherche Web auparavant (comme vous devriez le faire), cherchez quand même dans le forum ; le moteur de recherche que vous aviez utilisé n'a peut-être pas encore indexé tout le contenu de ce forum.
La tendance actuelle pour les projets est de fournir le support utilisateur au travers d'un forum Web ou d'un canal IRC, l'email étant réservé au trafic lié au développement. Essayez donc de trouver ces canaux en premier lorsque vous cherchez de l'aide par rapport à un projet précis.
Lorsqu'un projet possède une liste de diffusion dédiée au développement, écrivez sur celle-ci, et non pas à un développeur en particulier, même si vous pensez savoir qu'il répondra mieux à votre question. Recherchez l'adresse d'une liste de diffusion dans la documentation du projet et sur son site web, et utilisez-la. Il y a plusieurs raisons de procéder ainsi :
Une question qui est assez bonne pour être posée directement à un développeur aura également de la valeur pour le groupe entier. De la même manière, si vous pensez qu'une question est trop bête pour une liste de diffusion, ce n'est pas une excuse pour importuner un développeur.
Poser des questions sur une liste répartit la charge entre tous les développeurs. Un développeur particulier (surtout s'il est le leader du projet) sera sans doute trop occupé pour vous répondre.
La plupart des listes de diffusion sont archivées et les archives référencées par les moteurs de recherche. Quelqu'un pourra par la suite trouver votre question et sa réponse sur le web au lieu de la reposer à nouveau sur la liste.
Si certaines questions reviennent souvent, les développeurs peuvent se servir de cette information pour améliorer la documentation ou le logiciel lui-même afin de les rendre moins confus. Mais si ces questions sont posées en privé, personne ne peut vraiment savoir quelles questions reviennent le plus souvent.
Si le projet possède à la fois une liste de diffusion/forum "utilisateurs" et une autre "développeurs" (ou "hackers"), et que vous ne hackez pas le code vous-même, posez votre question sur la liste "utilisateurs". Ne partez pas du principeque vous serez bienvenu sur la liste développeurs, car ceux-ci risquent d'interpréter votre question comme du bruit qui perturbe le trafic normal de la liste.
Toutefois, si vous êtes sûr que votre question n'est pas triviale, et que vous n'obtenez pas de réponse depuis la liste "utilisateurs", essayez de la poser sur la liste "développeurs". Vous seriez bien avisé par ailleurs d'observer le trafic de la liste pendant quelques jours avant d'y poser votre question, afin d'assimiler les moeurs locales (ce conseil est d'ailleurs valable pour toute liste privée ou semi-privée).
Si vous ne pouvez pas trouver de liste de diffusion pour le projet, et ne voyez que l'adresse du mainteneur, adressez-vous alors à lui. Mais même dans ce cas, ne supposez pas que la liste de diffusion n'existe pas. Mettez en évidence dans votre email que vous avez cherché une liste de diffusion mais ne l'avez pas trouvée. Précisez aussi que vous n'avez aucune objection à ce que votre message soit envoyé à d'autres personnes. (Beaucoup de gens pensent que les emails privés doivent rester privés, même s'il n'y a rien de secret dedans. En lui permettant de rediriger votre mail, vous donnez à votre correspondant le choix sur la manière de traiter votre message.)
Sur les listes de diffusion, les newsgroups ou les forums Web, le sujet du message est une occasion en or pour attirer l'attention d'experts qualifiés en 50 caractères ou moins. Ne le gaspillez pas en babillages comme "Aidez-moi SVP" (et ne pensez même pas à "AIDEZ MOI SVP !!!!!!" ; les messages avec ce genre de sujets sont ignorés par réflexe). N'essayez pas de nous faire apitoyer sur votre sort, utilisez plutôt l'espace disponible pour décrire le problème de manière très concise.
Une bonne convention pour les sujets de message, utilisée par beaucoup de supports techniques, est "objet - déviation". "objet" décrit quel composant pose problème, "déviation" explique en quoi le comportement dévie du comportement attendu.
Stupide :
AIDEZ MOI ! La vidéo ne marche pas sur mon portable !
Intelligent :
Curseur de souris difforme sur X.org 4.1, chipset vidéo Fooware MV1005
Encore mieux :
Curseur de souris difforme sur X.org 4.1 avec chipset vidéo Fooware MV1005
Écrire une description du type "objet - déviation" vous aidera à mieux organiser votre pensée à propos du problème. Qu'est-ce qui est affecté? Seulement le curseur de souris ou d'autres éléments graphiques? Est-ce spécifique à X.org? À la version 4.1? Est-ce spécifique aux chipsets vidéo Fooware? Au modèle MV1005? Un hacker qui voit le résultat peut ainsi immédiatement comprendre ce qui vous cause ce problème et quel est votre problème, en un coup d'oeil.
Plus généralement, imaginez que vous regardiez l'index d'une archive de questions, dans lequel seules les lignes de sujet sont visibles. Faites que votre ligne de sujet reflète suffisamment bien votre problème, afin que la prochaine personne qui cherche dans l'archive pour une question similaire à la vôtre puisse trouver votre question au lieu de la poser à nouveau.
N'appuyez pas sur "répondre" dans un message existant pour commencer un nouveau sujet. Cela va limiter votre audience. Certains lecteurs de mails, comme mutt, permettent de trier les messages par sujet et de grouper les messages d'un même ensemble de réponses en le repliant. Les personnes qui font cela ne verront jamais votre message.
Changer le sujet n'est pas suffisant. Mutt, et probablement d'autres lecteurs de mails, utilise d'autres informations que le sujet pour assigner un message à un groupe. Commencez plutôt un nouveau sujet.
Sur les forums Web, les règles de bonne pratique sont légèrement différentes, parce que les messages sont usuellement attachés à un fil de discussion et sont invisibles en dehors de celui-ci. Changer le sujet lorsqu'on pose une question n'est pas essentiel. Tous les forums ne permettent pas de mettre un sujet sur les réponses, et de toute façon pratiquement personne ne les lit. Toutefois, poser une question en réponse à un autre fil est une pratique douteuse en elle-même, car elle ne sera vue que par ceux qui lisent ce fil. Alors, à moins que vous ne soyez sûr de vouloir poser votre question uniquement aux personnes actives dans un fil particulier, commencez-en un nouveau.
Terminer votre requête par « Merci d'envoyer la réponse à ... » élimine une bonne partie de vos chances d'obtenir une réponse. Si vous ne prenez pas la peine d'investir dans les quelques secondes nécessaires à préciser un champ "Répondre à..." correct dans votre logiciel de courrier, nous n'allons pas prendre la peine d'investir dans les quelques secondes nécessaires à la considération de votre problème. Si votre logiciel de courrier ne vous permet pas de faire cela, installez-en un meilleur. Si votre système d'exploitation ne supporte pas de logiciel de courrier permettant ceci, installez-en un meilleur.
Sur les forums Web, demander une réponse par email est terriblement impoli, à moins que vous ne pensiez que l'information soit sensible (et que quelqu'un pourrait, pour une quelconque raison, vous expliquer quelque chose à vous et pas au reste du forum). Si vous voulez une copie par email des réponses au sujet, demandez au forum de vous l'envoyer ; cette fonctionnalité est supportée pratiquement partout via les options "Surveiller ce sujet", "Recevoir un email quand une réponse arrive", etc.
Nous savons par expérience que les gens qui ne font pas attention à la forme de leur écrit ne font en général pas non plus attention à ce qu'ils disent et pensent (du moins, nous l'avons vu assez souvent pour le croire). Répondre aux questions de ceux qui ne font pas attention à ce qu'ils disent n'est pas vraiment valorisant ; nous préférons passer notre temps à faire autre chose.
C'est pourquoi exprimer clairement votre question est important. Si vous ne prenez pas la peine de faire cela, nous ne prendrons pas la peine d'y faire attention. Faites un effort pour travailler votre langage. Cela ne veut pas dire qu'il doit être rigide ou formel --- en fait, la culture hacker privilégie plutôt le langage informel, familier et humoristique utilisé avec précision. Mais il doit être précis ; il doit y avoir une indication que vous pensez également au problème et y prêtez attention.
Orthographiez correctement, utilisez correctement ponctuation et majuscules. Ne confondez pas "ce" avec "se" ou "c'est" avec "s'est". NE TAPEZ PAS TOUT EN MAJUSCULES, c'est lu comme si vous criiez et considéré comme impoli (le tout en minuscules n'est qu'un peu moins ennuyeux, car c'est difficile à lire. Alan Cox peut se permettre de le faire, mais pas vous).
Plus généralement, si vous écrivez comme un porc, vous serez probablement ignoré. Ecrire comme un l33t hax0r est le baiser de la mort ultime, et la garantie que vous ne recevrez rien sauf le silence en retour (ou alors, au mieux, on se moquera de vous).
Si vous posez des questions dans un forum qui ne parle pas votre langue natale, faire des erreurs de grammaire ou d'orthographe est excusable, mais ne pas faire d'efforts, non (et, oui, nous pouvons faire la différence). Alors, à moins d'être sûr de la langue natale de vos correspondants, écrivez en anglais. Les hackers ne répondent pas aux questions posées dans une langue qu'ils ne comprennent pas, et l'anglais est la langue la plus courante sur le net. En écrivant en anglais, vous maximisez les chances qu'a votre question d'être lue.
Si vous rendez vos questions artificiellement dures à lire, elles vont sans doute être ignorées au profit d'autres qui ne le sont pas. Donc :
Envoyez vos mails en texte simple, et non pas en HTML.
Les pièces jointes au format MIME sont généralement OK, mais seulement si elles sont du réel contenu (comme un fichier source ou un patch) et pas de la bouillasse générée par votre client mail (comme une deuxième copie de votre message).
N'envoyez pas de mail dans lequel les paragraphes sont écrits sur une seule ligne dans toute leur longueur (cela rend difficile de répondre à une partie seulement du message). Considérez que vos correspondants lisent leurs messages sur des terminaux texte à 80 caractères et paramétrez le passage à la ligne à 80 caractères ou moins.
N'utilisez pas de caractères encodés MIME sur des forums anglophones. Cet encodage peut s'avérer nécessaire si vous postez dans une langue non couverte par le codage ASCII, mais la plupart des clients mail ne le supportent pas - dans ces cas-là votre mail se retrouvera avec plein de caractères de type =20 et sera horrible à lire.
Ne vous attendez jamais à ce qu'un hacker puisse lire des formats de documents fermés et propriétaires comme Microsoft Word. La plupart des hackers réagissent à cela comme vous réagiriez si on déposait du purin à votre porte.
Si vous envoyez vos mails à partir d'une machine Windows, désactivez la stupide option "Guillemets intelligents". Cela pour éviter des caractères indésirables dans votre mail.
Dans les forums web, n'abusez pas des smileys et autres effets HTML. Un smiley ou deux passent bien, mais du texte colorié dans tous le sens vous fera passer pour un blaireau. Abuser des smileys et des couleurs vous fera passer pour un kikoolol en phase terminale, ce qui n'est généralement pas une bonne idée à moins que vous n'aimiez le ridicule en public.
Si vous utilisez un client mail graphique, comme Netscape Messenger ou Microsoft Outlook, soyez conscient du fait que leurs paramètres par défaut peuvent violer ces règles. La plupart de ces clients disposent d'une commande "Voir le code source". Utilisez-la sur un des messages de votre dossier d'envoi, pour vérifier que vos mails sont bien du texte simple, sans autres choses inutiles.
Essayez d'anticiper les questions qu'un hacker pourrait vous demander, et d'y répondre en avance dans votre demande d'aide. Simon Tatham a écrit un excellent article intitulé Comment signaler efficacement un bug. Je vous recommande grandement de le lire:
http://www.chiark.greenend.org.uk/%7Esgtatham/bugs-fr.html
Vous devez être précis et informatif. Coller un gros tas de code ou de données dans votre demande d'aide ne va pas vous y aider. Si vous avez un cas précis de grande taille qui fait planter un programme, essayez de l'élaguer et de le réduire au maximum.
Ceci est utile pour au moins trois raisons. Un : voir que vous faites un effort pour simplifier la question augmentera vos chances d'obtenir une réponse. Deux : simplifier la question augmentera vos chances d'obtenir une réponse utile. Trois : en simplifiant le problème, vous pourriez très bien finir par le résoudre vous-même.
Quand vous avez des problèmes avec un logiciel, ne prétendez pas avoir trouvé un bug à moins d'être très, très sûr de vous. Indice : sauf à être capable de fournir un patch réparant le problème, ou un test de régression sur une ancienne version qui démontre un comportement incorrect, vous n'êtes pas suffisamment sûr de vous. Ceci s'applique également aux pages web et à la documentation ; si vous avez trouvé un "bug" de documentation, vous devez pouvoir fournir un texte de remplacement et la liste des pages auxquelles il s'applique.
Rappelez-vous que beaucoup d'utilisateurs ne rencontrent pas votre problème. Sinon vous en auriez entendu parler en lisant la documentation ou en cherchant sur le Web (car vous l'avez fait avant de vous plaindre, pas vrai ?). Cela signifie que c'est très probablement vous qui avez fait quelque chose d'incorrect, et non pas le logiciel.
Les personnes qui ont écrit le logiciel travaillent très dur pour le faire fonctionner aussi bien que possible. Si vous affirmez avoir trouvé un bug, vous mettez en cause leur compétence, ce qui pourrait offenser certains d'entre eux, même si vous avez raison. Il n'est particulièrement pas diplomate de mettre "bug" dans le sujet du message.
Quand vous posez votre question, le mieux est d'écrire comme si vous supposiez que vous avez fait quelque chose d'incorrect, même si vous êtes secrètement sûr d'avoir trouvé un bug. S'il s'agit vraiment d'un bug, vous le saurez avec la réponse. Jouez-la de telle sorte que les mainteneurs aient envie de s'excuser si le bug est réel, plutôt que ce soit vous qui deviez vous excuser s'il s'avère que vous vous êtes trompé.
Certaines personnes comprennent qu'elles ne doivent pas être arrogantes ou impolies pour obtenir une réponse, et réagissent à l'extrême opposé en se mettant plus bas que terre. "Je sais que je suis un pauvre looser, mais...". Ce comportement est perturbant et n'aide personne. En particulier lorsqu'il est couplé à un problème décrit de façon très vague.
Ne perdez pas votre temps, ni le nôtre, avec de la politique de primates. En lieu et place, présentez les faits que vous avez accumulés et votre question aussi clairement que vous le pouvez. C'est une bien meilleure façon de vous représenter.
Parfois, les forums Web ont des endroits spécifiques pour les débutants. Si vous sentez que vous avez une question de débutant, allez la poser là-bas. Mais ce n'est pas plus une raison de vous y humilier.
Il n'est pas vraiment utile d'expliquer aux hackers ce qui pourrait causer le problème selon vous (si votre diagnostic était si bon, pourquoi demanderiez-vous de l'aide aux autres ?) Par conséquent, soyez sûr que vous leur indiquez les symptômes bruts de ce qui ne va pas, et non pas vos interprétations et théories. Laissez-les faire le travail d'interprétation et de diagnostic. Si vous pensez que votre interprétation a de l'importance, décrivez-la comme telle et expliquez pourquoi cette solution ne fonctionne pas.
Stupide :
J'ai des erreurs SIG11 répétées lors de la compilation du noyau, et je pense que ça vient d'une microcoupure sur ma carte mère. Comment puis-je vérifier cela ?
Intelligent :
Mon K6/233 que j'ai monté moi-même sur ma carte mère FIC-PA2007 (chipset VIA Apollo VP2) avec 256Mo de SDRAM PC 133 Corsair me donne des erreurs SIG11 environ 20 minutes après le démarrage pendant que je compile le noyau, mais jamais pendant les 20 premières minutes. Si je reboote, l'horloge ne revient pas à zéro, mais si je l'éteins toute la nuit, si. Changer la RAM ne résout pas le problème. Ci-après, la partie intéressante du log de compilation.
Comme ce point semble être difficile à assimiler pour beaucoup de personnes, rappelez-vous qu'il ne suffit pas d'expliquer : il faut montrer.
Les indices les plus utiles pour trouver ce qui ne va pas se situent souvent dans ce qui s'est produit juste avant. Donc, votre explication devrait décrire précisément ce que vous avez fait, et ce que la machine a fait, pour arriver à la panne. Dans le cas de programmes en ligne de commande, avoir un log de session (c.-à-d. utiliser l'utilitaire script) et citer la vingtaine de lignes intéressantes est très utile.
Si le programme qui a planté possède des options de diagnostic (comme -v pour verbose (N.d.T. : bavard, verbeux)), essayez de sélectionner les options qui vont ajouter des informations de débogage utiles à la transcription.
Si votre explication devient trop longue (plus de quatre paragraphes), il serait utile de résumer le problème au-dessus, puis continuer avec le récit chronologique. De cette manière, les hackers sauront ce qu'il faut regarder en lisant votre explication.
Si vous essayez de deviner comment faire quelque chose (par opposition à reporter un bug), commencez par décrire votre but. Ensuite seulement, décrivez l'étape à laquelle vous êtes bloqué.
Souvent, les gens qui demandent de l'aide ont un but particulier en tête et sont bloqués dans ce qu'ils pensent être une étape vers ce but. Ils demandent de l'aide sur cette étape, mais ne réalisent pas que c'est leur approche dans sa totalité qui est fausse. Il est difficile de le deviner dans ces conditions.
Stupide :
Comment puis-je donner une valeur RGB hexadécimale au programme FooDraw?
Intelligent :
J'essaie de remplacer la table des couleurs d'une image par des valeurs de mon choix. Pour le moment, le seul moyen que j'ai trouvé est d'éditer chaque valeur individuellement, mais je ne parviens pas à donner une valeur RGB hexadécimale au sélecteur de couleur de FooDraw.
La seconde version de la question est pertinente. Elle permet une réponse qui suggère un outil mieux adapté à la tâche.
Les hackers pensent que les problèmes doivent être résolus en public, de manière transparente, de telle sorte qu'un premier élément de réponse puisse et doive être corrigé si quelqu'un connaissant mieux le problème s'aperçoit qu'il est incomplet ou incorrect. Aussi, leur récompense pour avoir réagi au problème est en partie qu'ils sont reconnus comme compétents et connaisseurs par leurs pairs.
Quand vous demandez une réponse privée, vous cassez ce processus et cette récompense. Ne le faites donc pas. C'est à la personne qui répond de décider s'il faut vous répondre en privé et si elle le fait, c'est en général parce qu'elle pense que la question est trop évidente ou mal formulée pour être intéressante pour les autres.
Il y a une petite exception à cette règle. Si vous pensez que la question risque d'entraîner beaucoup de réponses qui seront pour la plupart similaires, la formule magique est alors de dire "envoyez-moi vos réponses et je ferai un résumé pour le groupe". Il est courtois d'essayer d'éviter à la liste de diffusion ou au newsgroup d'être inondés par un ensemble de messages similaires - mais vous devez tenir votre promesse de faire un résumé.
Les questions trop générales sont perçues comme une perte de temps. Les personnes les plus à même de vous répondre correctement sont également les plus occupées (entre autres parce qu'elles prennent la plus grosse part du travail). Ces personnes sont allergiques aux pertes de temps, et donc aux questions trop générales.
Vous aurez plus de chances d'obtenir une réponse si vous êtes explicite dans ce que vous voulez que vos correspondants fassent (donner un tuyau, envoyer du code, vérifier un patch, etc.). Cela va leur permettre de concentrer leurs efforts et de mieux vous aider.
Pour comprendre dans quel monde les experts vivent, pensez que l'expertise est une ressource abondante, mais que le temps pour répondre manque cruellement. Moins vous demandez de temps, plus vous avez de chance d'obtenir une réponse de quelqu'un de vraiment bon et vraiment occupé.
Il est donc utile de couper votre question pour minimiser le temps requis pour y répondre -- mais ce n'est pas la même chose que simplifier la question. Par exemple, "Pouvez-vous me donner une adresse vers une bonne explication de X ?" est une bien meilleure question que "Pouvez-vous m'expliquer X ?". Si vous avez du code qui ne marche pas, il est en général plus avisé de demander ce qui ne va pas avec plutôt que de demander de le réparer.
Ne demandez pas aux autres de débugger votre code défectueux sans leur donner un indice sur le problème qu'ils doivent chercher. Si vous postez quelques milliers de lignes de code suivies d'un "Ça ne marche pas", vous serez tout simplement ignoré. Mais en postant une petite douzaine de lignes avec un message disant "Je m'attendais à voir après la ligne 7, mais c'est qui est apparu", vous aurez probablement une réponse.
Si vous voulez simplement une révision de votre code, dites-le clairement, et n'oubliez pas de mentionner quelles parties nécessitent selon vous une révision, et pourquoi.
Les hackers sont bons pour répondre aux problèmes liés aux devoirs, étant donné que la plupart les ont faits eux-mêmes. C'est à vous de répondre à ces questions, pour que vous appreniez par expérience. Il est OK de demander des indices, mais pas la solution complète.
Si vous suspectez avoir affaire à ce genre de question, mais ne pouvez pas la résoudre vous-même, essayez de demander à un forum d'utilisateurs ou (en dernier recours) à une liste/forum d'utilisateurs d'un projet. Même si les hackers vont reconnaître la question, certains des utilisateurs avancés pourront au moins vous donner un indice.
Résistez à la tentation de terminer votre demande d'aide par une question sans intérêt pour la discussion comme "Quelqu'un peut-il m'aider ?" ou "Y a-t-il une réponse à ce problème ?". Premièrement : Si vous avez décrit votre problème de manière correcte, ce genre de phrase est inutile. Deuxièmement : parce qu'elles sont inutiles, les hackers vont les trouver ennuyeuses et risquent de vous envoyer une réponse qui répond à votre question sans vraiment vous aider comme "Oui, quelqu'un peut t'aider" et "Non, il n'y a pas de réponse pour toi".
En général, poser des questions appelant à répondre "oui" ou "non" est une chose à éviter, à moins que ce ne soit la réponse que vous désiriez.
C'est votre problème, pas le nôtre. Prétendre l'urgence sera vraisemblablement contre-productif : les hackers interprètent ces messages comme des tentatives malpolies et égoïstes d'attirer immédiatement l'attention et les effacent.
Il y a une demi-exception. Il peut être utile de préciser que vous utilisez le programme dans un domaine de pointe, dont les hackers seront intéressés ; dans un tel cas, si vous êtes pressé par le temps, et le spécifiez poliment, les gens pourraient être suffisamment intéressés pour vous répondre rapidement.
C'est cependant une chose risquée à faire, car ce qui intéresse les hackers n'est pas forcément ce qui vous intéresse. Poster depuis la Station Spatiale Internationale serait intéressant, par exemple, mais probablement pas poster au nom d'une organisation politique ou de charité pleine de bonnes intentions. En fait, poster un truc du genre : "Urgent! Aidez-moi à sauver les bébés phoques!" ne fera qu'attirer l'ire sur vous, même de la part des hackers qui adorent les bébés phoques.
Si vous trouvez ça bizarre, relisez le reste de ce document jusqu'à ce que vous le compreniez avant de poster quoi que ce soit.
Soyez courtois. Utilisez "S'il vous plaît" et "Merci pour votre attention". Mettez en évidence le fait que vous appréciez le temps que les autres ont passé à vous aider gratuitement.
Pour être honnête, ce n'est pas aussi important (et ne peut en constituer un remplacement) qu'écrire clairement, en évitant les fautes, en étant précis, qu'éviter les formats propriétaires, etc. Les hackers en général vont préférer recevoir des rapports de bugs bruts mais techniquement précis plutôt qu'un flou poli (Si cela vous étonne, rappelez-vous que nous donnons de la valeur aux questions qui nous apprennent quelque chose.)
Cependant, si la technique n'est pas votre fort, la politesse augmente vos chances d'obtenir une réponse utile.
(Notez que la seule objection sérieuse que nous ayons reçue à propos de ce how-to est la recommandation d'utiliser "Merci d'avance". Certains hackers prennent cela comme le fait que vous ne remercierez personne une fois le problème résolu. Notre recommandation est soit de dire "Merci d'avance" en premier et de remercier ceux qui vous répondent, ou d'exprimer la courtoisie de manière différente, par exemple en disant "Merci pour votre attention".)
Envoyez une note une fois que le problème est résolu à tous ceux qui vous ont aidé ; faites-leur savoir comment le problème a été résolu et remerciez-les encore pour leur aide. Si le problème a généré de l'intérêt dans la liste de diffusion ou le newsgroup, il est approprié d'envoyer une telle note.
De manière optimale, votre réponse devrait être dans le même fil de discussion que la question initiale, et devrait avoir le mot 'RESOLU' ou tout autre mot aussi explicite dans le sujet. Sur les listes de diffusion à haut trafic, un lecteur voyant un sujet disant "Problème X" se terminant par "Problème X - RESOLU" sait qu'il ne doit pas perdre son temps sur ce sujet (à moins que le problème X ne l'intéresse) et peut donc s'attaquer à un autre problème.
Votre note n'a pas besoin d'être longue et excessivement reconnaissante ; un simple "Ca y est - c'était en fait un câble réseau défectueux ! Merci a tous. - Bill" sera mieux que rien du tout. En fait, un résumé rapide et sympa sera mieux qu'une longue dissertation à moins que la solution n'ait un véritable intérêt technique.
Pour les problèmes ayant une certaine profondeur, il est approprié de poster un résumé de votre progression vers la solution. Décrivez votre problème final. Décrivez la solution qui a fonctionné, et décrivez les éventuels culs-de-sacs après cela. Les culs-de-sacs doivent venir après la solution et autres résumés du problème, afin d'éviter de transformer le message en thriller à suspense. Nommez les gens qui vous ont aidés - vous vous ferez des amis.
En plus d'être poli et informatif, ce genre de note permet aux prochaines personnes qui cherchent dans les archives de la liste de diffusion/newsgroup/forum de connaître quelle solution vous a aidé et pourrait les aider à leur tour.
Enfin, ce genre de note permet à ceux qui ont participé de sentir que le problème a bien été résolu. Si vous n'êtes pas technicien ou hacker vous-même, croyez-nous, ce sentiment est très important pour les gourous et experts à qui vous avez demandé de l'aide. Les histoires de problèmes qui finissent par ne jamais être résolus sont des choses frustrantes ; les hackers n'en dorment pas tant qu'ils ne sont pas résolus. Si vous leur évitez cela, cela vous sera très utile la prochaine fois que vous aurez besoin de poser une question.
Essayez de prévoir comment vous pouvez éviter aux autres d'avoir le même problème dans le futur. Demandez-vous si un patch dans la documentation ou la FAQ pourrait aider, et si la réponse est oui, envoyez-le au mainteneur.
Parmi les hackers, ce genre de bon comportement est plus important que la politesse brute. En vous comportant ainsi avec les autres, vous vous construirez une bonne réputation, ce qui est un très bon avantage.
Une fois que les réponses arrivent, prenez le temps de bien réagir, en particulier lorsque les cas suivants se présentent.
Il existe une tradition ancienne et sacrée : si vous recevez une réponse contenant "RTFM", la personne qui vous a envoyé cela pense que vous devriez "Read The Fucking Manual" (N.d.T. : Lire Le Putain de Manuel). Et elle a certainement raison. Faites-le.
RTFM a un petit frère. Si vous recevez une réponse contenant "STFW", la personne qui vous a envoyé cela pense que vous auriez dû "Search The Fucking Web" (N.d.T. : Chercher Sur le Putain de Web). Et elle a certainement raison. Faites-le. (De manière plus douce, on peut également vous dire "Google Is Your Friend" - Google est ton ami).
Dans les forums Web, on peut également vous inviter à chercher dans les archives. En fait, une personne pourrait être assez gentille pour vous diriger vers le sujet qui répond à votre question. Mais ne comptez pas là-dessus : faites votre propre recherche.
Souvent, la personne qui vous dit de faire une recherche a le manuel ou la page web avec les informations que vous recherchez devant les yeux, et y regarde pendant qu'elle vous répond. Ces réponses veulent dire que cette personne pense que (a) l'information que vous cherchez est excessivement facile à trouver, et (b) que vous allez en apprendre plus si vous cherchez l'information vous-même au lieu de vous la faire apporter sur un plateau.
Il ne faut pas être offensé par cela ; vis-à-vis des autres hackers, il vous montre une certaine forme de respect simplement par le fait qu'il ne vous ignore pas. Vous devriez au contraire le remercier pour sa trop grande gentillesse.
Si vous ne comprenez pas la réponse, n'expédiez pas immédiatement une demande de clarification. Utilisez les mêmes outils que ceux que vous avez utilisés pour chercher une réponse à votre problème initial (manuels, FAQ, le Web, les amis) pour comprendre la réponse. Si vous devez demander une clarification, montrez ce que vous avez appris.
Par exemple, supposez que je vous dise : "Je dirais que tu as un zentry qui est coincé ; tu devrais le dégager."
Voici une mauvaise réaction : "Euh c'est quoi un zentry ?"
Voici une bonne réaction : "Ok, j'ai regardé la page man et les zentrys ne sont mentionnés que pour les options -z et -p. Aucune de ces options ne parle de dégager les zentrys. Est-ce que c'est l'un de ceux-là ou alors j'ai raté quelque chose ?"
La plupart du temps, ce qui est perçu comme de l'impolitesse dans les propos d'un hacker n'est pas vraiment dit avec l'intention de vous offenser. Il s'agit plutôt du résultat d'un style de communication direct, "ne-perd-pas-ton-temps-en-conneries" qui est naturel pour les gens qui sont plus préoccupés à résoudre les problèmes qu'à être chaleureux avec les autres.
Quand vous sentez que quelqu'un est impoli avec vous, essayez de réagir avec calme. Si quelqu'un dépasse vraiment les bornes, un ancien de la liste, du newsgroup ou du forum va certainement le lui faire savoir. Si cela n'arrive pas et que vous perdez votre calme, alors il est probable que la personne qui vous a mis hors de vous agissait dans les "normes" de la communauté hacker et que la faute retombe sur vous. Cela risque de compromettre grandement vos chances d'obtenir l'information ou l'aide dont vous avez besoin.
D'un autre côté, vous allez de temps en temps être le témoin d'impolitesse gratuite. L'autre facette de ce qui est dit au-dessus est qu'il est tout à fait acceptable de réprimander violemment les vrais fauteurs de troubles, en les remettant à leur place d'une manière bien ficelée. En tout cas, soyez vraiment, vraiment sûr que c'est le cas avant de passer à l'acte. La limite entre corriger une incivilité et déclencher une flamewar inutile est assez fine pour que les hackers eux-mêmes ne s'y risquent pas trop ; si vous êtes un débutant ou quelqu'un de l'extérieur, vos chances de passer à travers sont relativement faibles. Si vous cherchez l'information plus que l'amusement, il vaut mieux éviter de toucher au clavier et ne pas risquer cela.
(Certaines personnes affirment que beaucoup de hackers agissent comme des autistes et qu'il leur manque la partie du cerveau qui gère les relations humaines. Cela peut être vrai ou faux. Si vous n'êtes pas un hacker vous-même, cela peut sans doute vous rassurer de penser que nous sommes des malades mentaux. Allez-y. On s'en fout. Nous aimons être ce que nous sommes, et en général nous réagissons avec un bon scepticisme aux étiquettes qu'on nous colle sur le dos.)
Dans la section suivante, nous allons parler d'un autre problème : le genre d'"impolitesse" que vous verrez lorsque vous vous comportez mal.
Il est probable que vous alliez vous planter un certain nombre de fois sur les forums de la communauté hacker -- de la même manière que ce qui est décrit dans cet article, ou d'une autre manière. Et l'on vous dira exactement comment vous vous êtes plantés, parfois même de manière brutale. Et en public.
Quand cela arrive, la pire chose à faire est de vous lamenter de cette expérience, crier sur tous les toits que vous avez été insulté, réclamer des excuses, pleurer, menacer de retenir votre respiration, engager des poursuites judiciaires, vous plaindre aux employeurs, laisser le siège des toilettes relevé, etc. A la place, voici ce que vous pouvez faire :
Laissez cela passer au-dessus de vous. C'est normal. En fait, c'est salutaire et approprié.
Les règles dans les communautés ne se font pas respecter toutes seules : elles sont maintenues par des gens qui les appliquent à la lettre, de manière visible, en public. Ne vous lamentez pas sur le fait que vous pensez que les critiques auraient dû être envoyées en privé : ça ne fonctionne pas comme ça. Il n'est pas non plus utile d'insister sur le fait que vous avez été personnellement insulté quand quelqu'un dit que l'une de vos affirmations est fausse, ou que son point de vue est différent. Ce sont des attitudes de loser.
Il y a eu des forums de hackers dans lesquels, en raison d'une courtoisie poussée à l'extrême, les participants se faisaient bannir pour avoir simplement critiqué les messages d'autres personnes, et se faisaient dire "Ne dis rien si tu ne veux pas aider l'utilisateur". La fuite des participants-clés qui s'ensuivit a eu pour conséquence de faire descendre ces forums au niveau de babillages et de les rendre inutiles en tant que forums techniques.
Sympathique à l'extrême (dans ce sens) ou utile : Choisissez.
Rappelez-vous : quand un hacker vous dit que vous vous êtes planté, et (peu importe la manière) vous dit de ne pas recommencer, il agit pour (1) vous et (2) sa communauté. Il serait bien plus simple pour lui de vous ignorer et de vous filtrer de sa vie. Si vous ne pouvez pas en être reconnaissant, au moins ayez un peu de dignité, ne vous lamentez pas, et ne vous attendez pas à être traité comme du sucre parce que vous êtes un nouveau venu avec une âme dramatiquement sensible et des fantasmes de reconnaissance.
Parfois, des gens vous attaqueront personnellement, sans raison apparente, même si vous n'avez rien fait de mal (ou fait quelque chose de mal dans leur imagination). Dans ces cas-là, vous plaindre est la meilleure manière d'empirer les choses.
Ces flamers sont soit des lamers qui ne comprennent rien mais s'imaginent être des experts ou des psychologues en herbe et veulent voir si vous allez vous planter. Les autres lecteurs vont les ignorer, ou s'occuper d'eux à leur propre manière. Le comportement des flamers ne crée des problèmes qu'à eux-mêmes, et vous ne devriez pas vous en mêler.
Ne vous laissez pas entraîner dans une guéguerre non plus. La plupart des attaques sont à ignorer -- après avoir vérifié qu'il s'agit vraiment d'attaques, et que votre question a été posée correctement et a été bien comprise (ce qui peut arriver également).
Voici quelques questions stupides usuelles, et ce à quoi les hackers pensent quand ils n'y répondent pas.
Q : Où puis-je trouver le programme X ?
R : Au même endroit que moi, sot -- et sans doute après une bonne recherche sur le Web. C'est pas vrai, il y a encore des gens qui ne savent pas se servir de Google ?
Q : Comment puis-je utiliser X pour faire Y?
R : Si tu veux faire Y, tu devrais poser la question sans présupposer une méthode qui n'est peut-être pas appropriée. Les questions de cette forme indiquent une personne qui n'est pas totalement ignorante de X, mais qui n'a pas bien déterminé le problème Y qu'elle cherche à résoudre et est trop fixée sur les détails d'une situation particulière. Le mieux est d'ignorer ces personnes jusqu'à ce qu'elles définissent mieux leur problème.
Q : Comment puis-je configurer mon invite de commande?
R : Si tu es capable de poser cette question, tu es sans doute capable de faire un petit RTFM pour trouver toi-même la réponse.
Q : Puis-je convertir un document AcmeCorp en fichier TeX en utilisant le convertisseur Bass-o-matic?
R : Tu n'as qu'à essayer. Si tu l'avais fait, tu aurais (a) eu la réponse et (b) évité de gaspiller mon temps.
Q : Mon {programme, configuration, bloc SQL} ne marche pas.
R : Ce n'est pas une question, et je n'ai pas vraiment envie de jouer aux devinettes pour savoir quel est ton vrai problème -- j'ai des choses plus intéressantes à faire.
Quand je vois quelque chose comme cela, ma réaction est en général l'une des suivantes :
Tu n'as rien d'autre à ajouter à cela ?
Ah, quel dommage, j'espère que ça va s'arranger.
Et en quoi cela me concerne-t-il ?
Q : J'ai un problème avec ma machine sous Windows. Vous pouvez m'aider ?
R : Bien sûr. Vire ce déchet de chez Microsoft, et installe Linux.
Note : Vous pouvez poser des questions en rapport avec les machines sous Windows si elles concernent un programme qui a un binaire Windows officiel, ou qui interagit avec des machines Windows (ex : Samba). Ne soyez cependant pas surpris si la réponse est que le problème vient de Windows, car Windows est tellement mal foutu que c'est souvent le cas.
Q : Mon programme ne marche pas. Je pense qu'il y a un problème avec l'appel système X.
R : Même s'il est techniquement possible que tu sois la première personne à remarquer une déficience évidente dans des appels systèmes utilisés par des centaines de milliers de personnes, il est bien plus probable que tu n'aie rien compris. Des affirmations extraordinaires nécessitent d'être appuyées par des preuves ; si vous faites une telle remarque, vous devez la soutenir avec des informations sur les cas qui mettent la déficience en évidence.
Q : J'ai des problèmes pour installer Linux ou X. Vous pouvez m'aider ?
R : Non, j'aurais besoin d'avoir un accès physique à ta machine pour cela. Va plutôt demander à ton LUG local pour une aide plus proche. (Vous pouvez trouver une liste de groupes d'utilisateurs (LUG) ici).
Note : les questions sur l'installation de Linux peuvent être appropriées si vous êtes sur un forum ou une liste de diffusion d'une distribution particulière, et que ce problème concerne cette distribution ; ou sur un forum de groupe d'utilisateurs. Dans ce cas, soyez sûr de décrire les détails du problème. Mais faites une recherche avant, sur "linux" et toutes les pièces matérielles suspectes.
Q : Comment est-ce que je peux obtenir les droits root/récupérer les ops sur un channel/lire l'email de quelqu'un ?
R : T'es vraiment désespéré pour vouloir faire de telles choses et un vrai crétin pour demander à un hacker de t'aider.
Pour terminer, je vais illustrer comment poser des questions de manière intelligente avec des exemples ; des paires de questions à propos du même problème, l'une posée de manière stupide, l'autre de manière intelligente.
Stupide :
Où puis-je trouver des infos sur le Foonly Flurbamatic ?
Cette question ne mérite pas plus qu'un STFW comme réponse.
Intelligent :
J'ai utilisé Google pour chercher "Foonly Flurbamatic 2600" sur le Web, mais je n'ai rien trouvé d'intéressant. Quelqu'un sait où je pourrais trouver des informations utiles pour ce périphérique ?
Cette personne a déjà STFW, et son problème semble réel.
Stupide :
Je n'arrive pas à compiler le code du projet foo. Pourquoi ne marche-t-il pas ?
Le demandeur assume que la faute vient de quelqu'un d'autre. C'est très arrogant de sa part.
Intelligent :
Le code du projet foo ne compile pas sous Nulix version 6.2. J'ai lu la FAQ, mais il n'y a rien à propos des problèmes avec Nulix. Voici une transcription de ma tentative de compilation ; y a-t-il quelque chose que j'aurais dû faire ?
Il a indiqué son environnement, a lu la FAQ, montré l'erreur, et ne prétend pas que son problème est dû à une erreur de quelqu'un d'autre. Voila quelqu'un qui mérite de l'attention.
Stupide :
J'ai des problèmes avec ma carte mère. Vous pouvez m'aider ?
La réponse du hacker moyen à cela sera sans doute quelque chose comme "C'est ça, et tu ne veux pas 100 balles et un mars non plus ?" suivi d'une série de caractères de la touche "Suppr".
Intelligent :
J'ai essayé X, Y et Z sur la carte mère modèle S2464. Cela n'a pas marché, alors j'ai essayé A, B et C. Notez bien le symptôme assez curieux quand j'ai essayé C. De toute évidence, le florb a l'air de grommicker, mais les résultats ne sont pas ceux auxquels on pourrait s'attendre. Quelles sont les causes qui amènent la carte mère MP à grommicker ? Quelqu'un a des idées à propos de tests que je pourrais effectuer pour comprendre le problème ?
Cette personne, au contraire, semble mériter une réponse. Elle a montré qu'elle était capable de résoudre un problème par elle-même au lieu d'attendre que la réponse tombe du ciel.
Dans la dernière question, notez la différence subtile mais importante entre "Donnez-moi une réponse" et "Merci de m'aider à trouver quels tests je pourrais effectuer pour trouver la réponse".
En fait, la forme de cette dernière question est basée sur un incident réel qui est arrivé en août 2001 sur la liste de diffusion du noyau Linux. J'avais (Eric) posé la question. Une carte mère Tyan S2464 plantait mystérieusement. Les membres de la liste m'ont donné les informations dont j'avais besoin pour résoudre le problème.
En posant la question de la manière dont je l'ai fait, j'ai donné aux gens quelque chose sur lequel ils pouvaient réfléchir ; je les ai encouragés à s'intéresser au problème qui était devenu attractif pour eux. J'ai montré du respect pour l'habileté de mes pairs et les ai invités à me considérer comme l'un d'eux. J'ai également montré du respect pour leur temps en leur expliquant par où j'étais déjà passé.
Une fois le problème résolu, quand j'ai remercié tout le monde et émis la remarque que le processus fonctionnait vraiment bien, un membre de la liste a dit qu'il pensait que cela avait marché non pas parce que je suis connu sur cette liste, mais parce que j'ai posé la question comme il le fallait.
Les hackers vivent dans une impitoyable méritocratie ; je suis sûr qu'il avait raison, et que si je m'étais comporté comme un parasite je me serais fait engueuler ou ignorer, peu importe qui j'étais. Sa suggestion de décrire l'incident au complet en tant qu'aide pour d'autres m'a directement amené à écrire ce guide.
Si vous ne pouvez pas obtenir de réponse, ne le prenez pas personnellement, comme si nous ne voulions pas vous aider. Parfois, les membres du groupe auxquels vous posez votre question peuvent ne pas connaître la réponse. Pas de réponse ne veut pas dire que vous avez été ignoré, bien que j'avoue qu'il est difficile de faire la différence.
En général, re-poser votre question est une mauvaise idée. Cela sera perçu comme ennuyeux. Soyez patient : la personne avec votre réponse se trouve peut-être dans un autre fuseau horaire ou dort peut-être. Ou peut-être que la question n'était pas bien formulée.
Il y a d'autres sources d'informations vers lesquelles vous pouvez vous diriger, et bien souvent ces sources sont plus adaptées aux besoins d'un débutant.
Il y a beaucoup de groupes d'utilisateurs, en ligne ou localement, qui sont très enthousiastes à propos des logiciels, même s'ils n'ont pas forcément écrit de logiciels eux-mêmes. De tels groupes se forment souvent pour que les gens puissent s'aider les uns les autres et aider les nouveaux utilisateurs.
Il y a également beaucoup de sociétés commerciales auxquelles vous pouvez demander de l'aide, des grandes comme des petites (Red Hat et LinuxCare sont les deux plus connues ; il y en a plein d'autres). Ne soyez pas consterné à l'idée que vous deviez payer pour avoir un peu d'aide ! Après tout, si le moteur de votre voiture coule une bielle, il y a de grandes chances pour que vous deviez l'amener chez un garagiste et payer pour qu'elle soit réparée. Même si le logiciel ne vous a rien coûté, il ne faut pas vous attendre à ce que le support soit toujours gratuit.
Pour les systèmes populaires comme Linux, il y a au moins 10000 utilisateurs par développeur. Il est tout simplement impossible pour une personne de gérer les appels à l'aide de plus de 10000 utilisateurs. Rappelez-vous que même si vous devez payer pour le support, vous devrez toujours payer bien moins cher que si vous aviez dû acheter le logiciel également (et le support pour les logiciels propriétaires est souvent plus cher et moins compétent que le support pour les logiciels open source).
Soyez gentil. Le stress ajouté aux problèmes peut rendre les gens impolis ou stupides même quand ils ne le sont pas.
Répondez à quelqu'un qui faute pour la première fois hors ligne. Il n'est pas nécessaire d'humilier publiquement quelqu'un qui a fait une erreur honnête. Un vrai débutant ne sait peut-être pas chercher dans les archives, ni où se trouve la FAQ.
Si vous n'êtes pas sûr, précisez-le! Une réponse fausse et assurée est pire que pas de réponse du tout. N'envoyez pas quelqu'un dans la mauvaise direction parce que c'est cool d'avoir l'air de s'y connaître. Soyez humble et honnête ; donnez le bon exemple pour la personne qui pose la question et vos pairs.
Si vous ne pouvez pas aider, n'entravez pas. Ne faites pas de plaisanteries sur des procédures qui pourraient casser le système de l'utilisateur -- le pauvre gars pourrait les interpréter comme des instructions à suivre.
Posez des questions pour obtenir plus de détails. Si vous le faites bien, la personne qui demande apprendra quelque chose -- et vous aussi. Essayez de transformer la mauvaise question en bonne question ; rappelez-vous qu'on a tous été un jour débutant.
Même si hurler un RTFM est parfois justifié quand on répond à un fainéant, un pointeur vers la documentation (même s'il s'agit juste de mots-clés Google) est toujours meilleur.
Si vous pouvez répondre à la question, donnez une bonne réponse. Ne suggérez pas des bidouillages infâmes quand quelqu'un utilise la mauvaise approche ou le mauvais outil. Suggérez d'autres outils. Reformulez la question.
Aidez votre communauté à apprendre de la question. Quand vous repérez une bonne question, demandez-vous "Comment la documentation ou la FAQ devrait-elle changer pour que personne n'ait à se reposer cette question?". Puis envoyez un patch au mainteneur de la documentation.
Si vous avez fait des recherches pour répondre à la question, démontrez vos talents plutôt que de faire comme si vous aviez sorti la réponse de votre cul. Répondre à une bonne question est comme donner un poisson à quelqu'un, mais enseigner comment résoudre son problème soi-même est comme lui apprendre à pêcher.