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

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.

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:

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

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

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 “gebruikers”lijst/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 “gebruikers”lijst/forum gedurende enkele dagen, probeer de “ontwikkelaars”variant. 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.)

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.

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.

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.

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:

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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”.)

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.

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 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?”

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.