Hoe vragen te stellen op een verstandige manier

Nederlandse vertaling van
"How To Ask Questions The Smart Way" door:
Eric Steven Raymond, Thyrsus Enterprises, <esr@thyrsus.com>
Rick Moen, <respond-auto@linuxmafia.com>

Vertaald door: Jasper Vries <smart-questions@jaspervries.nl>.

Gebaseerd op Revision 3.7, 06 Dec 2010.
Originele document: http://catb.org/~esr/faqs/smart-questions.html.

Copyright © 2001,2006 Eric S. Raymond, Rick Moen

Inhoudsopgave

Vertalingen
Disclaimer
Inleiding
Voordat je een vraag stelt
Als je een vraag stelt
Kies je forum zorgvuldig
Web en IRC forums gericht op nieuwkomers geven vaak het snelste resultaat
Als een tweede stap, gebruik mailing lijsten 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 (prive) email
Stel een duidelijke vraag
Wanneer je een vraag stelt over code
Plaats geen huiswerkopgaven
Vermijd doelloze vragen
Bestempel vragen niet als "belangrijk", ookal zijn ze dat voor jou
Beleefdheid doet geen pijn, en helpt soms zelfs
Plaats aansluitend een korte opmerking over 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 Chinese Dutch French Georgian German Greek Hebrew Japanese Polish Portuguese Romanian Russian Spanish Thai Turkish. Als je dit document wilt kopieren, mirrorren of vertalen, of citeren, bekijk dan de copying policy.

Disclaimer

Veel projectwebsites linken naar dit document in hun help-secties. Dat is goed, dat is het gebruik dat we beoogd hebben — maar als 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 het 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 het idee krijgt dat je deze direct van de auteurs kunt krijgen, ben jij een van die idioten. 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 met rust en iedereen zal tevreden zijn.

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 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 een geschenk. Goede vragen helpen onze kennis te ontwikkelen en onthullen vaak problemen die we nog niet gemerkt hadden of 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 iemand die wel een antwoord waard is. We noemen deze mensen losers (Engels; verliezers) (om historische redenen soms gespeld 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. Desalniettemin, onze stijl van het beantwoorden van vragen is toegespitst op mensen die wel geinteresseerd zijn en bereid zijn actief deel te nemen in de probleemoplossing. Dat zal niet veranderen. Het moet ook niet veranderen; als het zou veranderen, zouden we minder effectief de dingen kunnen doen 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 efficient kunnen besteden, aan winnaars.

Als je deze houding aanstootgevend vindt, verwaand of arrogant, 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 de moeite neemt dat mogelijk te maken. Maar het is simpelweg niet efficient 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 en bereid zijn om een actieve partner te zijn in de onwikkeling van 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 van het vragen van hackers 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. (Voor opmerkingen over deze vertaling, neem contact op met Jasper Vries.) Merk op dat dit document geen algemene handleiding met betrekking tot de netiquette is en dat suggesties die niet specifiek gericht zijn op het verkrijgen van bruikbare antwoorden op technische forums normaal gesproken worden afgewezen.)

Voordat je een vraag stelt

