Hoe vragen te stellen op de verstandige manier

Een Nederlandse vertaling van:

"How To Ask Questions The Smart Way" door:

Eric Steven Raymond

Rick Moen


    
    

Vertaald door: Jasper Vries (contact)
Vertaling gebaseerd op Revision 3.10, 21 May 2014, vertaling laatst herzien op 25 februari 2017.
Link naar het originele document: http://catb.org/~esr/faqs/smart-questions.html.


Inhoudsopgave

Vertalingen
Disclaimer
Inleiding
Voordat je een vraag stelt
Als je een vraag stelt
Kies je forum zorgvuldig
Stack Overflow
Web- en IRC forums
Als een tweede stap, gebruik mailinglijsten van projecten
Gebruik betekenisvolle, specifieke onderwerpregels
Maak het makkelijk om te reageren
Schrijf in heldere, grammaticaal correct gespelde taal
Verzend vragen in toegankelijke standaardformaten
Ben precies en informatief over je probleem
Hoeveelheid is niet precisie
Beweer niet te snel dat je een fout gevonden hebt
Nederig zijn is geen vervanging voor het doen van je huiswerk
Beschrijf de symptomen van het probleem, niet je vermoedens
Beschrijf de symptomen van je probleem in chronologische volgorde
Beschrijf het doel, niet de stap
Vraag niet om antwoord te krijgen via (privé) e-mail
Stel een duidelijke vraag
Wanneer je een vraag stelt over code
Plaats geen huiswerkopgaven
Vermijd doelloze vragen
Markeer je vraag niet als Urgent, ook al is het dat voor jou
Beleefdheid doet geen pijn, en soms helpt het
Plaats aansluitend een korte reactie op de oplossing
Hoe men antwoorden interpreteert
RTFM en STFW: Hoe men aangeeft dat je het behoorlijk verkeerd gedaan hebt
Als je het niet begrijpt...
Omgaan met grofheid
Over het niet reageren als een loser
Vragen die men niet moet stellen
Goede en slechte vragen
Als je geen antwoord krijgt
Vragen op een helpvolle manier beantwoorden
Aanverwante zaken
Dankwoord

Vertalingen

Vertalingen: Bahasa Indonesian Belorussian Brazilo-Portuguese Bulgarian Chinese (Traditional) Croatian Dutch French Georgian German Greek Hindi Irish Gaelic Japanese Lithuanian Polish Portuguese Romanian Russian Serbian Spanish Uzbek Als je dit doucment wilt kopiëren, dupliceren, vertalen of eruit wilt citeren, bekijk dan de copying policy.

Disclaimer

Veel projectwebsites linken naar dit document in hun help-secties. Dat is prima, dat is ook waarvoor we het bedoeld hebben — maar wanneer je als webmaster zo'n link plaatst voor je projectpagina, vermeld dan alsjeblieft duidelijk bij de link dat wij geen helpdesk voor je project zijn!

We hebben op de harde manier moeten ondervinden dat we, zonder zulke vermelding, herhaaldelijk worden lastig gevallen door idioten die denken dat het onze taak is de technische problemen van de hele wereld op te lossen, omdat we dit document gepubliceerd hebben.

Als je dit document leest omdat je hulp nodig hebt, en je de indruk hebt dat je deze direct van de auteurs van dit document kunt krijgen, dan ben jij één van de idioten waar we het over hebben. Stel ons geen vragen. We zullen je gewoonweg negeren. We zijn hier om je te laten zien hoe je hulp kunt krijgen van mensen die echt verstand hebben van de software of hardware waar je problemen mee hebt, maar 99% van de tijd zijn wij dat niet. Behalve als je zeker weet dat een van de auteurs een kenner is op het gebied van waar je mee bezig bent, laat ons dan met rust en iedereen is gelukkiger.

Inleiding

In de wereld van hackers, hangt het soort antwoord dat je krijgt op je technische vragen net zoveel af van de manier waarop je je vraag stelt als van de moeilijkheidsgraad van het opstellen van een antwoord. Deze handleiding leert je hoe je vragen moet stellen opdat het meer voor de hand ligt dat je een bevredigend antwoord krijgt.

Nu dat het gebruik van open source gemeengoed is geworden, kun je vaak net zo goede antwoorden krijgen van andere ervaren gebruikers als van hackers. Dit is een Goede Zaak; gebruikers zijn vaak net wat toleranter met de fouten die nieuwkomers vaak maken. Desalniettemin, het behandelen van ervaren gebruikers alsof ze hackers zijn op de manier zoals hier beschreven, is meestal ook de meest effectieve manier om antwoorden van hen te krijgen.

Allereerst moet je inzien dat hackers moeilijke problemen en goede, aan het denken zettende, vragen daarover leuk vinden. Als we er niets aan vonden, zouden we er niet zijn. Als je ons een interessante vraag om op te kauwen geeft, zijn we je dankbaar; goede vragen zijn stimulerend en voor ons een geschenk. Goede vragen helpen onze kennis te ontwikkelen en onthullen vaak problemen die we nog niet gemerkt hadden of waar we anders over dachten. Onder hackers is Goede vraag! een sterk en oprecht compliment.

Desondanks hebben hackers de reputatie vijandig of arrogant op eenvoudige vragen te reageren. Soms lijkt het dat we grof zijn tegen nieuwelingen en onwetenden, maar dat is niet echt waar.

We zijn, zonder excuus, vijandig tegenover mensen waarvan het lijkt dat ze niet willen nadenken of hun huiswerk niet hebben gedaan voordat ze een vraag stellen. Zulke mensen zijn als een bodemloze put — ze nemen zonder te geven, en verspillen tijd die we hadden kunnen besteden aan meer interessante vragen en aan iemand die wel een antwoord waard is. We noemen deze mensen losers (Engels; verliezers) (en om historische redenen spellen we het soms als lusers).

We begrijpen dat er veel mensen zijn die de software die we schrijven alleen maar willen gebruiken en geen interesse hebben in de technische details. Voor de meeste mensen is de computer niets meer dan een hulpmiddel om een doel te bereiken; ze hebben belangrijker dingen te doen en levens te leven. We erkennen dat en verwachten niet dat iedereen interesse moet hebben in de technische zaken die ons fascineren. Toch is onze stijl van het beantwoorden van vragen toegespitst op mensen die wel geïnteresseerd zijn en bereid zijn actief deel te nemen in de probleemoplossing. Dat zal niet veranderen. Het moet ook niet veranderen; want dan zouden we minder effectief zijn met de dingen waar we goed in zijn.

We zijn (in het algemeen) vrijwilligers. We nemen tijd uit onze drukke levens om vragen te beantwoorden en soms worden we erdoor overspoeld. Dus filteren we meedogenloos. In het bijzonder gooien we vragen weg van mensen die losers lijken te zijn, zodat we onze vragen-beantwoord-tijd meer efficiënt kunnen besteden, aan winnaars.

Als je deze houding aanstootgevend, verwaand of arrogant vindt, ga dan even je veronderstellingen na. We vragen niet om voor ons te buigen — de meeste van ons willen niets liever dan als een gelijke met je omgaan en je verwelkomen in onze cultuur, als je maar de moeite neemt dat mogelijk te maken. Maar het is simpelweg niet efficiënt voor ons om mensen te helpen die zelf niet willen helpen. Het is OK om onwetend te zijn; het is niet OK om je van de domme te houden.

Het is dus niet nodig om technisch onderlegd te zijn om aandacht van ons te krijgen, maar het is nodig om een houding aan te nemen die leidt naar kennis van zaken — alert, nadenkend, opmerkzaam, bereid zijn om een actieve partner te zijn in het zoeken naar een oplossing. Als je je niet kunt vinden in deze vorm van discriminatie, raden we je aan om iemand te betalen voor een commercieel ondersteuningscontract in plaats hackers te vragen om persoonlijk hulp aan je te doneren.

Als je besluit ons om hulp te vragen, wil je niet een van de losers zijn. Je wil ook niet dat je erop lijkt. De beste manier om een snel en bruikbaar antwoord te krijgen is het stellen van een vraag als een persoon met kennis, vertrouwen en ideeën die toevallig hulp nodig heeft met een specifiek probleem.

(Verbeteringen aan deze handleiding zijn welkom. Je kunt suggesties mailen naar de auteurs (van het originele Engelstalige document): esr@thyrsus.com of respond-auto@linuxmafia.com. Merk op dat dit document geen algemene handleiding met betrekking tot de netiquette is, en dat we normaal gesproken suggesties zullen negeren die niet gericht zijn op het verkrijgen van bruikbare antwoorden op technische forums.)

Voordat je een vraag stelt

Voordat je een technische vraag stelt via e-mail, in een nieuwsgroep of op een forum, volg onderstaande stappen:

  1. Probeer een antwoord te vinden middels het doorzoeken van de archieven van het forum of de mailinglijst waarin je een vraag wilt stellen.

  2. Probeer een antwoord te vinden door te zoeken op het Web.

  3. Probeer een antwoord te vinden door het lezen van de handleiding.

  4. Probeer een antwoord te vinden door het lezen van een FAQ (lijst met veel gestelde vragen).

  5. Probeer een antwoord te vinden door te onderzoeken of te experimenteren.

  6. Probeer een antwoord te vinden door een vraag te stellen aan een bekwame vriend.

  7. Als je een programmeur bent, probeer een antwoord te vinden door het lezen van de broncode.

Als je een vraag stelt, laat dan zien dat je bovenstaande dingen gedaan hebt; hiermee toon je dat je geen luie vlegel bent die andermans tijd loopt te verspillen. Nog beter, laat zien wat je hebt geleerd door het doen van deze dingen. We beantwoorden graag vragen van mensen die laten zien dat ze ook daadwerkelijk kunnen leren van de antwoorden.

