Personliga verktyg
Du är här: Hem Dokumentation How-tos Att ställa smarta frågor
Donera
Inloggning


Glömt ditt lösenord?
Ny användare?
« Juli 2014 »
Juli
TiOnToFr
123456
78910111213
14151617181920
21222324252627
28293031
 
Dokumentåtgärder

Att ställa smarta frågor

Hur får man hackare och erfarna användare att ge användbara svar och uppskatta ens frågor? Hur tolkar man svar? Vilka fallgropar bör man undvika? Hackarlegenderna Eric S. Raymond och Rick Moen beskriver uttömmande frågeställandets ädla konst.

Eric Steven Raymond
Thyrsus Enterprises
<esr@thyrsus.com>

Rick Moen
<rick@linuxmafia.com>

Originalets titel: How To Ask Questions The Smart Way
Revision 3.1 (28 Oct 2004)

Copyright © 2001 Eric S. Raymond

Översättning av Alexander Nordström
Svenska Linuxföreningen
<lx [at] se.linux.org>

Copyright © 2004 Alexander Nordström

Detta verk skyddas av upphovsrättslagen. För mångfaldigande, spegling, översättning, eller omfattande citering av detta dokument, se kopieringspolicyn för det engelska originalet. För frågor om översättningen, kontakta i första hand Alexander Nordström, inte originalets författare.

Innehållsförteckning

Introduktion

Vilken typ av svar man får på sina tekniska frågor beror i hackarkulturen lika mycket på hur man frågar som på hur svårt svaret är att finna. Den här texten visar hur man ställer frågor på ett sätt som förbättrar möjligheten att få ett tillfredsställande svar.

Nu när användandet av öppen källkod är utbrett kan man ofta få svar från andra, mer erfarna användare, istället för från hackare. Detta är en Bra Sak; användare är i allmänhet lite mer toleranta när det gäller den sortens problem som nybörjare ofta har. Men att behandla erfarna användare som hackare på det sätt vi rekommenderar här är i allmänhet det mest effektiva sättet att få användbara svar från dem också.

Det första man måste förstå är att hackare faktiskt tycker om svåra problem och bra, tankeväckande frågor om dem. Om vi inte gjorde det skulle vi inte hålla på vad vi gör. Om du ger oss en intressant fråga att bita i kommer vi att vara dig tacksam; bra frågor är stimulerande gåvor. Bra frågor får oss att utveckla vår uppfattningsförmåga och avslöjar ofta problem som vi kanske inte hade märkt eller tänkt på annars. ”Bra fråga!” är en kraftfull och hjärtlig komplimang bland hackare.

Detta till trots har hackare rykte om sig att bemöta simpla frågor med vad som liknar fientlighet eller arrogans. Ibland förefaller det som om vi är reflexmässigt oartiga mot nybörjare och okunniga. Men så är inte fallet.

Men vi är—och det ber vi inte om ursäkt för—osympatiska gentemot folk som förefaller ovilliga att tänka själva eller göra sina egna läxor innan de ställer frågor. Sådana människor är tidsdödare—de tar utan att ge tillbaks, de ödslar tid som vi kunde utnyttjat till att besvara en mer intressant fråga åt någon mer värdig ett svar. Vi kallar sådana människor förlorare (eller ”losers”, och av historiska skäl stavar vi det ibland ”lusers”).

Vi inser att det finns många som bara vill använda programmen vi skriver och inte har något intresse av att lära sig tekniska detaljer. För de flesta är datorn bara ett verktyg, ett medel för att nå ett mål; de har viktigare saker att göra och liv att leva. Vi inser det och förväntar oss inte att alla skall intressera sig för de tekniska frågor som fascinerar oss. Detta till trots är vårt sätt att besvara frågor bäst anpassat för folk som faktiskt har ett sådant tekniskt intresse och en vilja att aktivt delta i problemlösningen. Det kommer inte att ändras, och det bör det inte göra sheller; om det gjorde det skulle vi bli mindre effektiva på det vi gör bäst.

Vi är (i stort sett) frivilliga. Vi skänker tid av våra upptagna liv för att svara på frågor, och stundtals överväldigas vi av dem. Därför sållar vi hänsynslöst. Framförallt slänger vi bort frågor från folk som förefaller vara förlorare, så att vi så effektivt som möjligt kan använda vår tid till att besvara frågor från ”vinnare”.

Om du tycker att den här attityden är irriterande, nedlåtande eller arrogant, fundera lite över dina antaganden. Vi förväntar oss inte att du skall knäböja för oss—tvärtom, de flesta av oss önskar inget hellre än att se dig som vår jämlike och välkomna dig till vår kultur om du anstränger dig för att göra det möjligt. Men det är helt enkelt inte effektivt att hjälpa folk som inte vill hjälpa sig själva. Det är okej att vara okunnig; det är inte okej att spela dum.

Så medan det inte är nödvändigt att redan vara tekniskt kompetent för att få vår uppmärksamhet är det nödvändigt att uppvisa den sortens attityd som leder till kompetens—var alert, eftertänksam, observant och villig att ta en aktiv del i att ta fram ett svar. Om du inte kan leva med sådan diskriminering föreslår vi att du betalar någon för ett kommersiellt kontrakt för användarstöd istället för att be hackare att personligen donera hjälp.

Om du bestämmer dig för att komma till oss för att få hjälp vill du inte vara en av förlorarna. Du vill inte framstå som en heller. Det bästa sättet att få ett snabbt och tillmötesgående svar är att ställa frågan som en person med intelligens, självförtroende och vett som bara råkar behöva hjälp med just det här problemet.

Innan du frågar

Innan du ställer en teknisk fråga via e-post, i en nyhetsgrupp eller i ett webbforum, gör följande:

  1. Försök att hitta svaret genom att söka på nätet.
  2. Försök att hitta svaret genom att läsa manualen.
  3. Försök att hitta svaret genom att läsa vanliga frågor och svar (FAQ).
  4. Försök att hitta ett svar genom att undersöka och experimentera.
  5. Försök att hitta ett svar genom att fråga en kunnig vän.
  6. Om du är programmerare, försök att hitta ett svar genom att läsa källkoden.

När du ställer din fråga, visa att du har gjort detta först; det hjälper till att fastställa att du inte är en slöfock som slösar med andras tid. Ännu bättre, visa vad du lärt dig genom att göra det. Vi tycker om att svara på frågor från personer som visar att de kan lära sig från svaren de får.

Använd till exempel Google för att söka efter felmeddelandet, om du fått ett sådant (och sök både i Googles arkiv av nyhetsgrupper och webbsidor). Detta kan mycket väl leda dig direkt till dokumentation av lösningen eller en tråd i en e-postlista som besvarar din fråga. Även om det inte skulle göra det är det bra att kunna skriva att ”jag googlade efter det följande uttrycket men fick inte fram någonting som såg användbart ut” i en förfrågan via e-post eller i en nyhetsgrupp.

Förbered frågan. Tänk igenom saken. Frågor som verkar hastigt ställda får hastigt formulerade svar eller inga svar alls. Ju mer du demonstrerar att du tänkt och försökt lösa dina problem innan du ber om hjälp, desto troligare är det att du faktiskt får hjälp.

Se upp så att du inte ställer fel fråga. Om frågan du ställer grundar sig på ett felaktigt antagande kommer J. Någon Hackare att svara med ett otroligt bokstavligt svar muttrandes ”dum fråga…” i hopp om att erfarenheten att få vad du bad om istället för vad du behövde lär dig en läxa.