Voordat je een technische vraag stelt via email, 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 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 veelgestelde 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 zaken 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 zaken. We beantwoorden graag vragen voor 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 groups als ook het Web). Dit brengt je wellicht direct naar de oplossing van je probleem. Ookal krijg je geen geschikte resultaten, het zeggen van "Ik heb gegoogled op de volgende zoekwoorden, maar ik kreeg geen resultaten van enige betekenis" 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 Googlen. Lees en begrijp de veelgestelde vragen (FAQ's), leun achterover, relax 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 over een oplossing hebt nagedacht 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 foutieve vragen. Als je een vraag stelt gebaseerd op verkeerde vermoedens, zal J. Random Hacker waarschijnlijk antwoorden met een nutteloos letterlijk antwoord terwijl hij denkt "Stomme vraag...", in de hoop dat het krijgen waarom je gevraagd hebt in plaats van een bruikbaar antwoord je een lesje zal leren.

Veronderstel nooit 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 wel 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, het laten zien dat je bereid bent om te helpen 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 zou ik moeten bezoeken?" maken meer kans om een antwoord te krijgen dan "Geef me alsjeblieft de exacte procedure 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:

Hackers zullen vragen afschieten die ongepast zijn om hun communicatie kanalen te beschermen tegen overvloeden van irrelevatie. 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 (Frequently Asked Questions, Veel Gestelde Vragen) lijst, en naar mailinglijsten van het betreffende project en hun 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. Bijvoorbeeld, ga er niet van uit dat de auteur van een informatieve website je gratis raadgever wil zijn. Maak geen optimischische gokken over of je vraag welkom zal zijn — als je er niet zeker van bent, 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 goed idee om te zoeken naar sleutelwoorden die te maken hebben met je probleem in de archieven van de nieuwsgroep of mailinglijst voor dat 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 publiekelijk 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 zich teruggetrokken uit het verlenen van ondersteuning omdat de hoeveelheid nutteloze email naar hun inboxen ondraaglijk werd.

Web en IRC forums gericht op nieuwkomers geven vaak het snelste resultaat

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 je zomaar kunnen helpen. Als je een algemene web zoekopdracht heb gedaan (zoals je zou moeten), zoek dan evengoed in het forum; je internet zoekmachine 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, waar email gereserveerd is voor ontwikkel-verkeer. Zoek naar deze kanalen wanneer je project-specifieke hulp zoekt.

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, ookal denk je dat je weet wie jou het best kan antwoorden. Bekijk de documentatie en de homepage voor het adres van de mailinglijst van het project en gebruik het. Er zijn verschillende goede redenen voor dit gebruik:

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

Echter, als je zeker weet dat je vraag niet-triviaal is en je geen antwoord krijgt in de "gebruikers" lijst/forum voor enkele dagen, probeer de "ontwikkelaars" variant. We raden je aan om daar enkele dagen mee 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 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 niets 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, ookal staat er niets geheims in. Door het toestaan dat je bericht wordt doorgestuurd geef je je correspondent een keuze over hoe je bericht 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" (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" gedeelte specificeert welke ding of welke groep van dingen het probleem vormt 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 in groter detail 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 een oogopslag.

Meer algemeen, stel je de index 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 het opnieuw stellen van dezelfde vraag.

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 email.

Op forums 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 geen goed idee, 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 betrokken zijn in die discussie.

Maak het makkelijk om te reageren

Je vraag beeindigen 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 forums is het vragen om reacties via email buitengewoon grof, tenzij je denk dat de informatie gevoelig kan zijn (en iemand wil, om onbekende reden, deze informatie wel aan jou kenbaar maken, maar niet aan de rest van het forum). Als je een emailbericht 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" en dergelijke.

Schrijf in heldere, grammaticaal correct gespelde taal

We hebben ervaren dat mensen die achteloze en slordige schijvers zijn meestal ook achteloos en sloridig denken en code schrijven (in ieder geval vaak genoeg om op te wedden). 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 extra moeite aan het oppoetsen van je taalgebruik. Het hoeft niet stijf en formeel te zijn — de taal in de hacker cultuur 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. SCHRIJF NIET IN ALLEEN HOOFDLETTERS; dit wordt gezien als scheeuwen 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 half-analfabeet, wordt je hoogstwaarschijnlijk genegeerd. Gebruik geen msn-taal. Het schrijven van "thanks" als "thnx" maakt je een half-analfabete 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 simpelweg weg, en Engels is de werktaal van het Internet. Door het schrijven in 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 taalbarriere en mogelijkheden om die te voorkomen. Bijvoorbeeld:

Verzend vragen in toegankelijke standaardformaten

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

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 om te zien of je berichten in onopgemaakte tekst worden verzonden zonder dat onnodige troep wordt toegevoegd.

Ben precies en informatief over je probleem

Probeer zoveel mogelijk de vragen, die een hacker zal 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 in het 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 artikel geschreven met de titel How to Report Bugs Effectively. Ik beveel van harte aan 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 grote, ingewikkelde testopstelling hebt dat je programma stuk maakt, probeer deze te beperken 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 een documentatie, voorzie dan in de verbeterde tekst en geef aan op welke pagina's het moet komen staan.

Onthou, er zijn veel 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, ookal heb je gelijk. Het is in het bijzonder ongepast om de term "fout" of "bug" in de onderwerpregel te skanderen.

Als je je vraag stelt, is het het beste om te schrijven alsof je aanneemt dat jij iets verkeerd hebt gedaan, ookal ben je zelf behoorlijk zeker dat de fout in het programma zit. Als het echt een fout is, zul 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 grof of arrogant moeten zijn of niet een antwoord moeten eisen, gedragen zich als het andere uiterste van nederig zijn. "Ik weet dat ik een kansloze nieuweling en 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 fora 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 daar op 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 de klok herstart, 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, katoen, xanthium en Democraten groot brengt, en frivole welsprekendheid noch 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 uitwerken van iets dat verkeerd ging direct voor het optreden van het probleem. Daarom moet je exact beschrijven wat je hebt gedaan, wat de machine en software heeft 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 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. Onthoud dat meer niet noodzakelijk beter is; kies een foutopsporingsniveau dat informatief is zonder de lezer te overspoelen met zooi.

Als je beschrijving lang dreigt te raken (meer dan zo'n vier alinea's), kan het hulpvol 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 doel van hogere orde 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 beter geschikt voor de taak.

Vraag niet om antwoord te krijgen via (prive) email

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. Alsook, helpers krijgen een gedeelte van hun erkenning door gezien te worden door anderen als competent en kennisrijk.

Als je vraagt om een privaat antwoord, verstoor je het proces en de erkenning. Doe dit dus niet. Het is de keuze van de antwoorder of hij privaat wil reageren — en als hij dat doet, is dat meestal omdat hij 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 je belofte en vat het samen.

Stel een duidelijke vraag

Vragen met een open einde worden van tijd tot tijd 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 de expertise van een expert voor als overvloedige bron en de tijd om te reageren als een schaarse bron. 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 een code hebt die niet 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. Het plaatsen van enkele honderden regels code en het zeggen van "het werkt niet", zal ervoor zorgen dat je genegeerd wordt. Het plaatsen van enkele tientallen regels code en zeggen "na regel 7 verwachtte ik <x> te zien, maar <y> deed zich voor", heeft 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 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 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 vinden 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 vraag hebt die als huiswerkvraag door zou kunnen gaan, maar je kunt 'm toch niet oplossen, vraag dan in een forum of gebruikersgroep of (als laatste redmiddel) in een "gebruikers" lijst/forum van een project. Hackers zullen je vraag als huiswerkvraag afdoen, maar sommige ervaren gebruikers kunnen je op z'n minst een tip geven.

Vermijd doelloze vragen

Weersta de verleiding om je vraag om hulp af te sluiten met inhoudsloze vragen als "Kan iemand me helpen?" of "Is er een oplossing?". Allereerst: als je je probleemomschrijving 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.

Bestempel vragen niet als "belangrijk", ookal zijn ze 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 onmiddelijke en speciale aandacht.

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

Het is echter een risicovol ding om te doen, omdat de maatstaven van de hacker over wat interessant is waarschijnlijk afwijken van de jouwe. Vragen vanaf bijvoorbeeld het International Space Station worden belangrijk geacht, maar vragen met een weldadige of politieke achtergrond worden dat vrijwel zeker niet. 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 ook maar een vraag stelt.

Beleefdheid doet geen pijn, en helpt soms zelfs

Ben beleefd. Gebruik "Alsjeblieft" en "Bedankt voor je aandacht" of "Bij voorbaat dank". Maak duidelijk dat je het waardeert dat mensen hun tijd besteden door je kostenloos te helpen.

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

Hoe dan ook, 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 met betrekking tot de voorgaande aanbeveling, bezwaren zijn op het gebruik van "Alvast bedankt". Sommige hackers geloven dat dit de bedoeling inhoudt iemand niet achteraf te bedanken. Onze aanbeveling is om of eerst "Alvast bedankt" te zeggen en iedereen nogmaals achteraf te bedanken, of 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 geholpeen heeft; laat 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' of 'OPGELOST' of een soortgelijke kreet aan de onderwerpregel toe te voegen. Op hoogfrequente mailinglijsten weet de lezer dat hij zijn tijd niet hoeft te verdoen zodra hij een onderwerp ziet over "Probleem X", eindigend met "Probleem X - OPGELOST" (tenzij hij 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 simpele "Hallo — het was een defecte netwerkkabel! Bedankt, allemaal. -Willem" is beter dan geen reactie. 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 oorzaak 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 meegehopen 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 guru's 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.

Besef 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 het.

RTFM heeft een jongere aanverwand. 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. 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 als je deze met de paplepel ingegoten krijgt.

Voel je echter niet beledigd hierdoor; volgens hacker standaarden 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.". Hier is een slechte vervolgvraag: "Wat is een zentry?". Een goede vervolgvraag is: "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 lijkt als grofheid 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 het om hun gemak stellen van mensen.

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, 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 hacker gemeenschap en zal jij als de schuldige wordt aangewezen. Dit zal de kans dat je informatie of hulp krijgt aantasten.

Aan de andere kant zul je zo nu en dan tegen zinloze of ongerechtvaardigde grofheid aanlopen. 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 maar het beste van het toetsenbord af blijven 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. Als je zelf geen hacker bent; kan het helpen om te gaan met onze excentriteiten door te denken dat we hersenbeschadiging hebben opgelopen. Ga je gang. Het zal ons niet deren; we houden ervan om te zijn wie we zijn, en hebben meestal een gezonde dosis scepsis over het ingedeeld worden in klinische categorieën.)