Gebruik tactieken zoals het doen van een Google zoekopdracht naar de tekst of de foutmelding die je krijgt (zoek in Google Discussiegroepen en ook op het Web). Dit brengt je misschien wel direct naar de oplossing van je probleem. Maar al krijg je geen geschikte resultaten, het zeggen van “Ik heb gegoogeld op de volgende zoekwoorden, maar ik kreeg geen hoopvolle resultaten” is een goede zaak in bij het vragen om hulp, het geeft in ieder geval aan welke zoekopdrachten geen nut hebben. Het helpt ook om anderen met een vergelijkbaar probleem om jouw probleemomschrijving te vinden, door dat de zoektermen worden gekoppeld aan jouw probleem en hopelijk een oplossing.

Neem de tijd. Verwacht niet een ingewikkeld probleem op te lossen met een paar seconden Googelen. Lees en begrijp de veel gestelde vragen (FAQ's), leun achterover, ontspan en overdenk het probleem voordat je de experts benadert. Geloof ons, ze kunnen uit je vraag aflezen hoeveel je gelezen en gedacht hebt en zijn meer bereid te helpen als je je voorbereid hebt. Vuur niet gelijk je hele arsenaal vragen af alleen omdat je eerste zoekpoging geen resultaten opleverde (of teveel).

Bereid je vraag voor. Overdenk hem. Haastige vragen krijgen haastige antwoorden, of zelfs geen. Hoe meer je laat zien dat je een oplossing hebt proberen te vinden en er moeite in hebt gestoken voordat je hulp zoekt, hoe groter de kans dat je ook daadwerkelijk hulp krijgt.

Pas op met het stellen van de verkeerder vraag. Als je een vraag stelt gebaseerd op verkeerde aannames, zal J. Random Hacker waarschijnlijk antwoorden met een nutteloos letterlijk antwoord terwijl hij denkt Domme vraag..., in de hoop dat het krijgen waarom je gevraagd hebt in plaats van een bruikbaar antwoord je een lesje leert.

Ga er nooit van uit dat je recht hebt op een antwoord. Dat heb je niet, je betaalt immers ook niet voor de dienst. Je krijgt een antwoord als je het verdient, door het stellen van een inhoudelijke, interessante en goed doordachte vraag — een die impliciet bijdraagt aan de ervaring van de gemeenschap, in plaats van het passief misbruiken van de kennis van anderen.

Aan de andere kant, laten zien dat je bereid bent om mee te werken in het proces van het vinden van een oplossing is een goed begin. Kan iemand me op weg helpen?, Wat ontbreekt er in mijn voorbeeld? en Welke site moet ik bekijken? maken meer kans om een antwoord te krijgen dan Geef me alsjeblieft de exacte stappen die ik moet volgen., omdat je duidelijk maakt dat je echt bereid bent om je probleem proberen op te lossen als iemand je alleen al in de juiste richting wijst.

Als je een vraag stelt

Kies je forum zorgvuldig

Kies de plaats waar je je vraagt stelt zorgvuldig. Je wordt waarschijnlijk genegeerd of afgeschreven als een loser als je:

  • je vraag stelt in een forum bedoeld voor andere onderwerpen

  • een beginnersvraag stelt in een forum waar uitgebreide technische vragen verwacht worden, of omgekeerd

  • je dezelfde vraag in te veel verschillende nieuwsgroepen tegelijk stelt

  • een persoonlijke e-mail stuurt aan iemand die geen bekende van je is en ook niet persoonlijk verantwoordelijk voor het oplossen van je probleem

Hackers schieten vragen af die ongepast zijn, om hun communicatiekanalen te beschermen tegen een overvloed aan irrelevantie. Je wil niet dat dit met je gebeurt.

De eerste stap is dan ook om het juiste forum te vinden. Ook hier zijn Google en andere methoden om het web te doorzoeken je vriend. Gebruik ze om de website van het project te vinden dat het meest gerelateerd is aan de hardware of software waarmee je problemen hebt. Normaal gesproken heeft deze website links naar een FAQ-lijst (Frequently Asked Questions, Veel Gestelde Vragen), en naar mailinglijsten van het betreffende project en bijbehorende archieven. Deze mailinglijsten zijn de laatste plaats waar je hulp moet zoeken als je er op eigen kracht (inclusief het lezen van de FAQ's) niet uit komt. De projectpagina kan ook de procedure beschrijven over het rapporteren van fouten, of een link ernaar toe hebben; volg deze als dat het geval is.

Een email afvuren op een persoon of forum waarmee je niet bekend bent is om z'n minst risicovol. Ga er bijvoorbeeld niet van uit dat de auteur van een informatieve website je gratis raadgever wil zijn. Doe geen optimistische aannames over of je vraag welkom zal zijn — als je twijfelt, stel je vraag ergens anders, of stel hem helemaal niet.

Als je een forum, nieuwsgroep of mailinglijst uitkiest, vertrouw dan niet alleen op de naam ervan; zoek naar een FAQ of probeer na te gaan of je vraag in het onderwerp past. Lees enkele bestaande berichten zodat je gevoel krijgt over hoe zaken er aan toe gaan. Het is zelfs een heel goed idee om te zoeken naar sleutelwoorden die te maken hebben met je probleem in de archieven van de nieuwsgroep of mailinglijst voordat je je vraag stelt. Je kunt het antwoord soms al direct vinden, en zo niet zal het je helpen een betere vraag te formuleren.

Vuur je vraag niet af op alle hulpkanalen tegelijkertijd, dat wordt gezien als schreeuwen en irriteert mensen. Loop ze stap voor stap door.

Weet wat je onderwerp is! Een van de klassieke fouten is het stellen van vragen over de Unix of Windows programmeer interface in een forum toegeschreven op een programmeertaal, bibliotheek of hulpprogramma geschikt voor beide platformen. Als je niet weet waarom dit een fout is, kun je beter geen vragen stellen totdat je door hebt waarom.

In het algemeen is de kans groter om bruikbare antwoorden te krijgen op een goed uitgekozen publiek forum dan op private forums. Hiervoor zijn meerdere redenen. Enerzijds is dat de hoeveelheid potentiële respondenten. Anderzijds is dat de grootte van het publiek; hackers beantwoorden veel liever vragen waar veel mensen iets aan zouden kunnen hebben.

Begrijpelijk is dat bekwame hackers en auteurs van populaire software nu al veel te veel misplaatste berichten ontvangen. Door bij te dragen aan deze vloedgolf, zou je de druppel kunnen zijn die de emmer doet overlopen — meer dan eens hebben mensen die bijdragen aan populaire projecten hun steun ingetrokken omdat de hoeveelheid nutteloze e-mail in hun postvakken ondraaglijk werd.

Stack Overflow

Zoek, vraag daarna pas op Stack Exchange

In de afgelopen jaren zijn de gezamenlijke Stack Exchange-website een belangrijk platform geworden voor het beantwoorden van technische en andere vragen. Het is zelfs de voorkeurslocatie voor veel open-source projecten.

Begin met zoeken via Google, voordat je naar Stack Exchange kijkt; Google indexeert het voortdurend. Grote kans dat iemand al een vergelijkbare vraag heeft gesteld, en de Stack Exchange websites staan meestal bovenaan in de zoekresultaten. Als je niks kon vinden via Google, zoek dan op de specifieke website die het best bij je probleem past (zie hieronder). Zoeken met tags kan helpen om de zoekresultaten te beperken.

Heb je nog steeds niks gevonden, stel dan je vraag op één site waar deze het meest relevant is. Gebruik de opmaakhulpmiddelen, in het bijzonder voor code, en voeg tags toe die verband houden met de kern van de vraag (specifiek de naam van de programmeertaal, besturingssysteem of bibliotheek waar je problemen mee hebt). Wanneer iemand die reageert vraag om meer informatie, neem dat dan op in je oorspronkelijke bericht. Als een antwoord bruikbaar is, klik dan op de naar boven wijzende pijl om aan te geven dat het een nuttig antwoord is. Als het antwoord een oplossing geeft voor je probleem, klik dan op het vinkje onder de pijlen om aan te geven dat dit het goede antwoord is.

Stack Exchange is uitgegroeid tot meer dan 100 sites, maar waarschijnlijk is het een van deze:

  • Super User is voor algemene computervragen. Wanneer je vraag niet gaat over code of programma's waarmee je alleen praat via een netwerkverbinding, hoort hij waarschijnlijk hier thuis.

  • Stack Overflow is voor vragen over programmeren.

  • Server Fault is voor vragen over server- en netwerkbeheer.

Veel projecten hebben hun eigen specifieke sites, zoals Android, Ubuntu, TeX/LaTeX, en SharePoint. Bekijk de Stack Exchange site voor een actuele lijst.

Web- en IRC forums

Je lokale gebruikersgroep, of je Linux distributie, kan je aanbevelen een forum of IRC kanaal te bezoeken waar nieuwkomers om hulp kunnen vragen. (In niet-Engelstalige landen zijn forums voor nieuwkomers nog vaak mailinglijsten.) Dit is een goede eerste plaats om je vraag te stellen, vooral als je denkt dat je bent gestruikeld over een relatief eenvoudig of vaak voorkomend probleem. Een aanbevolen IRC kanaal is een open uitnodiging om daar vragen te stellen en vaak direct antwoord te krijgen.

Als je problemen hebt met een programma dat werd geleverd met een Linux distributie (zoals dat tegenwoordig veel voorkomt), is het beter om je vraag te stellen in het forum/mailinglijst van de distributie dan in het forum/mailinglijst van het programma. De hackers van het project zeggen vaak alleen gebruik onze versie.

Voordat je in een forum een vraag stelt, kijk of er een zoekfunctie aanwezig is. Zo ja, probeer een aantal sleutelwoorden; het zou zomaar kunnen helpen. Als je een algemene web-zoekopdracht heb gedaan (zoals je zou moeten), zoek dan evengoed in het forum; je internetzoekmachine heeft wellicht niet het hele forum recent geïndexeerd.

Er is een groeiende tendens voor projecten om ondersteuning voor gebruikers af te handelen via een forum of IRC kanaal, en e-mail gereserveerd wordt voor ontwikkel-verkeer. Zoek naar deze kanalen wanneer je project-specifieke hulp zoekt.

Binnen IRC is het waarschijnlijk beter om niet meteen een lange probleemomschrijving te geven. Dit wordt door sommigen beschouwd als dat je het IRC-kanaal overspoelt. Het is beter om in één zin een probleemomschrijving te geven op een manier die het gesprek binnen het kanaal op gang kan brengen.

Als een tweede stap, gebruik mailing lijsten van projecten

Als een project een ontwikkel-mailinglijst heeft, schrijf dan de mailinglijst aan en niet de individuele ontwikkelaars, ook al denk je dat je weet wie jou het best kan antwoorden. Bekijk de documentatie van het project en de homepage voor het adres van de project-mailinglijst en gebruik het. Er zijn verschillende goede redenen hiervoor:

  • Elke vraag die goed genoeg is om aan een van de ontwikkelaars te stellen zal ook van waarde zijn voor de hele groep. Andersom, als je denkt dat je vraag te dom is voor een mailinglijst, is dat geen excuus om de individuele ontwikkelaars daarmee lastig te vallen.

  • Het stellen van een vraag via de lijst verdeelt de belasting over de ontwikkelaars. De individuele ontwikkelaar (vooral als hij de leider van het project is) kan te druk zijn om je vraag te beantwoorden.

  • De meeste mailinglijsten worden gearchiveerd en de archieven geïndexeerd door zoekmachines. Als je je vraag via de lijst stelt en deze wordt beantwoord, kan iemand in de toekomst je vraag en het antwoord op internet vinden in plaats van hem opnieuw te stellen.

  • Als specifieke vragen vaak worden gesteld, kunnen ontwikkelaars ze gebruiken om de documentatie of de software te verbeteren. Als deze vragen privaat worden gesteld heeft niemand een compleet beeld van welke vragen het meest gesteld worden.

Als een project een gebruikers- en een ontwikkelaars- (of hacker-) mailinglijst of forum heeft, en je hackt niet in de broncode, stel je vraag in de gebruikerslijst/forum. Ga er niet van uit dat je welkom bent op de ontwikkelaarslijst, waar ze je vraag waarschijnlijk zien als ruis in het ontwikkelverkeer.

Echter, als je zeker weet dat je vraag niet-triviaal is en je geen antwoord krijgt in de gebruikerslijst/forum gedurende enkele dagen, probeer de ontwikkelaarsvariant. We raden je aan om daar enkele dagen mee te lezen of in ieder geval enkele dagen aan gearchiveerde berichten terug te lezen voordat je een bericht plaatst, zodat je bekend bent met de gang van zaken (dit is overigens aan te raden bij alle private of semi-private lijsten).

Als je het adres van de mailinglijst van het project niet kunt vinden, maar je ziet alleen het adres van de beheerder van het project, ga dan je gang en schrijf de beheerder aan. Maar zelfs in dit geval, ga er niet van uit dat de mailinglijst niet bestaat. Vertel in je email dat je ernaar gezocht hebt maar er geen hebt kunnen vinden. Vermeld ook dat je er geen bezwaar tegen hebt dat je bericht wordt doorgestuurd naar anderen. (Veel mensen zijn van mening dat een private email privaat moet blijven, ook al staat er niets geheims in. Door het toestaan dat je bericht wordt doorgestuurd geef je je correspondent een keuze over hoe je e-mail af te handelen.)

Gebruik betekenisvolle, specifieke onderwerpregels

In mailinglijsten, nieuwsgroepen of forums is de onderwerpregel je uitgelezen kans om in ongeveer 50 tekens de aandacht van gekwalificeerde experts te trekken. Verspil het niet aan gebral als Help me alsjeblieft (of nog erger HELP ME!!!!; berichten met zulke koptekst worden in een reflex verwijderd). Probeer ons niet te imponeren met de grootte van je pijnen; gebruik de ruimte voor een korte omschrijving van je probleem.

Een nuttige conventie, die door vele ondersteuningsorganisaties wordt aangehouden, is voorwerp - afwijking. Het voorwerp-deel specificeert welk ding of welke groep van dingen een probleem geeft, en het afwijking-deel beschrijft de afwijking van verwachte gedrag.

Dom:

HELP! Beeld werkt niet goed op mijn laptop!

Slim:

X.org 6.8.1 misvormde muiscursor, Fooware MV1005 vid. chipset

Slimmer:

X.org 6.8.1 muiscursor met Fooware MV1005 vid. chipset - is misvormd

Het proces van het schrijven van een voorwerp - afwijking omschrijving zal je helpen je gedachten over het probleem nauwkeuriger op een rij te krijgen. Wat betreft het? Alleen de muiscursor of ook andere grafische elementen? Komt dit alleen voor op de X.org versie van X? Of versie 6.8.1? Is het specifiek aan de Fooware video chipset? Type MV1005? Een hacker kan hierdoor direct zien waarmee je een probleem hebt en wat het probleem is, in één oogopslag.

In het algemeen, stel je de inhoudsopgave van een vragenarchief met alleen onderwerpregels voor. Laat je onderwerpregel je vraag dusdanig weerspiegelen zodat de volgende die de archieven doorzoekt met een vergelijkbare vraag de draad kan oppakken in plaats van dezelfde vraag opnieuw te stellen.

Als je een vraag stelt in een reactie, pas dan de onderwerpregel aan om aan te geven dat je een vraag stelt. Een onderwerpregel als Re: test of Re: nieuwe fout trekt weinig aandacht. Beperk ook het aantal citaten uit voorgaande berichten tot een noodzakelijk minimum waaruit nieuwe lezers kunnen afleiden waar het over gaat.

Klik niet simpelweg op beantwoorden om een geheel nieuwe discussie in een mailinglijst te starten. Dit beperkt je publiek. Sommige mailprogramma's, zoals mutt, geven de gebruiker de mogelijkheid te sorteren op onderwerp om vervolgens de berichten in een onderwerp te verbergen door het onderwerp in te klappen. Mensen die dat doen zullen je bericht nooit zien.

Het onderwerp aanpassen is niet voldoende. Mutt, en waarschijnlijk ook andere mailprogramma's kijken naar andere informatie in de headers van het emailbericht om het toe te wijzen aan een onderwerp, niet naar de onderwerpregel. Start dus een compleet nieuwe e-mail.

Op webforums zijn de regels van goed gebruik enigszins verschillend, omdat berichten meestal sterk gebonden zijn aan een specifieke discussie en onzichtbaar buiten die discussie. Het veranderen van het onderwerp in een reactie is niet essentieel. Het is zelfs zo dat niet alle forums de mogelijkheid hebben een apart onderwerp voor een reactie in te geven, en vrijwel niemand leest ze als het wel kan. Het stellen van een vraag in een reactie is sowieso twijfelachtig, omdat het alleen wordt gelezen door de mensen die de discussie volgen. Dus, start een nieuwe discussie, tenzij je zeker weet dat je vraag alleen wilt stellen aan de mensen die nu betrokken zijn in die discussie.

Maak het makkelijk om te reageren

Je vraag besluiten met Stuur je reacties naar... maakt het onwaarschijnlijk dat je een antwoord krijgt. Als je niet een paar seconden de moeite wilt nemen om het antwoordadres correct in te stellen in je mailprogramma, kun je niet van ons verlangen dat we ook maar een paar seconden over je probleem nadenken. Als je mailprogramma dat niet ondersteunt, neem een betere. Als je besturingssysteem geen mailprogramma's ondersteunt die dit toelaten, neem een beter besturingssysteem.

Op webforums is het vragen om reacties via e-mail buitengewoon grof, tenzij je denk dat de informatie gevoelig kan zijn (en iemand, om onbekende reden, deze informatie wel aan jou kenbaar wil maken, maar niet aan de rest van het forum). Als je een e-mailbericht wilt ontvangen zodra iemand op je vraag gereageerd heeft, stel dat dan op het forum in; deze functie wordt vrijwel overal ondersteund onder opties als abonneer op dit onderwerp, stuur e-mail bij reacties en dergelijke.

Schrijf in heldere, grammaticaal correct gespelde taal

We hebben ervaren dat mensen die achteloze en slordige schrijvers zijn meestal ook achteloos en slordig denken en code schrijven (in ieder geval vaak genoeg om een weddenschap aan te gaan). Het beantwoorden van vragen van achteloze en slordige denkers is niet lonend; we besteden onze tijd liever aan iets anders.

Dus je vraag duidelijk en goed formuleren is belangrijk. Als je daarvoor niet de moeite kunt nemen, kun je van ons niet verlangen dat we de moeite nemen op te letten. Besteed de extra moeite aan het oppoetsen van je taalgebruik. Het hoeft niet stijf en formeel te zijn — de taal in de hackercultuur is informeel, ongedwongen, humorvol en precies tegelijk. Maar het moet precies zijn; er moet enige indicatie zijn dat je nadenkt en oplet.

Spel, gebruik interpunctie en hoofdletters correct. Verwar kan niet met kun, word met wordt, of wand met want. SCHRIJF NIET IN ALLEEN HOOFDLETTERS; dit wordt gezien als schreeuwen en wordt beschouwd als grof. (Alleen kleine letters is maar een klein beetje minder vervelend, want het is slecht leesbaar. Alan Cox komt ermee weg, maar jij niet.)

In het algemeen, als je schrijft als een halve analfabeet, wordt je hoogstwaarschijnlijk genegeerd. Gebruik geen SMS-taal. Het schrijven van "thanks" als "thnx" maakt je een halfanalfabete sul door het besparen van drie hele toetsaanslagen. Erger nog: schrijven als een 133t script kiddie hax0r is de kus des doods en garandeert dat je alleen ijzige stilte (of, in het gunstigste geval, een portie verwensingen en sarcasme) ontvangt.

Als je vragen stelt in een forum dat niet je moedertaal gebruikt, krijg je in beperkte mate ontheffing voor spel- en grammaticale fouten — maar absoluut geen ontheffing om lui te mogen zijn (en ja, in het algemeen voelen we dat verschil wel aan). Als je niet weet wat de taal is van je lezers, schrijf dan in het Engels. Bezige hackers gooien vragen in talen die ze niet begrijpen gewoon weg, en Engels is de werktaal van het Internet. Door het schrijven in het Engels beperk je de kans dat je vraag ongelezen weggegooid wordt.

Als Engels een tweede taal voor je is, dan is het goed om mogelijke respondenten op de hoogte te stellen van een eventuele taalbarrière en mogelijkheden om die te voorkomen. Bijvoorbeeld:

  • English is not my native language; please excuse typing errors. (Engels is niet mijn moedertaal, vergeef me mijn typefouten).

  • If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question. (Als je $TAAL spreekt, stuur me dan alsjeblieft een e-mail of persoonlijk bericht; ik heb misschien hulp nodig mijn vraag te vertalen).

  • I am familiar with the technical terms, but some slang expressions and idioms are difficult for me. (Ik ben bekend met de technische termen, maar ik heb moeite met sommige uitdrukkingen en woorden uit de straattaal).

  • I've posted my question in $LANGUAGE and English. I'll be glad to translate responses, if you only use one or the other.(Ik heb mijn vraag in $TAAL en in het Engels geplaatst. Ik vertaal graag de reacties, wanneer je maar een van de twee spreekt).

Verzend vragen in toegankelijke standaardformaten

Als je je vraag buitengewoon moeilijk te lezen maakt, ligt het voor de hand dat mensen de voorkeur geven aan vragen die dat niet zijn. Dus:

  • Verzend e-mail in niet-opgemaakte tekst, geen HTML. (Het is niet moeilijk om HTML uit te schakelen.)

  • Bijlagen in MIME formaat zijn meestal OK, mits ze echte inhoud bevatten (zoals een bijgevoegde broncode of patch) en het geen door je mailprogramma gegenereerde troep is (zoals een kopie van je bericht).

  • Verzend geen email met hele alinea's op een enkele regel. (Dit maakt het moeilijk om slechts op een gedeelte van het bericht te reageren.) Ga er van uit dat je bericht ook wordt gelezen op 80-karakter brede schermen en stel je tekstterugloop in op een waarde kleiner dan 80.

  • Echter, laat data (zoals logbestanden of sessie afschriften) niet teruglopen op een bepaalde vaste kolombreedte. Voeg data toe zoals deze is, zodat men er van uit kan gaan dat ze exact zien wat jij zag.

  • Zend geen MIME Quoted-Printable coderingen naar een Engelstalig forum. Deze codering kan nodig zijn voor berichten in een taal waarbij de ASCII tekenset ontoereikend is, maar veel e-mailprogramma's ondersteunen het niet. In dat geval zijn al die =20 entiteiten lelijk en afleidend zijn — of afbreuk doen aan de samenhang van je tekst.

  • Verwacht nooit dat hackers de mogelijkheid hebben documenten te lezen in exotische formaten als Microsoft Word of Excel. De meeste hackers reageren hierop zoals jij zou reageren als er iemand een hoop dampende varkensmest voor je deur heeft gelegd. Ook al kunnen ze deze formaten lezen, dan nog hekelen ze dat te moeten doen.

  • Als je e-mail stuurt vanaf een Windows machine, schakel dan Microsofts problematische Slimme Aanhalingstekens functie uit (via Opties > Autocorrectie-opties, haal het vinkje weg voor Rechte aanhalingstekens door gekrulde aanhalingstekens bij AutoOpmaak tijdens het typen). Dit is om te voorkomen dat je allerlei overbodige tekens over je bericht strooit.

  • Op webforums, misbruik de smiley en HTML functies niet (als ze beschikbaar zijn). Een of twee smilies zijn meestal wel OK, maar gekleurde en versierde tekst doet denken dat je zwakzinnig bent. Bovenmatig gebruik van smilies, kleur en lettertypen doen je lijken op een giechelend tienermeisje, hetgeen meestal geen goed idee is, tenzij je meer geïnteresseerd bent in seks dan antwoorden.

Als je een mailprogramma met een grafische gebruikersinterface gebruikt, zoals Netscape Messenger, MS Outlook, of vergelijkbaar, pas dan op dat hun standaardinstellingen waarschijnlijk bovenstaande regels overtreden. De meeste programma's beschikken over een menuoptie Bekijk broncode. Gebruik dit op iets in je verzonden items om te zien of je berichten in onopgemaakte tekst worden verzonden zonder onnodig toegevoegde troep.

Ben precies en informatief over je probleem

  • Beschrijf de symptomen van je probleem of fout precies en duidelijk.

  • Beschrijf de omgeving waarin je probleem optreedt (machine, besturingssysteem, toepassing, etc.). Vermeld ook de gebruikte distributie en versienummer (bijv.: Fedora Core 7, Slackware 9.1 etc.).

  • Beschrijf het onderzoek dat je gedaan hebt om je probleem te begrijpen voordat je de vraag stelde.

  • Beschrijf de diagnostische stappen die je doorlopen hebt om het probleem te lokaliseren voordat je de vraag stelde.

  • Beschrijf elke mogelijk relevante wijziging in je computer of software configuratie.

  • Indien mogelijk, geef een manier om het probleem in een gecontroleerde omgeving te reproduceren.

Probeer zoveel mogelijk de vragen, die een hacker zou kunnen stellen, voor te zijn door ze vooraf in je verzoek om hulp te beantwoorden.

Door hackers de mogelijkheid te geven om het probleem in een gecontroleerde omgeving te reproduceren is bijzonder belangrijk als je denkt een probleem in de code te rapporteren. Als je dit doet vergroot je de kans op een bruikbaar en snel antwoord enorm.

Simon Tatham heeft een uitstekend artikel geschreven met de titel How to Report Bugs Effectively. Ik adviseer je ten zeerste om het te lezen.

Hoeveelheid is niet precisie

Je moet nauwkeurig en informatief zijn. Dit lukt niet door middel van het simpelweg dumpen van grote hoeveelheden code of data in een hulpverzoek. Als je een veel, ingewikkelde handelingen doet waardoor een programma stuk gaat, probeer deze dan in te perken en zo klein mogelijk te maken.

Dit is nuttig om minstens drie redenen. Een: tonen dat je moeite neemt om de vraag te vereenvoudigen geeft meer kans op een antwoord, Twee: het vereenvoudigen van de vraag geeft meer kans dat je een bruikbaar antwoord krijgt. Drie: in het proces van het bijschaven van je foutrapport, zou je zelf al een oplossing of workaround kunnen ontwikkelen.

Beweer niet te snel dat je een fout gevonden hebt

Wanneer je problemen hebt met een stuk software, beweer niet dat je een fout hebt gevonden, tenzij je er heel, heel erg zeker van bent. Tip: tenzij je kunt voorzien in een patch voor de broncode die het probleem oplost, of een regressietest tegen een voorgaande versie hebt die foutief gedrag laat zien, ben je waarschijnlijk niet zeker genoeg. Dit geldt ook voor webpagina's en documentatie; als je een fout hebt gevonden in de documentatie, voorzie dan in de verbeterde tekst en geef aan op welke pagina's het moet komen te staan.

Onthou, er zijn veel andere gebruikers die geen last hebben van het door jou omschreven probleem. Anders zou je dat wel gemerkt hebben tijdens het lezen van documentatie of het doorzoeken van het web (dat heb je immers gedaan voordat je ging klagen, toch?). Dit betekent heel waarschijnlijk dat jij iets verkeerd doet, en niet de software.

De mensen die de software hebben geschreven werken heel hard om het zo goed mogelijk te laten werken. Als je beweert dat je een fout hebt gevonden twijfel je aan hun competentie, wat er toe kan leiden dat sommigen zich aangevallen voelen, ook al heb je gelijk. Het is in het bijzonder ongepast om de term fout of bug in de onderwerpregel te scanderen.

Als je je vraag stelt, is het het beste om te schrijven alsof je aanneemt dat jij iets verkeerd doet, ook al ben je zelf behoorlijk zeker dat de fout in het programma zit. Als het echt een fout is, zal je daarover horen in het antwoord. Speel het zo dat de makers zich tegenover jou zullen willen verontschuldigen als de fout echt is, in plaats van dat jij je moet verontschuldigen dat je het verkeerd aangepakt hebt.

Nederig zijn is geen vervanging voor het doen van je huiswerk

Sommige mensen die te horen krijgen dat ze niet zo onbeschoft of arrogant moeten zijn of niet een antwoord moeten eisen, gaan zich als het andere uiterste van nederig gedragen. I weet dat ik een kansloze loser ben, maar.... Dit leidt af en draagt niets bij. Het is vooral vervelend als het samen gaat met vaagheid over het probleem in kwestie.

Verspil je tijd niet, of de onze, met zulke primate hoffelijkheid. In plaats daarvan, vermeld de achtergrondinformatie en stel je vraag zo duidelijk mogelijk. Hiermee plaats je je zelf veel beter dan door nederig te zijn.

Soms hebben webfora aparte afdelingen voor vragen van nieuwelingen. Als je het gevoel hebt zo'n vraag te hebben, stel hem daar. Maar ben ook daar niet nederig.

Beschrijf de symptomen van het probleem, niet je vermoedens

Het is niet nuttig om hackers te vertellen wat jij denkt dat de oorzaak van je probleem is. (Als je diagnostische theorieën zo goed zijn, waarom vraag je dan om advies?) Verzeker je er dus van dat je de symptomen vertelt van datgene wat verkeerd gaat, in plaats van jouw interpretaties en theorieën. Laat hen de interpretatie en diagnostiek doen. Als je denk dat het belangrijk is om je vermoeden te vermelden, geef duidelijk aan dat het een vermoeden is en waarom dat geen oplossing voor je biedt.

Dom:

Ik krijg van voor tot achter SIG11 foutmeldingen tijdens het compileren van de kernel en ik vermoed dat er een haarscheur in een van de geleidingen op het moederbord zit. Wat is de beste manier om dat te controleren?

Slim:

Mijn zelfgebouwde K6/233 met FIC-PA2007 moederbord (VIA Apollo VP2 chipset) met 256 MB Corsair PC133 SDRAM geeft frequent SIG11 foutmeldingen, zo ongeveer 20 minuten na het opstarten tijdens de compilatie van de kernel, maar nooit tijdens de eerste 20 minuten. Opnieuw opstarten zorgt er niet voor dat tijd opnieuw begint te lopen, maar 's nachts uitschakelen wel. Vervangen van het RAM heeft niet geholpen. Hieronder volgt het relevante gedeelte van een typisch compilatie logbestand.

Omdat het bovenstaande punt voor veel mensen moeilijk te begrijpen is, voeg ik een ezelsbrug hieraan toe: "Alle diagnosten komen uit Missouri." Deze Amerikaanse staat heeft als officieel motto "Laat zien" (verkregen in 1899, toen Congreslid Willard D. Vandiver zei "Ik kom uit een land dat mais en katoen en lage stekelnoot en Democraten groot brengt, en frivole welsprekendheid overtuigt noch stelt mij tevreden. Ik kom uit Missouri. Je moet het me laten zien.") In het geval van de diagnost is het geen scepsis, maar een letterlijke, functionele noodzaak om te zien wat zo dicht mogelijk in de buurt komt van wat jij hebt gezien, in plaats van samenvattingen. Laat zien.

Beschrijf de symptomen van je probleem in chronologische volgorde

Vaak liggen de meest waardevolle aanwijzingen voor het uitzoeken van iets dat verkeerd ging direct voor het optreden van het probleem. Daarom moet je exact beschrijven wat je hebt gedaan, en wat de machine en software hebben gedaan, voordat het verkeerd ging. In het geval van een command-line proces is het erg nuttig om een logbestand te hebben en de eerste twintig ofzo relevante regels aan te halen.

Als het programma dat je in de steek heeft gelaten diagnostische opties heeft (zoals -v voor verbose, uitgebreid), probeer dan de opties te selecteren die nuttige foutopsporingsinformatie aan het afschrift toevoegen. Bedenk dat meer niet noodzakelijk beter is; kies een foutopsporingsniveau dat informatief is zonder de lezer te overspoelen met troep.

Als je beschrijving lang dreigt te raken (meer dan zo'n vier alinea's), kan het zinvol zijn het probleem aan het begin van het bericht te omschrijven en daarna de hele geschiedenis in chronologische volgorde te vertellen. Daardoor weet de hacker bij voorbaat waar hij in de beschrijving op moet letten.

Beschrijf het doel, niet de stap

Als je probeert uit te vinden hoe je iets moet doen (anders dan het rapporteren van een fout), begin dan met het beschrijven van je doel. Beschrijf pas daarna bij welke stap naar het doel je vastloopt.

Vaak is het zo dat mensen die technische hulp nodig hebben een hoger doel in gedachten hebben en vastlopen op een weg die ze ingeslagen zijn, waarvan zij denken dat deze naar het doel leidt. Ze vragen om hulp voor deze specifieke stap, maar realiseren zich niet dat ze de verkeerde weg zijn ingeslagen. Het kan veel moeite kosten om dan alsnog het doel te bereiken.

Dom:

Hoe kan ik een hexadecimale RGB waarde in de kleurkiezer van FooDraw invoeren?

Slim:

Ik probeer de kleurentabel van een afbeelding te vervangen door waarden van mijn keuze. Op dit moment zie ik als enige manier om dit te doen het aanpassen van iedere afzonderlijke waarde, maar de kleurkiezer van FooDraw accepteert geen hexadecimale RGB waarde.

De tweede versie van de vraag is verstandig. Het laat antwoorden toe die een programma suggereren dat beter geschikt is voor de taak.

Vraag niet om antwoord te krijgen via (privé) e-mail

Hackers denken dat het oplossen van problemen een publiek, transparant proces moet zijn waarin de eerste mogelijke oplossing verbeterd kan en zou moeten worden als iemand met meer kennis bemerkt dat deze incompleet of incorrect is. Helpers krijgen ook een gedeelte van hun erkenning door als competent en kennisrijk gezien te worden door anderen.

Als je vraagt om een privaat antwoord, verstoor je het proces en de erkenning. Doe dit niet. Het is de keuze van de respondent of hij privaat wil reageren — en als hij of zij dat doet, is dat meestal omdat hij of zij denkt dat de vraag te slecht gesteld is of het antwoord te voor de hand liggend is dat dit van interesse kan zijn voor anderen.

Er is een beperkte uitzondering op deze regel. Als je verwacht dat je veel vergelijkbare antwoorden krijg op je vraag, dan zijn de magische woorden email me, en ik zal de antwoorden samenvatten voor de groep. Het is hoffelijk om de mailinglijst of nieuwsgroep een vloed van substantieel identieke antwoorden te besparen ” maar hou je aan de belofte om het samen te vatten.

Stel een duidelijke vraag

Vragen met een open einde worden overwegend opgevat bodemloze putten. De mensen die je waarschijnlijk een antwoord kunnen geven zijn ook de drukst bezette mensen (alleen al omdat ze zelf het meeste werk doen). Deze mensen zijn allergisch voor bodemloze putten en hebben de neiging allergisch te zijn voor vragen met een open einde.

Het is waarschijnlijker dat je een bruikbaar antwoord krijgt als je expliciet bent over wat je verwacht van een antwoord (verwijzingen geven, code aanleveren, patch controleren of wat dan ook). Dit focust de moeite die iemand doet en geeft impliciet een bovengrens aan tijd en energie die in een antwoord gestoken moet worden. Dit is goed.

Om te begrijpen in welke wereld de experts leven, stel je dan voor dat de expertise van een expert in overvloedige aanwezig is en de tijd om te reageren schaars is. Hoe minder tijd je verlangt, des te groter de kans dat je antwoord krijgt van iemand die echt goed en echt druk is.

Het is dus nuttig om je vraag te begrenzen en zo de tijd te beperken die een expert nodig heeft om hem te beantwoorden — maar dit is vaak niet hetzelfde als het vereenvoudigen van een vraag. Dus, bijvoorbeeld, Kun je me een verwijzing naar een goede uitleg van X geven? is meestal een verstandigere vraag dan Kun je me X uitleggen, alsjeblieft?. Als je wat code hebt die niet goed functioneert, is het meestal verstandiger om te vragen of iemand kan uitleggen wat er verkeerd is dan vragen of iemand het kan maken.

Wanneer je een vraag stelt over code

Vraag anderen niet om problemen met je code op te lossen zonder een hint te geven naar welk probleem ze moeten zoeken. Plaats enkele honderden regels code en het zeg dat "het niet werkt", en je zal genegeerd worden. Plaats enkele tientallen regels code en zeg "na regel 7 verwachtte ik <x> te zien, maar <y> deed zich voor", dat geeft je veel meer kans op een antwoord.

De meest effectieve manier om precies te zijn bij een probleem met code is om te voorzien in minimale test-case die het probleem laat zien. Wat is een minimale test-case? Het is een illustratie van je probleem, precies genoeg code om het probleem te laten zien en niet meer. Hoe maak je een minimale test-case? Als je weet welke regel of codeblok het probleem veroorzaakt, maak hier dan een kopie van en voeg precies genoeg code toe om tot een compleet voorbeeld te komen (dat is zoveel dat is nodig is om de compiler/interpreter/applicatie het voorbeeld te laten verwerken). Als je het probleem niet kunt herleiden tot een specifieke plek, maak dan een kopie van de broncode en verwijder zo veel mogelijk onderdelen die geen invloed hebben op het probleemgedrag. Hoe kleiner je minimale test-case, hoe beter (zie de paragraaf "Hoeveelheid is niet precisie").

Het maken van een echt kleine minimale test-case zal niet altijd mogelijk zijn, maar proberen is altijd goed. Het kan je helpen te begrijpen wat je nodig hebt om het probleem zelf op te lossen — en ook als dat niet lukt zien hackers graag dat je het hebt geprobeerd. Hierdoor zullen ze meewerkender zijn.

Als je alleen wil dat iemand je code nakijkt, zeg het dan zo vroeg mogelijk in je bericht en vertel welke onderdelen in het bijzonder nagekeken moeten worden en waarom.

Plaats geen huiswerkopgaven

Hackers zijn goed in het herkennen van huiswerkvragen; de meeste van ons hebben ze zelf gemaakt. Het is aan jou om deze vragen uit te werken, zodat je leert van de ervaring. Het is OK om naar tips te vragen, maar niet naar complete oplossingen.

Als je vermoed dat je een huiswerkvraag hebt gekregen, maar je kunt 'm toch niet oplossen, vraag dan in een forum van een gebruikersgroep of (als laatste redmiddel) in een gebruikers-lijst/forum van een project. Hackers zullen hem herkennen, maar sommige ervaren gebruikers kunnen je misschien een hint geven.

Vermijd doelloze vragen

Weersta de verleiding om je vraag om hulp af te sluiten met technisch inhoudsloze vragen zoals Kan iemand me helpen? of Is er een oplossing?. Allereerst: als je je probleemomschrijving ook maar een beetje kundig hebt opgeschreven zijn zulke aanhangende vragen op z'n minst overbodig. Op de tweede plaats: omdat ze overbodig zijn, vinden hackers ze vervelend — en is de kans groot dat je logisch correcte, maar weinig helpvolle, antwoorden krijgt zoals Ja, kunt geholpen worden of Nee, we kunnen je niet helpen.

In het algemeen is het een goed idee om ja/nee vragen te vermijden, tenzij je een ja-of-nee antwoord wilt.

Markeer je vraag niet als Urgent, ook al is het dat voor jou

Dat is jouw probleem, niet het onze. Stellen dat iets belangrijk is werkt vaak averechts: de meeste hackers zullen zulke vragen verwijderen als ware het grove en zelfzuchtige verzoeken voor onmiddellijke en speciale aandacht. Daarbij activeert het woord 'Urgent' (en andere daarop lijkende pogingen om aandacht te trekken in de onderwerpregel) vaak de spamfilters - je beoogde ontvangers krijgen het misschien niet eens te zien!

Er is één semi-uitzondering. Het kan het vermelden waard zijn als je het programma gebruikt op een of andere prominente plek, iets waarvan de hackers enthousiast raken; als je in zo'n geval in tijdnood zit, en het vriendelijk vraagt, kunnen mensen geïnteresseerd raken en sneller antwoorden.

Het is echter een erg risicovol om dit te doen, omdat de maatstaven van de hacker over wat interessant is waarschijnlijk afwijken van de jouwe. Vragen vanuit bijvoorbeeld het International Space Station kwalificeren zich waarschijnlijk, maar vragen met een weldadige of politieke achtergrond doen dat vrijwel zeker niet. Sterker nog, het stellen van vragen als Belangrijk: Help me met het redden van de wollige baby zeehonden! worden gegarandeerd genegeerd of afgekraakt, zelfs door hackers die wollige baby zeehonden belangrijk vinden.

Als je dit vreemd vindt, lees de rest van deze handleiding herhaaldelijk totdat je begrijpt waarom, voordat je überhaupt een vraag stelt.

Beleefdheid doet geen pijn, en soms helpt het

Ben beleefd. Gebruik Alsjeblieft en Bedankt voor je aandacht of Bij voorbaat dank. Maak duidelijk dat je het waardeert dat mensen hun tijd gebruiken om je gratis te helpen.

Om eerlijk te zijn, dit is niet zo belangrijk als (en kan geen vervanging zijn voor) het grammaticaal correct, nauwkeurig en duidelijk beschrijvend te zijn en het voorkomen van gesloten bestandsformaten etc.; over het algemeen krijgen hackers liever enigszins brute maar technisch onderlegde vragen dan beleefde vaagheid. (Als dit je verwondert, herinner je dan dat we de waarde van een vraag beoordelen aan de hand van wat deze ons kan leren.)

Toch, als je je technische onderbouwing op orde hebt, zal beleefdheid de kans op een bruikbaar antwoord vergroten.

(We moeten opmerken dat de enige serieuze bezwaren die we hebben ontvangen van doorgewinterde hackers op deze HOWTO betrekking hebben op onze de voorgaande aanbeveling om Bij voorbaat dank te gebruiken. Sommige hackers hebben het gevoel dat dit een intentie is om iemand niet achteraf te bedanken. Onze aanbeveling is om of eerst Bij voorbaat dank te zeggen en iedereen achteraf te bedanken, of om beleefdheid te uiten in een andere vorm, zoals het zeggen van Bedankt voor je aandacht of Bedankt voor je moeite.)

Plaats aansluitend een korte opmerking over de oplossing

Stuur een reactie nadat het probleem opgelost is naar iedereen die je geholpen heeft; laat hen weten hoe het uiteindelijk gelukt is en bedank nogmaals voor hun hulp. Als het probleem algemene interesse heeft gewekt in de mailinglijst of nieuwsgroep, plaats je reactie dan daar.

Het is het beste om te reageren op de originele discussie van je vraag en 'FIXED', 'OPGELOST' of een soortgelijke kreet aan de onderwerpregel toe te voegen. Op hoogfrequente mailinglijsten weet de lezer dat hij zijn/haar tijd niet hoeft te verdoen zodra hij/zij een onderwerp ziet over Probleem X, eindigend met Problem X - OPGELOST (tenzij hij/zij Probleem X interessant vindt) en kan die tijd gebruiken om een ander probleem op te lossen.

Je reactie hoeft niet lang of uitgebreid te zijn; een simpel Hallo — het was een defecte netwerkkabel! Bedankt, allemaal. - Willem is beter dan niets. Sterker nog, een korte samenvatting is beter dan een langdradig verhaal, tenzij de oplossing echte technische diepgang heeft. Vermeld welke actie voor de oplossing zorgde, maar je hoeft niet alle details van de handelingen die je verricht hebt op te sommen.

Voor problemen met enige diepgang is het gepast om een samenvatting van de handelingen te vermelden. Beschrijf de uiteindelijke omschrijving van het probleem. Beschrijf wat heeft gewerkt als oplossing en geef daarna aan wat de doodlopende straten zijn. De doodlopende straten komen na de correcte oplossing en andere samenvattingen zodat je reactie geen detective verhaal wordt. Noem de namen van de mensen die je geholpen hebben; op die manier maak je vrienden.

Behalve beleefd en informatief zal dit soort reacties ook anderen helpen die de archieven van de mailinglijst/nieuwsgroep/forum doorzoeken zodat ze exact weten wat voor jou de oplossing is geweest, welke ook voor hen zou kunnen werken.

Als laatste, maar niet als minste, geven dit soort reacties iedereen die heeft meegeholpen aan de oplossing een voldaan gevoel over de afsluiting van het probleem. Als je zelf geen techie of hacker bent, moet je maar van ons aannemen dat dit gevoel erg belangrijk is voor de goeroes en experts die je hebt geraadpleegd voor hulp. Problemen, die in het onopgeloste niets opgaan, zijn frustrerende zaken; hackers zien dingen graag opgelost. De goede indruk die je achterlaat door het geven van zo'n reactie, zal nuttig zijn zodra je de volgende keer een vraag moet stellen.

Bedenk hoe je kunt voorkomen dat anderen hetzelfde probleem krijgen in de toekomst. Vraag je af of een aanvulling op documentatie of FAQ nuttig kan zijn. Als het antwoord hierop ja is, zend dan de aanvulling naar degene die de documentatie beheert.

Tussen hackers is dit soort van reacties zelfs belangrijker dan conventionele beleefdheid. Op deze manier bouw je een reputatie op over hoe je met anderen omgaat, welke erg waardevol kan zijn.

Hoe men antwoorden interpreteert

RTFM en STFW: Hoe men aangeeft dat je het behoorlijk verkeerd gedaan hebt

Er bestaat een oude en geheiligde traditie: als je een antwoord krijg in de vorm van RTFM, is de persoon die het antwoord verstuurd heeft van mening dat je de verdraaide handleiding moet lezen (Read The Fucking Manual). Hij of zij heeft vrijwel zeker gelijk. Lees hem.

RTFM heeft een jonger broertje. Als je een antwoord krijgt dat luidt STFW, is de persoon die het antwoord verstuurd heeft van mening dat je het verdraaide web moet doorzoeken (Search The Fucking Web). Hij of zij heeft vrijwel zeker gelijk. Doorzoek het. (De mildere versie hiervan is wanneer verteld wordt Google is je vriend!)

Op forums kan men je ook vertellen om de archieven van het forum te doorzoeken. Soms kan iemand zelfs zo vriendelijk zijn om je een verwijzing te geven naar een ander onderwerp waar het probleem opgelost werd. Maar vertrouw nooit op deze vriendelijkheid; doorzoek de archieven voordat je een vraag stelt.

Vaak heeft de persoon die je vertelt om een zoekopdracht te doen de handleiding of webpagina met de informatie die je nodig hebt voor zich en kijkt ernaar terwijl hij of zij typt. Antwoorden als deze houden in dat (a) de informatie die je zoekt eenvoudig te vinden is, en (b) je meer zult leren als je de informatie zelf zoekt dan wanneer je deze met de paplepel ingegoten krijgt.

Voel je echter niet beledigd hierdoor; volgens hackerstandaarden toont degene die je dit antwoord geeft een ruwe vorm van respect, simpelweg door je niet te negeren. Je zou dankbaar moeten zijn voor deze grootmoederlijke goedheid.

Als je het niet begrijpt...

Als je het antwoord niet begrijpt, vraag dan niet direct om verduidelijking. Gebruik dezelfde middelen die je gebruikt hebt om een antwoord op je oorspronkelijke vraag te vinden (handleidingen, FAQ's, Internet, ervaren vrienden) om het antwoord te begrijpen. Pas dan, als het nog steeds nodig is om verduidelijking te vragen, laat zien wat je hebt geleerd.

Bijvoorbeeld, veronderstel dat ik je zeg: Het lijkt erop dat je zentry vastgelopen is; je moet hem vrijmaken.. Dan is hier een slechte vervolgvraag: Wat is een zentry?. Hier is een goede vervolgvraag: OK, ik heb de handleiding doorgenomen en zentry's worden alleen genoemd onder de -z en -p schakelopties. Geen van beiden zegt iets over het vrijmaken van zentry's. Is het een van deze, of heb ik iets over het hoofd gezien?

Omgaan met grofheid

Veel van dat wat grofheid lijkt in de hackerwereld is niet als dergelijk bedoeld. Het is het resultaat van de directe, ontwijk-de-onzin stijl van communiceren die natuurlijk is voor mensen die zich meer bezig houden met het oplossen van problemen dan anderen een warm en pluizig gevoel geven.

Als je grofheid meemaakt probeer dan kalm te reageren. Als iemand het erg bont maakt, zal hoogstwaarschijnlijk iemand die al lang lid is van de mailinglijst of nieuwsgroep of forum er iets van zeggen. Als dat niet gebeurt en jij je kalmte verliest, is het waarschijnlijk dat de persoon zich gedroeg naar de normen van de hackergemeenschap en zal jij als de schuldige wordt aangewezen. Dit zal de kans dat je informatie of hulp krijgt aantasten.

Aan de andere kant zal je zo nu en dan tegen grofheid aanlopen en je daarover aanstellen is behoorlijk zinloos. De andere kant van het hierboven genoemde is, dat het aanvaardbaar is de werkelijke overtreders hard terecht te wijzen en ze met een scherp verbaal mes te pijnigen. Zorg er voor dat je heel, heel zeker bent voordat je dit zelf probeert. De grens tussen het terecht wijzen van een overtreder of het starten van een oorlog van woordenwisseling is dusdanig smal dat hackers vaak zelf de fout maken en onbedoeld de grens overschrijden; als je een nieuwkomer of buitenbeentje bent is de kans om zo'n fout te vermijden erg klein. Als je op zoek bent naar informatie in plaats van sensatie, kun je het beste je vingers van het toetsenbord af houden dan zoiets te riskeren.

(Sommige mensen zijn van mening dat veel hackers onder een milde vorm van autisme of het Syndroom van Asperger lijden, en sommige hersenonderdelen missen die normale menselijke sociale interactie smeren. Dit kan, maar hoeft niet waar te zijn. Als je zelf geen hacker bent; kan het helpen om te gaan met onze excentriciteiten door te denken dat we hersenbeschadiging hebben opgelopen. Ga je gang. Het zal ons niet deren; we houden ervan om te zijn wat we zijn, en hebben meestal een gezonde dosis scepsis over het ingedeeld worden in klinische categorieën.)

Jeff Bigler's observaties over tact filters zijn ook relevant en de moeite waard om te lezen.

In de volgende paragraaf zullen we het hebben over een andere situatie; de vorm van grofheid die je zult tegenkomen als jij je misdraagt.

Over het niet reageren als een loser

Kans bestaat dat je het een paar keer verprutst op de fora binnen de hackergemeenschap — zoals uiteengezet in dit artikel, of op vergelijkbare wijze. Je zult exact worden verteld hoe je het verpest hebt, mogelijk met kleurrijke omschrijvingen. Publiekelijk.

Als dit gebeurt, is het slechtste wat je kunt doen gaan janken over je ervaring, stellen dat je verbaal aangevallen bent, verontschuldigingen eisen, schreeuwen, je adem inhouden, dreigen met rechtszaken, klagen bij iemands werkgever, de toiletbril omhoog laten staan, etc. In plaats daarvan doe je het volgende:

Zet je eroverheen. Het is normaal. Om precies te zijn, het is gezond en passend.

De standaarden van de gemeenschap onderhouden zich niet vanzelf: ze worden onderhouden door mensen die ze actief toepassen, zichtbaar, publiekelijk. Jank niet dat alle kritiek afgehandeld zou moeten worden via private e-mail: zo werkt het niet. Noch is het nuttig om voor te houden dat je persoonlijk beledigd bent als iemand aangeeft dat je veronderstelling verkeerd was, of dat zijn visie afwijkt. Dat is de houding van een loser.

Er waren hacker forums waar, in een ondoordacht gevoel van hyper-beleefdheid, deelnemers verbannen werden omdat ze iets fout vonden aan iemand anders' bericht, en verteld werden Zeg niets als je niet wil helpen.. Het resultaat was het vertrek van deelnemers met kennis wat leidde tot het vervallen van de forums tot betekenisloos geklets en het nutteloos worden als technische forums.

Overdreven vriendelijk (op genoemde manier) of bruikbaar: kies er een.

Onthoud: wanneer een hacker je vertelt dat je het verpest hebt en (hoe vernederend dan ook) je vertelt dat niet meer te doen, handelt hij uit medeleven met (1) jou en (2) zijn gemeenschap. Het zou veel makkelijker zijn voor hem om jou te negeren en je uit zijn leven te filteren. Als je niet dankbaar kunt zijn, toon op z'n minst een beetje waardigheid, ga niet janken, en verwacht niet behandeld te worden als een breekbare pop, alleen omdat je een nieuwkomer bent met een theatrale overgevoelige ziel en waanideeën over gerechtigheid.

Soms zullen mensen je persoonlijk aanvallen zonder duidelijke reden, etc., ook al heb je het niet verpest (of heb je het alleen verpest in hun verbeelding). In dit geval is klagen de manier om het echt te verpesten.

Deze personen zijn of lamballen die geen enkel verstand hebben maar denken dat ze experts zijn, of zelfbenoemde psychologen die testen of je het zult verpesten. De andere lezers negeren hen, of vinden hun eigen manieren om met hen om te gaan. Het gedrag van de aanvallers creëert problemen voor henzelf, wat niets met jou te maken hebben.

Raak echter ook niet verwikkeld in een persoonlijke aanval-oorlog. De meeste persoonlijke aanvallen kunnen het beste worden genegeerd — nadat je heb gecontroleerd of het echt persoonlijke aanvallen zijn en geen verwijzingen zijn naar de manier waarop je het verpest hebt of versleutelde antwoorden op je echte vraag zijn (dit komt ook voor).

Vragen die men niet moet stellen

Hier zijn enkele klassieke domme vragen en wat hackers denken wanneer ze deze niet beantwoorden.

V: Waar kan ik programma of bron X vinden?
V: Hoe kan ik X gebruiken om Y te doen?
V: Hoe kan ik mijn shell prompt instellen?
V: Kan ik een AcmeCorp document naar een TeX bestand converteren met de Bass-o-matic bestandsconverter?
V: Mijn {programma, configuratie, SQL statement} werkt niet
V: Ik heb problemen met mijn Windows machine. Kun je me helpen?
V: Mijn programma werkt niet. Ik denk dat systeemfaciliteit X defect is.
V: Ik heb problemen met het installeren van Linux of X. Kun je me helpen?
V: Hoe kan ik root kraken/kanaalbeheer toegang stelen/iemands email lezen?

V:

Waar kan ik programma of bron X vinden?

A:

Op dezelfde plaats waar ik het gevonden heb, sukkel — aan de andere kant van een internetzoekopdracht. Werkelijk, weet nog steeds niet iedereen hoe je Google moet gebruiken?

V:

Hoe kan ik X gebruiken om Y te doen?

A:

Als je Y wilt bereiken, zou je deze vraag moeten stellen zonder de veronderstelling van het gebruik van een methode die wellicht niet geschikt is. Vragen in deze vorm geven wijzen vaak op een persoon die niet enkel onwetend is over X, maar verward is over welk probleem Y hij probeert op te lossen en te gefixeerd is op de details van de specifieke situatie. Het is over het algemeen het beste om zulke mensen te negeren totdat ze hun probleem beter omschrijven.

V:

Hoe kan ik mijn shell prompt instellen?

A:

Als je slim genoeg bent om deze vraag te stellen, ben je slim genoeg om RTFM en het zelf uit te zoeken.

V:

Kan ik een AcmeCorp document naar een TeX bestand converteren met de Bass-o-matic bestandsconverter?

A:

Probeer en kijk of het werkt. Als je dat gedaan had, zou je (a) het antwoord weten en (b) mijn tijd niet verdoen.

V:

Mijn {programma, configuratie, SQL statement} werkt niet

A:

Dit is geen vraag en ik ben niet in de stemming om Twintig Vragen te spelen om de echte vraag uit je te prutsen — ik heb wel betere dingen te doen. Als ik zoiets zie, is mijn reactie normaal gesproken een van het volgende:

  • en heb je daar iets aan toe te voegen?

  • ah, dat is jammer, ik hoop dat je het kunt oplossen.

  • en wat heeft dat precies met mij van doen?

V:

Ik heb problemen met mijn Windows machine. Kun je me helpen?

A:

Ja. Gooi die Microsoft-troep naar buiten en installeer een open-source besturingssysteem zoals Linux of BSD.

Opmerking: je kunt een vraag stellen die te maken heeft met Windows machines als deze gaat over een programma dat een versie specifiek voor Windows heeft, of samenwerkt met Windows (dus Samba). Ben alleen niet verrast als uit het antwoord blijkt dat het probleem bij Windows ligt en niet bij het programma, omdat Windows sowieso in het algemeen stuk is, waardoor dit vaak het geval is.

V:

Mijn programma werkt niet. Ik denk dat systeemfaciliteit X defect is.

A:

Hoewel het mogelijk is dat je de eerste persoon bent die een voor de hand liggend probleem in systeemprocedures of bibliotheken tegen komt, welke veel gebruikt worden door honderden of duizenden andere mensen, ligt het meer voor de hand dat je werkelijk geen idee hebt waar je het over hebt. Buitengewone veronderstellingen vereisen buitengewoon bewijs; als je uit gaat van een dergelijke veronderstelling moet je dit onderbouwen met heldere en uitgebreide documentatie over de fout in kwestie.

V:

Ik heb problemen met het installeren van Linux of X. Kun je me helpen?

A:

Nee. Ik heb fysieke toegang tot je machine nodig om dit op te lossen. Vraag je lokale Linux gebruikersgroep voor fysieke hulp. (Je kunt hier een lijst van gebruikersgroepen vinden.)

Opmerking: vragen over het installeren van Linux kunnen terecht zijn als je op een forum of mailinglijst zit van een specifieke distributie en het probleem zich voordoet met die distro; of op forums van lokale gebruikersgroepen. Beschrijf in dit geval de exacte details van het probleem. Maar zoek eerst nauwkeurig op "linux" en alle verdachte hardware.

V:

Hoe kan ik root kraken/kanaalbeheer toegang stelen/iemands email lezen?

A:

Je bent het afvoerputje van de maatschappij omdat je zoiets wilt doen en een idioot om een hacker om hulp te vragen.

Goede en slechte vragen

Tot slot zal ik met een aantal voorbeelden illustreren hoe je verstandige vragen kunt stellen; paren van vragen over hetzelfde probleem, waarbij een op een domme manier gesteld wordt en een op een slimme manier.

Dom: Waar kan ik informatie vinden over de Floony Flurbamatic?

Deze vraag schreeuwt gewoon om "STFW" als antwoord.

Slim: Ik heb Google gebruikt om Floony Flurbamatic 2600 op internet te vinden, maar ik kreeg geen bruikbare resultaten. Kan iemand mij een verwijzing geven naar programmeerinformatie voor dit apparaat?

Deze heeft al geSTFWd en het lijkt erop dat hij een echt probleem heeft.

Dom: Ik krijg het niet voor elkaar om de code van project foo te compileren. Waarom is het stuk?

De vraagsteller veronderstelt dat iemand anders iets verkeerd heeft gedaan. Arrogante sukkel...

Slim: De code van project foo compileert niet onder Nulix versie 6.2. Ik heb de FAQ gelezen, maar er staat niks in over Nulix-gerelateerde problemen. Hier is een afschrift van mijn compilatie poging; is het iets wat ik verkeerd heb gedaan?

De vraagsteller heeft de omgeving genoemd, de FAQ gelezen, geeft de fout, en gaat er niet van uit dat iemand anders iets verkeerd moet hebben gedaan. Deze zou wel wat aandacht waard kunnen zijn.

Dom: Ik heb problemen met mijn moederbord. Kan iemand me helpen?

J. Random Hacker's antwoord hierop zou waarschijnlijk zijn Juist. Moet je ook nog een boertje laten en je luiers verschoond krijgen?, gevolgd door een druk op de delete-knop.

Slim: Ik heb X, Y en Z geprobeerd op het S2464 moederbord. Toen dat niet werkte, probeerde ik A, B en C. Let op de vreemde symptomen toen ik C probeerde. Het is duidelijk dat de florbis grommikt, maar de resultaten zijn niet wat men zou verwachten. Wat zijn meestal de oorzaken van het grommiken op Athlon MP moederborden? Heeft iemand ideeën voor meer tests die ik kan uitvoeren om het probleem te lokaliseren?

Deze persoon lijkt een antwoord waard. Hij/zij laat probleem-oplossend vermogen zien in plaats van het passief afwachten totdat een antwoord uit de hemel komt vallen.

In de laatste vraag, merk het subtiele doch belangrijke verschil op tussen het eisen Geef me een antwoord en Kan iemand me alsjeblieft helpen om uit te vinden welke diagnostische toetsen ik kan uitvoeren om tot een oplossing te komen.

Om precies te zijn, de vorm van de laatste vraag is nauw gebaseerd op een werkelijk probleem dat gebeurde in augustus 2001 op de linux-kernel mailinglijst (lkml). Ik (Eric) was degene die de vraag toen ter tijd stelde. Ik had mysterieuze vastlopers op een Tyan S2462 moederbord. De leden van de mailinglijst voorzagen me van de kritieke informatie die ik nodig had om het probleem op te lossen.

Door de vraag te stellen op een manier zoals ik deed, gaf ik mensen iets om op te kauwen; ik maakte het eenvoudig en aantrekkelijk om betrokken te raken. Ik toonde respect voor de kennis van mijn medeleden en nodigde hen uit om mij te raadplegen als waardig medelid. Ik toonde ook respect voor de waarde van hun tijd door het vermelden van de doodlopende straten die ik al was tegen gekomen.

Achteraf bedankte ik iedereen en merkte op hoe goed alles had gelopen. Een lkml lid bemerkte dat en dacht dat het zo goed had gewerkt, niet omdat ik een naam was op die lijst, maar omdat ik de vraag in de juiste vorm gesteld had.

Hackers zijn in bepaalde aspecten een erg meedogenloze gemeenschap; ik weet zeker dat hij gelijk heeft, en als ik me had gedragen als een spons, zou ik worden genegeerd of afgeschoten ongeacht wie ik was. Zijn suggestie om het hele gebeuren op te schrijven als instructie voor anderen heeft direct geleidt tot het opstellen van deze handleiding.

Als je geen antwoord krijgt

Als je geen antwoord krijgt, vat het dan niet persoonlijk op dat we denken dat we je niet willen helpen. Soms weten de leden van de gevraagde gemeenschap het antwoord gewoon niet. Geen antwoord is niet hetzelfde als genegeerd worden, maar toegegeven, het is moeilijk om dat verschil van buitenaf te zien.

In het algemeen is het opnieuw plaatsen van je vraag een slecht idee. Dit wordt gezien als nutteloos vervelend. Heb geduld: de persoon met het antwoord op je vraag kan zich in een andere tijdzone bevinden en slapen. Of je vraag was in de eerste plaats al niet goed geformuleerd.

Er zijn andere bronnen waar je kunt vragen om hulp, vaak bronnen beter aangepast aan de behoeften van een beginneling.

Er zijn vele online en lokale gebruikersgroepen die enthousiast zijn over de software, ook al hebben ze nooit zelf software geschreven. Deze groepen worden vaak gevormd zodat mensen elkaar kunnen helpen en hulp kunnen bieden aan nieuwe gebruikers.

Er zijn ook genoeg grote en kleine commerciële bedrijven die je kunt contracteren voor hulp. Ben niet ontzet door het idee dat je moet betalen voor een beetje hulp! Immers, als een koppakking van je automotor eruit klapt, is de kans groot dat je ermee naar een garagebedrijf gaat en betaalt om het te laten repareren. Zelfs als de software gratis is, kun je niet verwachten dat de ondersteuning ook altijd gratis is.

Voor populaire software als Linux zijn er minstens 10.000 gebruikers per ontwikkelaar. Het is simpelweg niet mogelijk voor één persoon om de ondersteuningsverzoeken van meer dan 10.000 gebruikers af te handelen. Bedenk dat ook al zou je moeten betalen voor ondersteuning, je nog steeds veel minder betaalt dan als je de software ook nog zou moeten kopen (en ondersteuning voor closed-source software is meestal duurder en minder kundig dan ondersteuning voor open-source software).

Vragen op een helpvolle manier beantwoorden

Ben zachtaardig. Probleem-gerelateerde stress kan mensen onbeschoft of dom doen lijken, ook al zijn de dat niet.

Reageer offline op iemand die de eerste keer iets verkeerd doet. Er is geen reden om iemand publiekelijk te vernederen als deze persoon een oprechte fout heeft gemaakt. Een echte nieuwkomer weet misschien niet hoe hij de archieven moet doorzoeken of waar de FAQ te vinden is.

Als je iets niet zeker weet, zeg het! Een verkeerd maar overtuigend klinkend antwoord is slechter dan geen enkel antwoord. Stuur iemand niet de verkeerde richting op, simpelweg omdat het leuk is om over te komen als een expert. Ben bescheiden en eerlijk; ben een goed voorbeeld voor de vraagsteller en de meelezers.

Als je niet kunt helpen, bemoei je er niet mee. Maak geen grappen over procedures die iemands systeem overhoop kunnen gooien — het arme schaap zou dit kunnen opvatten als zijnde instructies.

Stel verdiepende vragen om meer details te verkrijgen. Als je hier goed in bent, zal de vraagsteller er iets van leren — en jijzelf misschien ook. Probeer een slechte vraag om te zetten in een goede; bedenk dat we allemaal ooit nieuwkomers zijn geweest.

Het mompelen van RTFM is soms gerechtvaardigd als reactie naar iemand die een lui varken is, maar een verwijzing naar documentatie (ook al is het alleen een suggestie om naar bepaalde zoekwoorden te Googelen) is beter.

Als je de vraag uiteindelijk gaat beantwoorden, geef een waardevol antwoord. Suggereer geen klungelige omwegen als iemand het verkeerde programma of de verkeerde aanpak gebruikt. Stel goede programma's voor. Zet de vraag in ander perspectief.

Beantwoord de feitelijke vraag! Wanneer de vraagsteller zijn of haar vooronderzoek grondig heeft gedaan en heeft vermeld bij de vraag dat X, Y, Z, A, B, en C al geprobeerd zijn zonder goed resultaat, dan is het bijzonder onbehulpzaam om te reageren met Probeer A of B, of met een link naar iets die niet meer geeft dan Probeer X, Y, Z, A, B, of C..

Help je gemeenschap van de vraag te leren. Wanneer je een goede vraag tegen komt, vraag jezelf af Hoe kan de relevante documentatie of FAQ verbeterd worden zodat niemand deze vraag meer hoeft te beantwoorden?. Zend dan de verbeteringen naar diegene die de documentatie beheert.

Als je onderzoek gedaan hebt om een vraag te beantwoorden, toon dan je vaardigheden in plaats van het op te schrijven alsof je het antwoord uit je kont hebt getrokken. Het beantwoorden van een goede vraag is als een maaltijd schenken aan een hongerig persoon. Het aanleren van onderzoeksvaardigheden is als het leren hoe men een leven lang voedsel produceert.

Aanverwante zaken

Als je instructies nodig hebt in de basis van hoe computers, Unix en het Internet werken, bekijk The Unix and Internet Fundamentals HOWTO.

Als je software publiceert of verbeteringen voor software schrijft, probeer de richtlijnen te volgen zoals uiteen gezet in de Software Release Practice HOWTO.

Dankwoord

Evelyn Mitchell heeft bijgedragen aan enkele voorbeelden van domme vragen en inspireerde het Hoe een goed antwoord te geven gedeelte. Mikhail Ramendik heeft enkele waardevolle suggesties voor verbeteringen aangedragen.