Anta aldrig att du är berättigad ett svar. Det är du inte; du betalar ju faktiskt inte för tjänsten. Om du förtjänar ett svar gör du det genom att ställa en intressant och tankeväckande fråga med substans—en som bidrar till allas upplevelse istället för att bara passivt kräva andras kunskap.

Att däremot visa att du är villig att hjälpa till i processen för att ta fram en lösning är en väldigt god början. ”Kan någon ge mig en ledtråd?”, ”vad saknas i mitt exempel?” och ”vilken webbplats borde jag ha tittat på?” har bättre förutsättningar att få ett svar än ”var snäll och posta instruktioner för hur jag skall göra”, eftersom du då visar att du verkligen är beredd att fullborda processen om någon bara kan visa rätt riktning.

När du frågar

Välj forum noggrant

Var förnuftig med var du ställer din fråga. Andra kommer antagligen att strunta i dig eller se dig som förlorare om du:

  • postar din fråga i ett forum där frågan är utanför ämnet
  • postar en väldigt elementär fråga där man förväntar sig avancerade tekniska frågor eller vice versa
  • korspostar till alltför många olika nyhetsgrupper
  • skickar ett personligt e-postmeddelande till någon som vare sig är bekant med dig eller personligen ansvarig för att lösa ditt problem

Hackare struntar i frågor som är felriktade för att skydda sina kommunikationskanaler från att dränkas i irrelevant nonsens. Du vill inte råka ut för detta.

Första steget är därför att hitta rätt forum. Som sagt, Google och andra metoder för att söka på nätet är dina vänner. Använd dem för att hitta webbsidan för det projekt som har mest att göra med hårdvaran eller programvaran som du har problem med. Oftast har den länkar till vanliga frågor och svar (FAQ) och till projektets e-postlistor och dess arkiv. Dessa e-postlistor är det slutgiltiga stället att gå till för att be om hjälp om ingen av dina egna ansträngningar (inklusive att läsa de där vanliga frågorna och svaren som du hittade) lyckas hitta svaret åt dig. Det kan också hända att projektets webbsida beskriver eller länkar till den procedur som bör användas för att rapportera buggar; följ den om så är fallet.

Att skicka iväg ett e-postmeddelande till en person eller ett forum som du inte är bekant med är riskabelt—i bästa fall. Antag till exempel aldrig att den som författat en informativ webbsida vill vara din gratiskonsult. Gör inga optimistiska antaganden om huruvida din fråga kommer att välkomnas—om du är osäker, skicka den någon annanstans eller avstå från att skicka den alls.

När du väljer webbforum, nyhetsgrupp eller e-postlista, sätt inte alltför stor tillit enbart till dess namn; se efter om det finns vanliga frågor och svar eller regler som kan bekräfta att din fråga är inom rätt område. Läs lite av den pågående diskussionen innan du postar så att du kan få en uppfattning om hur saker och ting sker där. Dessutom är det en god idé att söka efter nyckelord som har att göra med ditt problem i nyhetsgruppen eller e-postlistans arkiv innan du postar. Det kan visa sig att du hittar ett svar, och om du inte gör det kan det hjälpa dig att formulera en bättre fråga.

Kasta dig inte över alla tillgängliga kanaler på en gång. Det är jämförbart med att skrika, och det irriterar folk. Använd en i taget.

Se till att du vet vad ämnet för din fråga är! Ett klassiskt misstag är att ställa en fråga om Unix eller Windows programmeringsgränssnitt i ett forum för ett språk eller bibliotek som är portabelt till båda miljöerna. Om du inte inser varför detta är ett misstag är det bäst att inte ställa några frågor alls tills du förstår.

I allmänhet, frågor till ett väl valt öppet forum har bättre förutsättningar att få användbara svar än samma frågor i ett privat forum. Anledningarna till detta är flera. En är helt enkelt antalet personer som kan svara. En annan är publikens storlek; hackare svarar hellre på frågor som lär ut till många än frågor som bara lär ut till några få.

Skickliga hackare och upphovsmän till populära program får, som man kan förstå, redan mer än sin rättmätiga del av feladresserade meddelanden. Genom att bidra till störtfloden riskerar man att i extremfallet bli droppen som får bägaren att rinna över—många gånger har personer som bidragit till populär projekt dragit tillbaka sitt stöd för att sidoeffekterna i form av värdelös e-posttrafik till deras personliga konton blivit outhärdlig.

Webb- och IRC-forum inriktade på nybörjare ger oftast det snabbaste svaret

Det kan hända att din lokala användarförening eller din Linuxdistribution tillkännager ett webbforum eller en IRC-kanal där nybörjare kan be om hjälp. Dessa är bra första anhalter att ställa frågor, särskilt om du misstänker att du har stött på ett ganska enkelt eller vanligt problem. En tillkännagiven IRC-kanal är en öppen inbjudan att ställa frågor där, och ofta får man svar i realtid.

Faktum är att om programmet som du har problem med kommer från en distribution (vilket är vanligt idag) är det ofta bättre att fråga i distributionens forum eller e-postlista innan man försöker med programprojektets forum eller lista. Hackarna från projektet svarar ofta bara ”använd vår version”.

Innan du postar till ett webbforum, se om det har en sökfunktion. Om det har det, pröva med ett par nyckelordssökningar för någonting passande för ditt problem; det kan hända att det hjälper. Om du gjorde en allmän webbsökning (så som du borde gjort), sök i forumet ändå; det är inte säkert att din sökmotor för hela webben indexerat just detta forum i sin helhet nyligen.

Det blir allt vanligare att projekt erbjuder användarstöd via webbforum eller IRC-kanaler och reserverar e-post för mer utvecklarinriktad trafik. Leta därför efter de kanalerna först när du söker projektspecifik hjälp.

Som ett andra steg, använd projektets e-postlistor

När ett projekt har en e-postlista för utvecklare, skriv till e-postlistan, inte till individuella utvecklare, även om du tror dig veta vem som bäst kan besvara frågan. Läs projektets dokumentation och hemsida för att hitta adressen till projektets e-postlista och använd den. Det finns flera bra anledningar att göra detta:

  • Frågor som är bra nog att besvaras av en enskild utvecklare är också av värde för hela gruppen. Om du däremot misstänker att din fråga är för dum för en e-postlista är det inte en ursäkt att trakassera enskilda utvecklare.
  • Att ställa frågor till listan fördelar arbetsbördan mellan utvecklarna. Den enskilde utvecklaren (särskilt om han är projektledaren) kan vara alltför upptagen för att svara på dina frågor.
  • De flesta e-postlistor arkiveras, och arkiven indexeras av sökmotorer. Någon annan kan hitta din fråga och svaret på webben istället för att fråga igen.
  • Om vissa frågor ställs särskilt ofta kan utvecklarna använda den informationen för att förbättra dokumentationen eller programmet så att dessa blir mindre förvirrande. Men om frågorna ställs privat får ingen en fullständig överblick över vilka frågor som ställs oftast.

Om ett projekt har separata e-postlistor för ”användare” och ”utvecklare” (eller ”hackare”) och du inte hackar i koden, fråga i forumet eller listan för ”användare”. Anta inte att du är välkommen i utvecklarlista, där din fråga antagligen kommer att ses som brus i utvecklartrafiken.