In het volgende gedeelte zullen we het hebben over een ander geval; de vorm van "grofheid" die je zult tegenkomen als jij je misdraagt.

Over het niet reageren als een loser

Kansen zijn dat je het een paar keer verpest op de fora van de hacker gemeenschap — 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 rechtzaken, 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 toepasselijk.

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 email: 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 ondoordachte zin van hyper-beleefdheid, deelnemers verbannen werden doordat zij reageerden op slechte vragen van anderen en verteld werden "Zeg niets als je niet wilt helpen.". Het resultaat was het vertrek van betekenisvolle deelnemers wat leidde tot het vervallen van de forums tot betekenisloos geklets en het nutteloos worden als technische forums.

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

Onthoud: wanneer een hacker je vertelt dat je het verpest hebt en je (hoe vernederend dan ook) 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 omdat je een nieuwkomer bent met een theatricale overgevoelige ziel en waanideeën over gerechtigheid.

Soms zullen mensen je persoonlijk aanvallen zonder duidelijke reden, etc., ookal 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 heeft.

Raak echter 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 naar de manier waarop je het verpest hebt of versleutelde antwoorden op je echte vraag (dit komt ook voor).

Vragen die men niet moet stellen

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

Q: Waar kan ik programma of bron X vinden?
Q: Hoe kan ik X gebruiken om Y te bereiken?
Q: Hoe kan ik mijn shell prompt instellen?
Q: Kan ik een AcmeCorp document naar een TeX bestand converteren met de Bass-o-matic file converter?
Q: Mijn [programma | configuratie | SQL statement] werkt niet.
Q: Ik heb problemen met mijn Windows machine. Kun je me helpen?
Q: Mijn programma werkt niet. Ik denk dat systeembron X defect is.
Q: Ik heb problemen met het installeren van Linux of X. Kun je me helpen?
Q: Hoe kan ik root kraken/kanaal beheer toegang stelen/iemands email lezen?