Men om du är säker på att din fråga inte är trivial och du inte fått något svar i användarlistan eller -forumet på flera dagar, pröva att fråga i listan eller forumet för utvecklare. Det är en mycket god idé att bara läsa meddelandena där i några dagar för att lära sig vanorna där (faktum är att detta är en god idé på alla privata eller halvprivata listor).

Om du inte kan hitta adressen till projektets e-postlista utan bara ser adressen till den som sköter projektet kan du skriva till denne. Men inte ens i det fallet bör man anta att e-postlistan inte finns. Skriv uttryckligen i meddelandet att du försökte men inte lyckades hitta en lämplig e-postlista. Nämn också att du inte har något emot att ditt meddelande skickas vidare till andra. (Många anser att privat e-post bör hållas privat, även om det inte finns något hemligt i innehållet. Genom att tillåta att ditt meddelande vidarebefordras ger du den du skriver till valmöjligheter i hanteringen av ditt meddelande.)

Använd meningsfulla, specifika ärenderader

I e-postlistor, nyhetsgrupper eller webbforum är ärenderaden din chans att dra till dig uppmärksamhet från kvalificerade experter med cirka femtio tecken eller mindre. Slösa inte bort denna genom struntprat som ”snälla hjälp mig” (för att inte tala om ”SNÄLLA HJÄLP MIG!!!!”; meddelanden med sådana ärenderader kastas reflexmässigt). Försök inte imponera oss med hur mycket du våndas; ägna istället utrymmet åt en jättekoncis problembeskrivning.

En bra standard för ärenderader som används av många organisationer som sysslar med användarstöd är ”sak-avvikelse”. ”Sak”-delen specificerar vilken eller vilka saker som problemet uppstår med, och ”avvikelse”-delen beskriver hur det faktiska beteendet skiljer sig från det förväntade beteendet.

Dumt:
HJÄLP! Grafiken funkar inte som den ska på min bärbara!
Smart:
XFree86 4.1 deformerad muspekare, Fooware MV1005 grafikchipset
Smartare:
XFree86 4.1 muspekare med Fooware MV1005 grafikchipset - deformerad

Att skriva en beskrivning i formen ”sak-avvikelse” hjälper dig att tänka på problemet i detalj. Vad påverkas? Bara muspekaren eller även annan grafik? Är detta specifikt för XFree86? För version 4.1? Är detta specifikt för Foowares grafikchipset? MV1005-modellen? En hackare som ser resultatet kan omedelbart förstå vad du har problem med och vilket problem du har, med ett ögonkast.

Mer allmänt, tänk dig att du tittar på en innehållsförteckning i ett arkiv med frågor där bara ärenderaden syns. Se till att din ärenderad motsvarar din fråga såpass väl att nästa person som söker i arkivet med en liknande fråga kan följa tråden till ett svar istället för att ställa frågan en gång till.

Om du ställer frågan i ett svar, se till att ändra ärenderaden för att visa att du ställer en fråga. En ärenderad som ”Re: test” eller ”Re: ny bugg” har mindre chans att få användbar uppmärksamhet. Tänk också på att klippa ner citat från tidigare meddelanden till minsta möjliga som krävs för att nytillkomna läsare skall förstå sammanhanget.

När du börjar en ny tråd, svara inte bara på något annat meddelande. Detta begränsar din publik. Vissa e-postprogram, såsom Mutt, låter användaren sortera meddelanden i trådar och dölja alla meddelanden i en tråd utom det första. De som gör så ser aldrig ditt meddelande.

Att ändra ärenderaden är inte tillräckligt. Mutt och andra e-postprogram tittar på meddelandets e-posthuvud för att placera det i rätt tråd, inte ärenderaden. Påbörja istället ett helt nytt meddelande.

I webbforum är reglerna lite annorlunda, eftersom meddelanden ofta är mer nära knutna till specifika diskussioner och inte kan ses utanför sina trådar. Att ändra ärenderaden när man ställer en fråga i ett svar är inte lika viktigt (en del forum tillåter inte ens att svar har en annan ärenderad och få läser dem när de tillåts). Men att ställa en fråga i ett svar är en tveksam vana i sig, eftersom det bara ses av dem som läser den tråden. Så om du inte är säker på att du vill fråga dem som redan deltar i tråden, påbörja en ny tråd.

Gör det lätt att svara

Att avsluta din fråga med ”vänligen skicka svar till…” gör det osannolikt att du får svar. Om du inte kan bemöda dig att på några sekunder konfigurera ditt e-postprograms ”Reply-To”-rad kan inte heller vi bemöda oss att fundera på ditt problem några sekunder. Om ditt e-postprogram inte har en sådan möjlighet, skaffa ett bättre e-postprogram. Om ditt operativsystem inte stödjer några e-postprogram som tillåter detta, skaffa ett bättre operativsystem.

Att be om svar via e-post i webbforum är rent oförskämt såvida du inte misstänker att informationen kan vara känslig (och att någon av någon okänd anledning kan tänkas låta dig, men inte hela forumet, ta del av den). Om du vill få e-post när någon svarar i tråden, ställ in webbforumet så att detta sker; denna funktion stöds nästan överallt genom val som ”bevaka tråden”, ”skicka e-post när någon svarar”, etc.)

Skriv tydligt, grammatiskt riktigt och rättstavat

Vi har av erfarenhet kommit fram till att folk som är oengagerade och slarviga skribenter oftast också är oengagerade och slarviga när det gäller att tänka och koda (åtminstone tillräckligt ofta för att man skall satsa på att så är fallet). Att svara på frågor från oengagerade och slarviga tänkare är inte givande; vi använder hellre vår tid till annat.

Därför är viktigt att uttrycka din fråga på ett bra och tydligt sätt. Om du inte kan bemöda dig att göra det kan vi inte bemöda oss att ge dig uppmärksamhet. Ansträng dig lite extra och vårda ditt språk. Det behöver inte vara stelt eller formellt—faktum är att hackarkulturen värderar informellt, slangigt och humoristiskt språk använt med precision. Men det måste vara precist; det måste finnas någon form av indikation att du tänker och är uppmärksam.

Stava, stava av, och använd versaler och gemener korrekt. Använd inte särskrivningar eller förkortade ord som ”e” för ”är” och ”lr” för ”eller”. Skriv inte med ENBART STORA BOKSTÄVER, det ses som att man skriker och anses oartigt. (Enbart små bokstäver är bara något mindre irriterande, eftersom det är svårt att läsa. Alan Cox slipper undan med det, men du gör det inte.)

Mer allmänt, om du skriver som en halvanalfabetisk drulle kommer folk antagligen att strunta i dig. Att skriva som en 3lajt hax0rskriptunge är en absolut dödskyss och gör att andra svarar genom att tiga som muren (eller i bästa fall att de svarar med förakt och sarkasm).

Om du ställer frågor i ett forum där något annat än ditt modersmål används kan du förvänta dig en begränsad förståelse för språkfel—men ingen extra tolerans för lathet (och ja, vi kan vanligtvis se skillnaden). Och om du inte vet vilka språk den du skriver till talar, skriv på engelska. Upptagna hackare har för vana att slänga frågor de inte förstår, och engelska är lingua franca på Internet. Genom att skriva på engelska minskar du risken för att din fråga slängs utan att läsas.

Skicka frågor i format som gör dem lätta att ta till sig

Om du gör din fråga onödigt svår att läsa ökar risken att andra hoppar över frågan till förmån för en lättläst fråga. Gör därför följande:

  • Skicka e-post i vanligt textformat, inte HTML. (Det är inte svårt att stänga av HTML.)
  • MIME-bilagor är vanligtvis okej, men bara om de innehåller faktiskt innehåll (såsom en bifogad källkodsfil eller programfix) och inte bara automatgenererat skräp från ditt e-postprogram (såsom en till kopia av ditt meddelande).
  • Skicka inte e-post där hela stycken består av enskilda rader utan fasta radbrytningar. (Detta gör det svårt att svara på enbart en del av meddelandet.) Se till så att ditt meddelande kan läsas med ett program som visar 80 tecken i bredd genom att ställa in ditt program att bryta rader någonstans före den åttionde kolumnen.
  • Trots detta bör du se till så att sådana fasta radbrytningar inte läggs till i data (såsom utdrag ur loggfiler eller kopior på resultat från in- och utmatning). Data bör inkluderas som det är så att den som svarar vet att de ser vad du såg.
  • Skicka inte meddelanden kodade som MIME Quoted-Printable till engelskspråkiga forum. Att göra det kan vara nödvändigt när man skriver på ett språk som ASCII inte täcker, men många e-postprogram hanterar det inte. När så är fallet gör alla förekomster av =20 i meddelandet det fult och svårläst.
  • Antag aldrig någonsin att hackare kan läsa slutna, leverantörsspecifika format som Microsoft Word eller Excel. De flesta hackare reagerar lika bra på sådant som du skulle göra om du fick en hög ångande svingödsel avlämpat utanför dörren. I de fall de kan stå ut med det är det högst motvilligt.
  • Om du skickar e-post från en Windowsmaskin, stäng av Microsofts dumma funktion för ”Smarta citattecken”, detta för att undvika att peppra ditt meddelande med skräptecken.
  • Undvik att missbruka funktioner som ”smilisar” och ”HTML” (när de finns tillgängliga). En smilis eller två är vanligtvis okej, men glättigt färgad text brukar få folk att tycka att du är töntig. Grov överanvändning av smilisar, färg och fonter får dig att framstå som en fnittrig tonårstjej, vilket inte är en bra idé om du inte är mer intresserad av sex än svar.

Om du använder ett e-postprogram med grafiskt användargränssnitt (såsom Netscape Messenger, MS Outlook eller liknande), se upp så att det inte bryter mot dessa regler med sina standardinställningar. Många sådana program har ett menyalternativ för att ”Visa källkod”. Använd detta på något meddelande i din mapp för skickade meddelanden för att se att du skickar vanlig text utan onödigt krafs.

Beskriv problemet precist och informativt

  • Beskriv symptomen på problemet noggrant och tydligt
  • Beskriv miljön där problemet uppstår (maskin, operativsystem, program, etc.). Tala om vilken distribution och version du använder (t.ex.: ”Fedora Core 2”, ”Slackware 9.1”, etc.).
  • Beskriv hur du undersökt och försökt förstå problemet innan du ställer frågan.
  • Beskriv de steg du själv tagit för att diagnostisera och isolera problemet innan du ställer frågan.
  • Beskriv alla nytillkomna förändringar i din dator eller programvarukonfiguration som kan vara relevanta.

Gör dit bästa för att förutse de frågor en hackare kan tänkas ställa och försök besvara dem redan när du ber om hjälp.

Simon Tatham har skrivit en utmärkt text om hur man skriver en effektiv buggrapport. Jag rekommenderar starkt att du läser den.

Omfattning är inte precision

Du måste vara precis och informativ. Detta mål uppnås inte genom att bara dumpa enorma mängder kod eller data i en förfrågan. Om du har ett stort, komplicerat testfall som får ett program att falera, försök att klippa ner det och göra det så litet som möjligt.

Detta är nyttigt av minst tre anledningar. Ett: sannolikheten att få ett svar ökar om det syns att du lagt ner arbete på att förenkla frågan. Två: Att förenkla frågan gör det troligare att du får ett användbart svar. Tre: det kan hända att du under arbetet med att förfina din buggrapport hittar ett sätt att lösa eller kringgå problemet.

Påstå inte att du hittat en bugg

När du har problem med ett program, påstå inte att du hittat en bugg om du inte är väldigt, väldigt säker på din sak. Tips: om du inte kan tillhandahålla en programfix i form av källkod som löser problemet eller ett regressionstest gentemot en tidigare version som visar inkorrekt beteende, så är du antagligen inte tillräckligt säker. Detta gäller även dokumentation. Om du hittat en ”bugg” i dokumentationen, tillhantahåll ny text och ange var den hör hemma.

Kom ihåg, det finns många andra användare som inte upplever ditt problem. Annars skulle du ha läst om det när du läste dokumentationen och sökte på nätet (du gjorde väl det innan du klagade?). Detta innebär att det troligen är du som gör något galet, inte programmet.

Personerna som skrivit programmet har jobbat hårt för att det skall fungera så bra som möjligt. Om du påstår att du hittat en bugg antyder du att de gjort något fel, och det kommer nästan alltid att göra dem upprörda—även om du har rätt. Det är särskilt odiplomatiskt att skrika ”bugg” i ärenderaden.

När du formulerar din fråga är det bäst att skriva som om du antar att du gör något fel, även om du i stillhet är rätt säker på att du faktiskt hittat en bugg. Om det verkligen är en bugg kommer du att få reda på det i svaret. Spela dina kort så att den som underhåller programmet ber dig om ursäkt om det verkligen är en bugg, hellre än så att du tvingas be dem om ursäkt om du ställt till det.

Man slipper inte undan sina läxor genom att kräla i stoftet

En del inser att de inte bör bete sig oartigt eller arrogant och begära ett svar, men faller istället i den motsatta fällan, nämligen att kräla i stoftet. ”Jag vet att jag är en patetisk förlorare till nybörjare, men…”. Detta är distraherande och inte hjälpsamt. Det är särskilt irriterande när det paras med en otydlig problembeskrivning.

Slösa inte bort din egen eller andras tid med oborstad primalpolitik. Presentera istället din fråga med bakgrundsfakta så tydligt som du kan. Detta är ett bättre sätt att finna din plats än att kräla i stoftet.

En del webbforum har särskilda avdelningar för nybörjarfrågor. Om du känner att du har en nybörjarfråga, ställ den där. Men kräla inte i stoftet där heller.

Beskriv problemets symptom, inte dina gissningar

Det är inte produktivt att berätta för hackare vad du tror är orsaken till ditt problem. (Om din diagnos vore så skickligt ställd, skulle du behöva fråga andra om hjälp?) Beskriv därför helt enkelt symptomen som visar att något går fel hellre än dina tolkningar och teorier. Låt dem tolka och diagnostisera. Om du känner att din gissning är viktig, presentera den tydligt som just en gissning och beskriv varför det svaret inte löser problemet.

Dumt:
Jag får SIG11-fel hela tiden när kärnan kompileras, och jag misstänker att det finns en hårfin spricka i en av lödningarna på moderkortet. Hur letar jag efter sådana?
Smart:
Min hembyggda K6/233 med moderkortet FIC-PA2007 (VIA Apollo VP2 chipset) och 256 MiB Corsair PC133 SDRAM får en rad tätt följda SIG11-fel cirka 20 minuter efter uppstart när kärnan kompileras, men aldrig under de första 20 minuterna. En omstart startar inte om klockan, men avstängning under natten gör det. Att byta ut allt RAM-minne hjälpte inte. Jag citerar den relevanta delen av en logg av en typisk kompilering nedan.