Q: Waar kan ik programma of bron X vinden?
A: Op dezelfde plaats waar ik het gevonden heb, sukkel — aan de andere kant van een zoekopdracht. Werkelijk, weet nog steeds niet iedereen hoe je Google moet gebruiken?

Q: Hoe kan ik X gebruiken om Y te bereiken?
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 vaak aan dat een persoon wel het een en ander af weet van 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.

Q: Hoe kan ik mijn shell prompt instellen?
A: Als je slim genoeg bent om deze vraag te stellen, ben je slim genoeg voor RTFM om zelf een antwoord te vinden.

Q: Kan ik een AcmeCorp document naar een TeX bestand converteren met de Bass-o-matic file converter?
A: Probeer en vind uit. Als je dat gedaan zou hebben, zou je (a) het antwoord weten en (b) mijn tijd niet verdoen.

Q: 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 slepen — ik heb wel betere dingen te doen. Als ik zoiets zie, is mijn reactie normaal gesproken een van het volgende:

Q: 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 als deze gaat over een programma dat een versie specifiek voor Windows heeft, of samenwerkt met met Windows (zoals Samba). Ben alleen niet verrast als uit het antwoord blijkt dat het probleem bij Windows ligt en niet bij het programma, omdat Windows in het algemeen sowieso stuk is, waardoor dit vaak het geval is.