Beskriv symptomen i kronologisk ordning

De mest användbara ledtrådarna när man försöker ta reda på varför något gick fel finns ofta i vad som hände tidigare. Därför bör din fråga beskriva precis vad du gjorde och vad maskinen gjorde precis innan det gick snett. När det gäller kommandoradsprocedurer är det ofta väldigt användbart att ha en logg av inmatning och utmatning (till exempel via verktyget script) och citera ett par dussin relevanta rader.

Om programmet som det gick snett för har diagnostiska alternativ (såsom -v för verbose), försök att noggrant välja alternativ som kan tillföra användbar felsökningsinformation till problembeskrivningen.

Om din felbeskrivning visar sig bli lång (mer än cirka fyra stycken) kan det vara bra att kortfattat beskriva problemet längst upp och sedan följa upp med en kronologisk beskrivning. På så sätt vet hackare vad de bör leta efter när de läser beskrivningen.

Beskriv målet, inte steget

Om du försöker ta reda på hur man gör någonting (och inte rapporterar en bugg), börja med att beskriva målet. Först efter att det är gjort bör du fortsätta med att beskriva det steg där du kört fast.

Folk som ber om hjälp har ofta ett tekniskt mål på hög nivå i sikte och har kört fast i ett försök att göra något de tror är ett sätt att nå det målet. De ber om hjälp med det steget, men inser inte att det är fel sätt att nå målet. Att överkomma detta kan kräva mycket möda.

Dumt:
Hur får jag färgpaletten i programmet FooDraw att acceptera ett hexadecimalt RGB-värde?
Smart:
Jag försöker byta ut färgpaletten för en bild till en med värden som jag väljer själv. Såvitt jag kan se verkar det enda sättet att göra detta vara att redigera varje enskild färg i tabellen, men jag kan inte få FooDraws färgpalett att acceptera ett hexadecimalt RGB-värde.

Den andra versionen av frågan är smart. Den låter svaret föreslå ett bättre verktyg för uppgiften.

Be inte folk svara via privat e-post

Hackare anser att problemlösning bör vara en process med allmän insyn under vilken ett första försök att besvara en fråga kan och bör korrigeras om någon kunnigare noterar att svaret är ofullständigt eller felaktigt. De får då dessutom en del av sin belöning för att ha svarat genom att ses som kompetenta och kunniga bland sina jämlikar.

När du ber om ett privat svar hindrar du både processen och belöningen. Gör inte det. Det är den som svarar som har rätt att välja om han svarar privat—och om han gör det är det oftast för att han anser att frågan är för dåligt formulerad eller för uppenbar för att intressera andra.

Det finns ett begränsat undantag till den här regeln. Om du tror att frågan är sådan att du kan förvänta dig många svar av samma karaktär är de magiska orden du bör använda ”skicka svar via e-post till mig så sammanfattar jag svaren för gruppen”. Det är artigt att försöka bespara e-postlistan eller nyhetsgruppen en störtflod av i princip identiska meddelanden—men du måste hålla ditt löfte att summera svaren.

Formulera de frågor du har uttryckligen

Frågor som inte är klart avgränsade ses som obegränsat tidsödande frågor. De personer som antagligen kan ge de bästa svaren är också de mest upptagna (kanske mest för att de tar på sig mycket arbete). Den sortens människor är allergiska mot sådant som ohämmat slösar med tid, och därför är de oftast allergiska mot frågor som inte är klart avgränsade.

Du har större möjligheter att få ett användbart svar om du uttryckligen skriver vad du vill att den som svarar skall göra (ge tips, skicka kod, kontrollera din programfix, etc.). Detta ser till att fokusera deras ansträngningar och sätter en underförstådd övre gräns för hur mycket tid och energi den som svarar måste lägga ner. Det är bra.

För att förstå världen som experterna lever i, tänk dig expertis som en obegränsad resurs och tid att svara som en begränsad resurs. Ju mindre tid du underförstått begär, desto troligare är det att du får svar från någon riktigt kunnig och riktigt upptagen.

Därför är det viktigt att begränsa din fråga för att minimera den tid som en expert måste upplåta för att undersöka saken—men detta är oftast inte detsamma som att förenkla frågan. Således är frågan, ”kan du ge mig ett tips om var jag hittar en bra förklaring av X?” oftast smartare än ”kan du förklara X?”. Om du har ett stycke kod som inte fungerar är det oftare smartare att be någon förklara vad som är fel med det än att be dem fixa det.

Posta inte frågor om läxor

Hackare är bra på att identifiera läxor; de flesta av oss har själva löst dem. De frågorna är till för dig att lösa så att du lär dig från erfarenheten. Det är okej att be om tips, men inte hela lösningar.

Om du misstänker att du fått en läxfråga, men ändå inte kan lösa den, försök att fråga i ett forum för en användargrupp eller (som en sista utväg) i ett projekts e-postlista eller forum för ”användare”. Medan hackare kommer att se vad det är kan det hända att någon avancerad användare åtminstone ger dig ett tips.

Undvik meningslösa frågor

Motstå frestelsen att avsluta din förfrågan med meningslösa frågor som ”kan någon hjälpa mig?” eller ”finns det något svar?” För det första: om du skrivit en hyfsat kompetent beskrivning av problemet är sådana frågor i bästa fall överflödiga. För det andra: eftersom de är överflödiga tycker hackare att de är irriterande—och de kommer antagligen att ge logiskt felfria men avvisande svar som ”ja, någon kan hjälpa dig” eller ”nej, ingen kan hjälpa dig”.

Fråga i regel inte ja-eller-nej-frågor om du inte vill ha ja eller nej till svar.

Markera inte din fråga som ”Brådskande”, även om den är det för dig

Det är ditt problem, inte vårt. Att hävda att frågan är brådskande får antagligen inte önskad effekt, snarare den motsatta: de flesta hackare slänger bort sådana meddelanden som oförskämda och själviska försök att avkräva omedelbar och särskild uppmärksamhet.

Det finns ett fall som kanske kan ses som ett undantag. Om du använder programmet på någon framstående plats som hackare kan tycka är spännande kan det vara värt att nämna; i ett sådant fall kan det, om du är under tidspress och talar om detta på ett artigt vis, göra folk tillräckligt intresserade för att de skall ge ett snabbare svar.

Detta är dock mycket riskabelt, eftersom hackarnas måttstock för vad som är spännande antagligen skiljer sig från din. Att posta från den internationella rymdstationen skulle till exempel passa in, men att posta för någon moraliskt riktig välgörenhetsrörelse eller politisk rörelse gör det sannolikt inte. Faktum är att ”Brådskande: Hjälp mig rädda de gulliga sälungarna!” med största sannolikhet leder till att du blir skydd eller kritiserad, även av hackare som anser att gulliga sälungar är viktiga.

Om du finner detta underligt, läs igenom resten av den här texten flera gånger tills du förstår, innan du postar någonting alls.

Artighet skadar aldrig, och hjälper ibland

Var artig. Använd ”kan du vara snäll” och ”tack för uppmärksamheten”. Visa att du uppskattar att folk använder sin tid till att ge dig kostnadsfri hjälp.

Ärligt talat är detta inte lika viktigt som att skriva grammatiskt riktigt, tydligt, precist och beskrivande, att undvika användarspecifika format och så vidare (och det uppväger inte brott mot dessa regler); hackare i allmänhet läser hellre en något brysk men tekniskt välformulerad buggrapport än artig otydlighet. (Om detta är förvirrande, kom ihåg att vi värderar frågor baserat på hur mycket de lär oss.)

Men om du misslyckas med att formulera en tekniskt bra fråga ökar artighet dina chanser att få ett användbart svar.

(Vi måste notera att den enda allvarliga kritik vi fått från erfarna hackare till den här texten har att göra med vår tidigare rekommendation att använda ”tack på förhand”. Vissa hackare ser detta som en underförstådd avsikt att inte tacka någon i efterhand. Vår rekommendation är att antingen säga ”tack på förhand” och tacka dem som svarat i efterhand, eller att uttrycka artighet på något annat sätt, såsom genom att säga ”tack för uppmärksamheten”.)

Följ upp med en kort kommentar angående lösningen

Skicka en kommentar när problemet blivit löst till alla som hjälpt dig; låt dem veta hur det löste sig och tacka dem igen för hjälpen. Om problemet fick mycket uppmärksamhet i en e-postlista eller nyhetsgrupp är det passande att posta kommentaren där.

Helst bör svaret postas i tråden som började med den ursprungliga frågan, och bör ha ”FIXAT”, ”LÖST” eller motsvarande uppenbar notis i ärenderaden. På e-postlistor med mycket trafik kan en person som kan tänkas svara på frågor låta bli att slösa tid på att läsa en tråd som avslutas med ”Problem X - LÖST” (såvida han eller hon inte personligen finner Problem X intressant) för att istället använda sin tid till att lösa ett annat problem.

Din kommentar behöver inte vara lång och komplicerad; ett enkelt ”Hejsan—det var en trasig nätverkskabel! Tack alla. - Kalle” är bättre än inget alls. Faktum är att en kort och koncis summering är bättre än en lång utläggning, såvida inte lösningen är tekniskt djupgående. Tala om vilken handling som löste problemet, men du behöver inte beskriva hela problemlösningsprocessen.

För mer djupgående problem är det lämpligt att posta ett sammandrag av problemlösningsprocessen. Beskriv din slutgiltiga problembeskrivning. Beskriv vad lösningen var, och indikera därefter återvändsgränder som man kan undvika. Återvändsgränderna bör återges efter lösningen och allt annat sammanfattande stoff, och inte göra uppföljningen till en detektivroman. Nämn namnen på personerna som hjälpte dig; det hjälper dig att skaffa nya vänner.

Förutom att det är artigt och informativt att följa upp med en kommentar angående lösningen hjälper det andra att veta exakt vilken lösning som hjälpte dig när de letar i e-postlistans, nyhetsgruppens eller forumets arkiv.

Sist men inte minst bidrar det till att alla som hjälpt till kan känna tillfredsställelse med lösningen. Om du inte själv är hackare eller tekniskt intresserad, lita på oss när vi säger att den känslan är väldigt viktig för guruer och experter som du fått hjälp av. Processer som leder ut till olöst tomhet är frustrerande saker; hackare önskar inget hellre än att se dessa få en lösning. Den goda karma man får genom att uppfylla denna önskan är väldigt, väldigt nyttig nästa gång du behöver ställa en fråga.

Fundera på hur du kan förhindra att andra stöter på samma problem i framtiden. Tänk efter om en korrigering av dokumentationen eller listan över vanliga frågor och svar kan hjälpa. Om svaret är ja, skicka en sådan korrigering till den som sköter projektet.

Bland hackare är den här sortens beteende faktiskt viktigare än vanlig artighet. Det är så man skaffar rykte om sig att hålla sig väl med andra, och detta kan vara en värdefull tillgång.

Hur man tolkar svar

RTFM och STFW: Hur man vet när man gjort bort sig

Det finns en uråldrig och helig tradition: om du får svaret ”RTFM” tycker den som svarade att du borde ha läst den förbaskade manualen. Han har antagligen rätt. Läs den!

RTFM har en yngre släkting. Om du får svaret ”STFW” tycker den som skickat det att du borde sökt på den förbaskade webben. Han har antagligen rätt. Sök! (En snällare variant är när någon säger att ”Google är din vän!”)

I webbforum kan det hända att du blir tillsagt att söka igenom forumets arkiv. Faktum är att någon till och med kan vara så trevlig att de hänvisar till den tråd där problemet löstes. Men förlita dig inte på den sortens artighet; sök igenom arkivet innan du frågar.

Personen som säger åt dig att söka har ofta manualen eller webbsidan med informationen du behöver uppe, och kan se den i skrivande stund. De här svaren betyder att han anser att (a) informationen du behöver är lätt att hitta och (b) du kommer att lära dig mer om du letar reda på informationen än om du matas med den.

Bli inte förolämpad av detta; enligt hackarnormer visar han dig en grovhuggen sorts artighet helt enkelt genom att inte strunta i dig. Tacka honom istället för hans farmoderliga godhet.

Om du inte förstår…

Om du inte förstår svaret, kräv inte omedelbart en förklaring. Använd samma verktyg som du använde för att försöka besvara den ursprungliga frågan (manualer, vanliga frågor och svar, webben, kunniga vänner) för att förstå svaret. Om du fortfarande måste be om en förklaring, visa vad du lärt dig.

Tänk dig att jag till exempel skriver: ”Det låter som att du har en fastlåst zentry; du måste nollställa den.” Då finns det en dålig följdfråga: ”Vad är en zentry?” Och här är en bra följdfråga: ”Okej, jag läste manualen och zentryer nämns bara under växlarna -z och -p. Ingen av dem säger något om hur man nollställer zentryer. Är det någon av dessa, eller har jag missat något?”

Att hantera oartighet

Mycket av det som liknar oartighet i hackarsällskap är inte menat att uppröra. Det är i själva verket resultatet av det direkta sätt att kommunicera som är naturligt för folk som bryr sig mer om att lösa problem än att få andra att känna sig varma och go'a inombords.

När du uppfattar något som oartigt, försök att ta det lugnt. Om någon verkligen är utagerande är det mycket troligt att någon erfaren person på e-postlistan, nyhetsgruppen eller webbforumet säger åt personen i fråga. Om så inte sker och du tappar humöret, agerade den som orsakade det antagligen inom hackarsamhällets normer och du kommer att ses som den skyldige. Detta minskar dina möjligheter att få den information eller hjälp du behöver.

Det kan också hända att du då och då stöter på oartighet och attityd som är rätt oförtjänt. Som ett resultat av vad som beskrivs ovan är det accepterad form att vara ganska hård mot verkliga övertramp och dissikera sådant uppförande med skarp verbal skalpell. Men var väldigt, väldigt säker på din sak innan du ger dig på detta. Skillnaden mellan att korrigera ociviliserat beteende och att starta meningslösa ordkrig är tillräckligt hårfin för att hackare själva då och då ska klanta sig; om du är nybörjare eller nykomling är dina förutsättningar att undvika sådana misstag små. Om du är ute efter information och inte underhållning är det bättre att hålla fingrarna borta från tangentbordet än att ta en sådan risk.