Q: Mijn programma werkt niet. Ik denk dat systeembron 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, welke veel gebruikt worden door honderden of duizenden andere mensen, tegen komt, ligt het meer voor de hand dat je 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.

Q: 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.

Q: Hoe kan ik root kraken/kanaal beheer toegang stelen/iemands email lezen?
A: Je bent een proleet 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 toelichten 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 te krijgen.

Slim: Ik heb Google gebruikt om iets te vinden over "Floony Flurbamatic 2600", 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 met 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 boeren en je luiers verschoond?", 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 ideeen voor meer tests die ik kan uitvoeren om het probleem te lokaliseren?

Deze persoon lijkt een antwoord waard. Hij of zij laat probleem-oplossend vermogen zien in plaats van het passief afwachten van een antwoord van hoger af.

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 het stellen van de vraag 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 mede-leden en nodigde hen uit om mij te raadplegen als waardig mede-lid. Ik toonde ook respect voor de waarde van hun tijd door het mededelen van de doodlopende straten die ik al was tegen gekomen.

Nadien 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 afgeschoten of genegeerd 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 in 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 eisen van een beginneling.

Er zijn vele online en lokale gebruikersgroepen die enthousiast zijn over de software, ookal 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 (Red Hat en SpikeSource zijn twee van de bekendste; er zijn vele andere). 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 al was de software gratis, verwacht niet 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 een persoon om de ondersteuningsverzoeken van meer dan 10 000 gebruikers af te handelen. Onthoud dat ookal zou je moeten betalen voor ondersteuning, je nog steeds veel minder betaalt dan als je de software ook 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, ookal zijn de dat niet.

Reageer off-line op iemand die de eerste keer iets verkeerd doet. Er is geen reden om iemand publiekelijk te vernederen als deze persoon een eerlijke 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 indringend klinkend antwoord is slechter dan geen enkel antwoord. Stuur iemand niet niet de verkeerde richting op, simpelweg omdat het leuk is om over te komen als een expert. Ben nederig en eerlijk; ben een goed voorbeeld voor de vraagsteller en de meelezers.

Als je niet kunt helpen, bemoei je er niet mee. Maak geen grapjes 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 jezelf 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 (ookal is het alleen een suggestie om naar bepaalde zoekwoorden te Google-en) 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.

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 stellen?". Zend dan de verbeteringen naar diegene die het document beheert.

Als je onderzoek gedaan hebt om een vraag te beantwoorden, toon je vaardigheid in plaats van het te doen voorkomen dat je het antwoord zomaar in een keer opgeschreven hebt. Het beantwoorden van een goede vraag is als een maaltijd schenken aan een hongerig persoon. Het aanleren van onderzoeks vaardigheid 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 uitbreidingen 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.

 

Gehost door Jasper Vries Webbuilding