(En del har dragit slutsatsen att hackare har en mild form av autism eller Aspergers syndrom och saknar en del av kopplingarna i hjärnan som hjälper ’vanliga’ personer umgås socialt. Detta må vara sant eller falskt. Om du inte själv är hackare kan det kanske hjälpa dig att stå ut med vårt excentriska beteende om du ser oss som hjärnskadade. Gör som du vill. Vi bryr oss inte; vi tycker om att vara vad vi nu är, och vi har i allmänhet en hälsosam skepticism inför kliniska beteckningar.)

I nästa avsnitt behandlar vi en annan fråga; den sortens ’oförskämdhet’ du får se om du inte uppför dig.

Om att inte reagera som en förlorare

Sannolikheten är att du kommer att göra bort dig några gånger i forum med hackarkultur—på sätt som beskrivs i den här texten, eller liknande. Och du kommer att få veta precis hur du gjorde bort dig, möjligen med originella avsidesrepliker. Offentligt.

När detta sker är det värsta du kan göra att gnälla om upplevelsen, påstå att du blivit verbalt misshandlad, kräva ursäkter, skrika, hålla andan, hota med stämningar, klaga hos folks chefer, lämna toalettsitsen uppfälld, etc. Gör istället följande:

Gå vidare. Sådant är livet. Det är normalt. Faktum är att det är nyttigt och lämpligt.

Ett samhälles normer underhåller inte sig själva. De underhålls av folk som aktivt tillämpar dem synbart och offentligt. Gnäll inte om att all kritik borde ha framförts via privat e-post. Det fungerar inte på det viset. Inte heller är det produktivt att insistera att du blivit förolämpad personligen när någon säger att ett av dina påståenden var felaktigt eller att hans åsikt skiljer sig från din. Sådana reaktioner hör till förlorare.

Det har hänt att hackarforum till följd av någon slags felriktad, överdriven artighet helt hindrat deltagare från att rätta andras inlägg med anvisningen ”säg inget om du inte är villig att hjälpa användaren”. Den resulterande utvandringen av insiktsfulla deltagare får sådana forum att förfalla till meningslöst prat och gör dem värdelösa som tekniska fora.

Överdrivet ”vänligt” (på det viset) eller användbart: välj själv.

Kom ihåg: när en hackare säger åt dig att du gjort bort dig, och att du inte bör göra om det (oavsett hur buttert han gör det) så gör han det för (1) ditt och (2) hans samhälles bästa. Det vore mycket lättare för honom att strunta i dig och helt enkelt filtrera bort dig. Om du inte klarar av att vara tacksam, ha åtminstone lite värdighet, gnäll inte, och vänta dig inte att bli behandlad som en porslinsdocka bara för att du är nykomling med överkänsligt själsliv och vanföreställningar om vad du har rätt till.

Somliga kommer att attackera dig personligen och grilla dig verbalt utan uppenbar anledning, etc., även om du inte gör bort dig (eller om de bara inbillar sig att du gjort det). Om man klagar i dessa fall gör man bort sig på riktigt.

De som startar dessa ordkrig är antingen töntar som inte vet någonting men tror att de själva är experter eller amatörpsykologer som undersöker om du gör bort dig. De andra läsarna kommer antingen att strunta i dem eller hitta egna sätt att ta hand om dem. Ordkrigarna ställer till det för sig själva, och det är inget du behöver bry dig om.

Låt dig inte heller dras in i ordkrig. Det är bäst att strunta i de flesta sådana—efter att du kontrollerat att de verkligen är rena ordkrig och inte ledtrådar till hur du gjort bort dig eller ett väl dolda svar på din fråga (detta händer också).

Frågor man inte bör ställa

Här är några klassiska dumma frågor och vad hackare tänker när de låter bli att svara på dem.

Fråga:
Var kan jag hitta program eller resurs X?
Svar:
På samma ställe jag skulle hitta det, dumsnut—på andra sidan en webbsökning. Jisses, vet inte alla hur man använder Google än?
Fråga:
Hur kan jag använda X för att göra Y?
Svar:
Om vad du vill göra är Y borde du ställa den frågan istället för att anta att du borde använda en metod som kanske inte är lämplig. Den som ställer den här sortens frågor är ofta inte bara förvirrad när det gäller X, utan även förvirrad när det gäller vad problemet Y de försöker lösa verkligen är och alltför fixerade vid detaljer. Oftast är det bäst att strunta i sådana personer tills de definierar sitt problem bättre.
Fråga:
Hur kan jag konfigurera prompten i mitt skal?
Svar:
Om du är tillräckligt smart att ställa den här frågan är du tillräckligt smart att RTFM och ta reda på det själv.
Fråga:
Kan jag konvertera ett Acmecorpdokument till en Texfil med min Bassomatiska filkonverterare?
Svar:
Pröva och se. Om du gjorde det skulle du (a) få reda på svaret och (b) sluta slösa bort min tid.
Fråga:
Mitt/min {program, konfiguration, SQL-sats} fungerar inte
Svar:
Det här är inte en fråga, och jag är inte intresserad av att tvinga ur dig en—jag har bättre saker för mig. När jag ser någonting sådant här är min reaktion oftast något av de följande alternativen:
  • hade du något att tillägga?
  • åhå, så tråkigt, jag hoppas att det löser sig.
  • och vad har det med mig att göra?
Fråga:
Jag har problem med min Windowsdator. Kan du hjälpa mig?
Svar:
Ja, släng ut Microsoftskräpet och installera ett operativsystem med öppen källkod som Linux eller BSD.

Notera: du kan ställa frågor som har att göra med Windowsdatorer om de handlar om ett fritt program som har en officiell Windowsversion eller kommunicerar med Windowsdatorer (t.ex. Samba). Bli bara inte förvånad om svaret blir att problemet är Windows och inte programmet, eftersom Windows i allmänhet är så trasigt att detta ofta är fallet.

Fråga:
Mitt program fungerar inte. Jag tror att systemresurs X är trasig.
Svar:
Medan det är möjligt att du är den första att stöta på en uppenbar brist i systemanrop och bibliotek som används flitigt av hundratals eller tusentals människor är det troligare att du lider av svår brist på insikt. Extraordinära påståenden kräver extraordinära belägg; när du gör ett sådant här påstående måste du stödja det med tydlig och utförlig dokumentation av situationen där problemet uppstår.
Fråga:
Jag har problem med att installera Linux eller X. Kan du hjälpa mig?
Svar:
Nej. Jag skulle behöva fysisk tillgång till din dator för att lösa den typen av problem. Be din lokala Linuxanvändarförening om personlig hjälp. (Du kan hitta en lista över användarföreningar här.)

Notera: frågor om hur man installerar Linux kan vara passande om du befinner dig i ett forum eller e-postlista om en specifik distribution och problemet är med den distributionen; eller på någon användarförenings forum. Om så är fallet, se till att beskriva de exakta detaljerna kring problemet. Men sök noggrant först med söktermerna ”Linux” och beteckningarna på all misstänkt hårdvara.

Fråga:
Hur kan jag knäcka root/stjäla kanaloperatörsrättigheter/läsa någons e-post?
Svar:
Du är ett avskum som vill veta sådant och en idiot som ber en hackare att hjälpa dig.

Bra och dåliga frågor

Jag tänker nu illustrera hur man ställer smarta frågor genom att visa några exempel där två frågor ställs angående samma problem, en på dumt vis och en på smart vis.

Dumt: Var kan jag hitta information om Foonly Flurbamatic?
Den här frågan bara ber om att besvaras med ”STFW”.
Smart: Jag använde Google för att försöka hitta ”Foonly Flurbamatic 2600” på nätet, men fick inga användbara träffar. Vet någon var jag kan hitta information om programmering för den?
Den här har redan STFWat, och låter som om han har ett problem på riktigt.
Dumt: Jag kan inte få koden från fooprojektet att kompilera. Varför är den trasig?
Han antar att någon annan gjort bort sig. Arrogant.
Smart: Koden från fooprojektet går inte att kompilera under Nulix, version 6.2. Jag har läst igenom listan med vanliga frågor och svar, men den nämner inte Nulixrelaterade problem. Här är en kopia på in- och utdata från mitt försök; beror det på någonting jag gör?
Han har specificerat miljön, han har läst listan med vanliga frågor, han visar felmeddelandet och han antar inte att hans problem är någon annans fel. Den här killen kan vara värd lite uppmärksamhet.
Dumt: Jag har problem med mitt moderkort. Kan någon hjälpa till?
J. Någon Hackares svar på detta är antagligen: ”Visst, behöver du hjälp med att rapa och få blöjan bytt också?” följt av en tryckning på deletetangenten.
Smart: Jag prövade X, Y och Z på moderkortet S2464. När det inte funkade provade jag A, B och C. Notera det intressanta fenomenet när jag prövade C. Det är tydligt att florbishen grommickar, men resultaten är inte vad man kan vänta sig. Vad är de vanligaste orsakerna till grommickande på Athlon MP-moderkort? Har någon idéer om vilka andra tester jag kan köra för att identifiera problemet?
Den här personen verkar däremot värdig ett svar. Han har visat problemlösande intelligens och inte bara passivt väntat på att ett svar skall dimpa ner från ovan.

Notera den subtila men viktiga skillnaden i den sista frågan mellan att kräva ”ge mig ett svar” och ”kan någon hjälpa mig att lista ut vilka diagnostiska prov jag kan använda för att få bättre insikt”.

Faktum är att den sista frågan är baserad på en verklig händelse i Augusti 2001 på linux-kernel mailing list (lkml). Det var jag (Eric) som ställde frågan den gången. Jag observerade mystiska hängningar med ett Tyan S2462-moderkort. E-postlistans deltagare bidrog med den information jag behövde för att lösa problemet.

Genom att ställa frågan så som jag gjorde gav jag folk något att bita i; jag gjorde det lätt och attraktivt för dem att ta del. Jag visade respekt för andras förmåga och inbjöd dem att konsultera med mig som jämlikar. Jag respekterade också att deras tid är värdefull genom att tala om de återvändsgränder jag redan undersökt.

Efteråt, när jag tackade alla och påpekade hur väl processen fungerat, noterade en deltagare att att han ansåg att anledningen att det fungerade inte var att jag är ett känt namn på listan, utan att jag frågade på rätt sätt.

På många sätt befinner sig hackare i en väldigt hänsynslös meritokrati; han hade säkert rätt, och om jag hade betett mig som en snyltare hade jag blivit utskälld eller ignorerad oavsett vem jag var. Hans förslag att skriva ner hela incidenten som en instruktion för andra ledde till att den här texten skrevs.

Om du inte lyckas få svar

Om du inte lyckas få svar, ta det inte personligt att vi inte känner att vi kan hjälpa till. De tillfrågade medlemmarna känner ibland helt enkelt inte till svaret. Att inte få svar är inte det samma som att ignoreras, även om det förvisso är svårt att se skillnaden som åskådare.

I allmänhet är det en dålig idé att bara ställa frågan igen. Detta ses som meningslös oartighet.

Det finns andra källor att få hjälp ifrån, källor som ofta är bättre anpassade till nybörjares behov.

Många virtuella och lokala användargrupper är entusiastiskt inställda till programvaran, även om de aldrig programmerat själva. Dessa grupper bildas ofta så att folk kan hjälpa varandra och nya användare.

Det finns också många kommersiella företag som du kan skriva kontrakt med för att få hjälp, både stora och små (Red Hat och Linuxcare är två av de mest kända; det finns många andra). Känn inte avsmak inför idén att behöva betala för att få lite hjälp. Om topplocket i motorn på din bil går sönder tar du den antagligen till en verkstad för reparation. Även om programvaran inte kostade någonting kan du inte vänta dig att användarstöd alltid skall vara gratis.

För populär programvara som Linux finns det åtminstone 10 000 användare per utvecklare. Det är helt enkelt omöjligt för en person att hjälpa över 10 000 användare. Kom ihåg att även om du måste betala för användarstöd betalar du fortfarande mindre än om du dessutom hade betalat för programvaran (och användarstöd för slutna program är ofta dyrare och mindre kompetent än användarstöd för fria program).

Hur man besvarar frågor på hjälpsamt sätt

Var mild. Problemrelaterad stress kan få folk att verka oartiga eller dumma även om de inte är det.

För en första överträdelse, svara privat. Det finns ingen anledning att offentligt förödmjuka någon som kan ha begått ett faktiskt misstag. En riktig nybörjare kanske inte vet hur man söker i arkiven eller var de vanliga frågorna sparas eller postas.

Om du är osäker, säg det! Ett felaktigt svar som låter auktoritärt är värre än inget alls. Led inte någon i fel riktning bara för att det är kul att låta som en expert. Var ödmjuk och ärlig; föregå med gott exempel både för frågeställaren och dina jämlikar.

Om du inte kan hjälpa till, hindra inte. Skämta inte om proceduren på ett sådant sätt som skulle kunna förstöra för användaren—stackaren kan tolka det som instruktioner.

Ställ undersökande frågor för att få reda på mer. Om du är bra på detta kommer frågeställaren att lära sig någon—och kanske du med. Försök att förvandla en dålig fråga till en bra fråga; kom ihåg att vi alla varit nybörjare en gång i tiden.

Medan det ibland kan vara berättigat att bara muttra RTFM när man svarar någon som helt enkelt är en latmask är det bättre att tipsa om var man hittar dokumentationen (även om det bara är ett förslag till sökord).

Om du svarar på en fråga, se till att svaret är av värde. Föreslå inte bara något hafsigt sätt att kringgå problemet när någon använder fel verktyg eller metod. Föreslå bra verktyg. Sätt frågan i nytt perspektiv.

Hjälp ditt samhälle att lära sig av frågan. När du undersöker en bra fråga, ställ också frågan hur dokumentation eller listan över vanliga frågor och svar skulle kunna ändras så att ingen behöver ställa frågan igen. Skicka sedan en uppdatering till den som sköter dokumentationen.

Om du behövt söka information för att besvara frågan, demonstrera dina färdigheter istället för att skriva som om du trollat fram svaret med knäna. Att svara på en bra fråga är som att ge en hungrig person ett mål mat, men att lära dem färdigheter i fel- och informationssökning är att lära dem hur man odlar sin egen mat under en livstid.

Annan läsning

Om du behöver grundläggande instruktioner angående hur persondatorer, Unix och Internet fungerar, se The Unix and Internet Fundamentals HOWTO.

När du publicerar programvara eller skriver programfixar för programvara, försök att följa riktlinjerna i The Software Release Practice HOWTO.

Tack

Evelyn Mitchell bidrog med några exempel på dumma frågor och gav inspiration till avdelningen ”Hur man besvarar frågor på hjälpsamt sätt”. Mikhail Ramendik bidrog med särskilt användbara förslag till förbättringar.