Hur ställa frågor på ett smart sätt

Original: http://www.catb.org/~esr/faqs/smart-questions.html

Eric Steven Raymond

Thyrsus Enterprises

<[email protected]>

Rick Moen

<[email protected]>

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

Revisionshistorik
Revision 3.10 21 maj 2014 ESR
Nytt avsnitt om Stack Overflow.
Revision 3.9 23 Apr 2013 ESR
URL fixar.
Revision 3.8 19 Jun 2012 ESR
URL fix.
Revision 3.7 6 December 2010 ESR
Bra tips för ESL-högtalare.
Revision 3.7 2 november 2010 ESR
Flera översättningar har försvunnit.
Revision 3.6 19 Mar 2008 ESR
Mindre uppdatering och nya länkar.
Revision 3.5 2 Jan 2008 ESR
Typo fix och några översättningslänkar.
Revision 3.4 24 Mar 2007 ESR
Nytt avsnitt, „När man frågar koden“.
Omar 3,3 29 Sep 2006 esr
Vikta i ett bra förslag från Kai Niggemann.
Revision 3.2 10 Jan 2006 ESR
Vikta i redigeringar från Rick Moen.
Revision 3.1 28 oktober 2004 ESR
Dokument „Google är din vän!“
Revision 3.0 2 Feb 2004 ESR
Större tillägg av saker om rätt etikett på webbforum.
INNEHÅLLSFÖRTECKNING

Översättningar
Varning
Introduktion
Innan du frågar
När du frågar
Välj forum noga
Stack Overflow
Webb och IRC forum
Som ett andra steg, använda projektsändlistor
Använd meningsfulla, specifika ämnes rubriker
Gör det enkelt att svara
Skriv i klart, grammatiska, rätt-stavat språk
Skicka frågor i lättillgängliga, standardformat
Var precis och informativ om ditt problem
Volymen är inte precision
Ha inte bråttom att hävda att du har hittat en bugg
KRYPANDE är inte en ersättning för att göra dina läxor
Beskriv problem symptom, inte era gissningar
Beskriv ditt problem symptom i kronologisk ordning
Beskriv målet, inte steget
Fråga inte folk att svara genom privata e-post
Var tydlig om din fråga
När man frågar kod
Lägg inte upp läxor frågor
Rensa onödiga förfrågningar
Inte flagga din fråga som „Brådskande“, även om det är för dig
Artighet skadar aldrig, och ibland hjälper
Följ upp med en kort notering på lösningen
Hur man ska tolka svar
RTFM och STFW: Hur berätta Du har Allvarligt skruvas upp
Om du inte förstår …
Hantering av råhet
På Inte Reagera som en förlorare
Frågor att inte fråga
Bra och dåliga frågor
Om du inte kan få ett svar
Hur att svara på frågor i ett hjälpsamt sätt
Närliggande resurser
Tack
Översättningar

Översättningar: Bahasa indonesiska Vitryska Bulgariska Brazilo-Portugisiska Tjeckiska Holländska Franska Georgiska Tyska Grekiska Japanska Polska Portugisiska Rumänska Ryska Serbiska Spanska Thai Om du vill kopiera, spegel, översätta, eller utdrag detta dokument, vänligen se min kopiering policy.

Varning

Många projekt webbplatser länkar till detta dokument i sina sektioner om hur du får hjälp. Det är bra, det är användningen som vi tänkt – men om du är en webmaster skapa en sådan länk för din projektsida, vänligen visa framträdande nära kopplingen märker att vi inte är en helpdesk för ditt projekt!

Vi har lärt oss den hårda vägen att utan ett sådant meddelande, vi kommer flera gånger bli utsatta av idioter som tror att ha publicerat detta dokument gör det vårt jobb att lösa alla världens tekniska problem.

Om du läser det här dokumentet för att du behöver hjälp, och du går bort med intrycket att du kan få det direkt från författarna till detta dokument, är du en av de idioter som vi talar om. Fråga inte oss frågor. Vi ska bara ignorera dig. Vi är här för att visa dig hur du får hjälp från människor som faktiskt vet om mjukvara eller hårdvara du arbetar med, men 99,9% av den tid som inte kommer att vara oss. Om du inte vet med säkerhet att en av författarna är expert på vad du arbetar med, lämna oss ifred och alla kommer att bli lyckligare.

Introduktion

I en värld av hackare, beror vilken typ av svar du får på dina tekniska frågor så mycket på det sätt du ställa de frågor som på svårigheten att utveckla svaret. Denna guide lär dig hur du ställa frågor på ett sätt mer sannolikt att få dig ett tillfredsställande svar.

Nu när användningen av öppen källkod har blivit vanligare, kan du ofta få så bra svar från andra, mer erfarna användare som från hackare. Detta är en bra sak; användare tenderar att vara bara lite mer toleranta mot den typ av misslyckanden nybörjare har ofta. Ändå behandlar erfarna användare som hackare i hur vi rekommenderar här generellt kommer att vara det mest effektiva sättet att få användbara svar av dem också.

Det första man måste förstå är att hackare faktiskt gillar hårda problem och bra, tankeväckande frågor om dem. Om vi ​​inte gjorde det, skulle vi inte vara här. Om du ger oss en intressant fråga att tugga på vi ska vara tacksamma för er; bra frågor är en stimulans och en gåva. Bra frågor hjälper oss att utveckla vår förståelse, och ofta avslöjar problem som vi kanske inte har märkt eller tänkt på något annat. Bland hackare, „Bra fråga!“ Är en stark och uppriktig komplimang.

Trots detta, hackare har ett rykte om att möta enkla frågor med vad som ser ut som fientlighet eller arrogans. Det ser ibland ut som vi är reflexmässigt otrevlig mot nybörjare och okunniga. Men detta är inte riktigt sant.

Vad vi är, unapologetically är fientligt inställd till människor som verkar vara ovilliga att tänka eller att göra sin egen hemläxa innan du ställer frågor. Folk gillar som är tids sänkor – de tar utan att ge tillbaka, och de slösa tid vi kunde ha spenderat på en annan fråga mer intressant och en annan person mer värdig ett svar. Vi kallar personer gillar detta „förlorare“ (och av historiska skäl som vi ibland stava det „lusers“).

Vi inser att det finns många människor som bara vill använda programvaran vi skriver, och som inte har något intresse av att lära tekniska detaljer. För de flesta människor, är en dator bara ett verktyg, ett medel att nå målet; De har viktigare saker att göra och lever för att leva. Vi erkänner att, och förvänta dig inte alla att ta ett intresse för tekniska frågor som fascinerar oss. Ändå är vår stil att besvara frågor ögonen öppna för människor som tar ett sådant intresse och är villiga att delta aktivt i problemlösning. Det kommer inte att förändras. Inte heller bör det; om det gjorde det skulle vi bli mindre effektiv på de saker vi gör bäst.

Vi är (i stort sett) volontärer. Vi tar time out från hektiskt att svara på frågor, och ibland är vi överväldigade med dem. Så vi filtrerar hänsynslöst. Framför allt vi slänger frågor från människor som verkar vara förlorare i syfte att tillbringa vår fråga-svars tid mer effektivt, på vinnarna.

Om du hittar denna attityd motbjudande, nedlåtande eller arrogant, kontrollera dina antaganden. Vi ber dig inte att knäböja för oss – i själva verket skulle de flesta av oss älskar inget mer än att ta itu med dig som en jämlike och välkomnar er in i vår kultur, om du lägger i den insats som krävs för att göra det möjligt. Men det är helt enkelt inte effektivt för oss att försöka hjälpa människor som inte är villiga att hjälpa sig själva. Det är OK att vara okunniga; det är inte OK att spela dum.

Så, även om det inte är nödvändigt att redan vara tekniskt kompetent att få uppmärksamhet från oss, är det nödvändigt att visa vilken typ av attityd som leder till kompetens – varning, omtänksam, uppmärksam, villig att vara en aktiv partner i utvecklingen av en lösning. Om du inte kan leva med denna typ av diskriminering, föreslår vi att du betalar någon för ett kommersiellt supportavtal istället för att fråga hackare att personligen donera hjälp för dig.

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 verka som en, heller. Det bästa sättet att få en snabb och lyhörd svaret är att fråga det som en person med smarts, självförtroende, och ledtrådar som bara råkar behöva hjälp på en särskilt problem.

(Förbättringar denna guide är välkomna. Du kan maila förslag till [email protected] eller [email protected] Notera dock att detta dokument inte är avsedd att vara en allmän guide till netikett, och vi kommer i allmänhet förkastar förslag som inte specifikt relaterade till framkalla användbara svar på ett tekniskt forum.)

Innan du frågar

Innan du ber en teknisk fråga via e-post, eller i en diskussionsgrupp, eller på en webbplats chatt styrelse, gör följande:

Försök att hitta ett svar genom att söka arkiv forumet eller e-postlistan du planerar att skicka till.

Försök att hitta ett svar genom att söka på webben.

Försök att hitta ett svar genom att läsa manualen.

Försök att hitta ett svar genom att läsa en FAQ.

Försök att hitta ett svar genom inspektion eller experiment.

Försök att hitta ett svar genom att fråga en kunnig vän.

Om du är en programmerare, försöka hitta ett svar genom att läsa källkoden.

När du ställa din fråga, visar det faktum att du har gjort dessa saker först; Detta kommer att bidra till att skapa att man inte är en lat svamp och slösa människors tid. Ännu bättre, visa vad du har lärt från att göra dessa saker. Vi gillar att svara på frågor för människor som har visat att de kan lära sig av svaren.

Använd taktik som gör en Google-sökning på texten oavsett felmeddelande du får (söker Google grupper samt webbsidor). Detta kan mycket väl ta dig direkt till fixa dokumentation eller en e-postlista tråd besvara din fråga. Även om det inte gör det, säger „Jag googlade på följande mening men fick inte något som såg lovande“ är en bra sak att göra i e-post eller nyhets inlägg som begär hjälp, om så bara för att det registrerar vad söker vann “ t hjälp. Det kommer också att bidra till att rikta andra personer med liknande problem till din tråd genom att länka söktermerna till vad som kommer förhoppningsvis att vara ditt problem och lösning tråd.

TA DEN TID DU BEHÖVER. Räkna inte med att kunna lösa ett komplicerat problem med några sekunders googla. Läs och förstå vanliga frågor, luta dig tillbaka, slappna av och ge problemet en tanke innan närmar experter. Lita på oss, kommer de att kunna berätta från dina frågor hur mycket läsning och tro att du gjorde, och kommer att vara mer villiga att hjälpa om du kommer förberedda. Inte omedelbart eld hela din arsenal av frågor bara för att din första sökning vände upp inga svar (eller för många).

Förbered din fråga. Tänk igenom det. Hasty-klingande frågor får förhastade svar, eller inga alls. Ju mer du gör för att visa att ha lagt tanke och möda på att lösa ditt problem innan du söker hjälp, desto mer sannolikt är det att du faktiskt få hjälp.

Akta dig för att ställa fel fråga. Om du frågar en som bygger på felaktiga antaganden, är J. Random Hacker ganska troligt att svara med onödigt bokstavlig svar medan tänkande „Dum fråga …“, och hoppas att upplevelsen av att få vad du bad om snarare än vad du behövde kommer att lära dig en läxa.

Aldrig antar att du har rätt till ett svar. Du är inte; du inte, trots allt, betalar för tjänsten. Du kommer att tjäna ett svar, om du tjänar det, genom att ställa en betydande, intressant och tankeväckande fråga – en som implicit bidrar till upplevelsen av samhället snarare än att bara passivt krävande kunskap från andra.

Å andra sidan, vilket gör det klart att du kan och vill hjälpa till i arbetet med att utveckla lösningen är en mycket bra start. „Skulle någon ge en pekare?“, „Vad är mitt exempel saknas?“, Och „Vilken plats skulle jag ha kontrollerat?“ Är mer benägna att få besvarade än „Vänligen posta det exakta förfarandet jag ska använda.“ Eftersom du är gör det klart att du verkligen villig att slutföra processen om någon bara kan peka dig i rätt riktning.

När du frågar

Välj forum noga

Var lyhörd välja var du ställa din fråga. Du kommer sannolikt att ignoreras, eller skrivas av som en förlorare, om du:

skicka din fråga till ett forum där det är off topic

skicka en mycket elementär fråga till ett forum där avancerade tekniska frågor förväntas, eller vice versa

kors post till alltför många olika diskussionsgrupper

skicka en personlig e-post till någon som varken är en bekant till er heller personligen ansvarig för att lösa ditt problem

Hackare blåsa av frågor som olämpligt är riktade för att försöka skydda sina kommunikationskanaler från att drunkna i irrelevans. Du vill inte att detta ska hända dig.

Det första steget är därför att hitta rätt forum. Igen, Google och andra webb söka metoder är din vän. Använd dem för att hitta projekt webbsida närmast förknippas med hårdvara eller mjukvara som ger dig problem. Vanligtvis kommer det att ha kopplingar till en FAQ (Frequently Asked Questions) listan, och att projicera e-postlistor och deras arkiv. Dessa e-postlistor är de sista ställen att gå för att få hjälp, om dina egna ansträngningar (inklusive läsa dessa frågor du hittade) inte finna dig en lösning. Projektet sidan kan också beskriva en bugg-rapportering förfarande, eller har en länk till en; i så fall följa den.

Skytte utanför ett e-postmeddelande till en person eller forum som du inte är bekant med är riskabelt i bästa fall. Till exempel, inte anta att författaren till en informativ webbsida vill vara din lediga konsult. Gör inte optimistiska gissningar om huruvida din fråga kommer att vara välkomna – om du är osäker, skicka det på annat håll, eller avstå från att skicka det alls.

När du väljer en webbforum, nyhetsgrupper eller e-postlista, litar inte namnet i sig för långt; leta efter en FAQ eller charter att verifiera din fråga är on-topic. Läs några av rygg trafiken innan du postar så att du får en känsla för hur saker och ting görs där. I själva verket är det en mycket bra idé att göra en nyckelordssökning efter ord som rör ditt problem på diskussionsgruppen eller sändlistearkiv innan du postar. Det kan finna dig ett svar, och om inte det hjälper dig att formulera en bättre fråga.

Inte hagelgevär sprängning alla tillgängliga hjälp kanaler på en gång, det är som att skrika och irriterar folk. Steg genom dem mjukt.

Vet vad ditt ämne är! En av de klassiska misstagen är att ställa frågor om Unix eller Windows programmeringsgränssnitt i ett forum som ägnas åt ett språk eller bibliotek eller verktygs bärbar över båda. Om du inte förstår varför detta är en blunder, skulle du vara bäst av att inte ställa några frågor alls tills du får det.

I allmänhet, frågor till en väl utvald offentligt forum är mer benägna att få användbara svar än motsvarande frågor till en privat. Det finns flera skäl till detta. En är helt enkelt storleken på poolen av potentiella respondenter. Ett annat är storleken på publiken; hackare skulle hellre svara på frågor som utbildar många människor än frågor som betjänar endast ett fåtal.

Förståeligt nog är skickliga hackare och författare populära program redan får mer än sin beskärda del av mis-riktade meddelanden. Genom att lägga till översvämning, kunde man i extrema fall till och med vara droppen som får bägaren att rinna över – ganska många gånger, har bidragit till populära projekt dras tillbaka sitt stöd eftersom ytterligare skador i form av värdelösa e-posttrafik till sina personliga konton blev outhärdlig.

Stapla Bräddning

Sök, så fråga på Stack Exchange

Under de senaste åren har det Stack Exchange gemenskap sajter dykt upp som en viktig resurs för att besvara tekniska och andra frågor och är till och med att föredra forum för många open-source projekt.

Börja med en Google-sökning innan du tittar på Stack Exchange; Google indexerar det i realtid. Det finns en mycket god chans att någon har redan bett en liknande fråga, och Stack Exchange platserna är ofta högt upp i sökresultaten. Om du inte hittar något via Google, sök på nytt på den specifika platsen mest relevanta för din fråga (se nedan). Söka med taggar kan hjälpa begränsa resultaten.

Om du fortfarande inte hittar något, skicka din fråga på en plats där det är mest på ämnet. Använd formateringsverktyg, särskilt för kod, och lägga till taggar som är relaterade till ämnet på din fråga (särskilt namnet på programmeringsspråk, operativsystem, eller bibliotek du har problem med). Om en commenter frågar efter mer information, redigera din huvudsakliga inlägg att inkludera det. Om något svar är till hjälp, klicka på uppåtpilen för att upvote det; Om ett svar ger en lösning på ditt problem, klicka på kryss enligt pilarna röstnings att acceptera det som är korrekt.

Stack Exchange har vuxit till över 100 sajter, men här är de troligaste kandidaterna:

Super Användaren är för frågor om allmänt ändamål datoranvändning. Om din fråga handlar inte om kod eller program som du talar med endast via en nätverksanslutning, går det förmodligen här.

Stack Overflow är för frågor om programmering.

Server Fel är för frågor om server och nätverksadministration.

Flera projekt har sina egna specifika platser, inklusive Android, Ubuntu, TeX / LaTeX och Sharepoint. Kontrollera Stack Exchange platsen för en up-to-date lista.

Webb och IRC forum

Din lokala användargrupp, eller din Linux-distribution, kan annonsera en webbforum eller IRC-kanal där nybörjare kan få hjälp. (I icke-engelskspråkiga länder newbie forum är fortfarande mer sannolikt att vara e-postlistor.) Dessa är bra första platser att fråga, speciellt om du tror att du kan ha löst ut under en relativt enkel eller vanligt problem. En annonserade IRC-kanal är en öppen inbjudan att ställa frågor där och ofta få svar i realtid.

I själva verket, om du fick det program som ger dig problem från en Linux-distribution (vilket är vanligt idag), kan det vara bättre att fråga i distro forum / lista innan du försöker programmets projekt forum / listan. Projektets hackare kan bara säga, „använda vår build“.

Innan du postar något webbforum, kolla om det har en sökfunktion. Om den gör det, prova ett par sökordssökningar för något liknande ditt problem; det bara kan hjälpa. Om du gjorde en allmän webbsökning innan (som du bör ha), söka på forumet ändå; din webbomfattande sökmotor kanske inte har allt detta forum indexe nyligen.

Det finns en ökande tendens till projekt för att göra användarstöd över en webbforum eller IRC-kanal, med e-post reserverad mer för utvecklingstrafik. Så leta efter dessa kanaler först när de söker projektspecifik hjälp.

Som ett andra steg, använda projektsändlistor

När ett projekt har en utvecklings postlista, skriva till sändlistan, inte enskilda utvecklare, även om du tror att du vet vem bäst kan besvara din fråga. Kontrollera dokumentationen av projektet och dess hemsida för adressen av ett projekt postlista, och använda den. Det finns flera goda skäl till denna policy:

Varje fråga tillräckligt bra för att bli tillfrågad om en utvecklare kommer också att vara av värde för hela gruppen. Omvänt om du misstänker att din fråga är för dum för en e-postlista, det är inte en ursäkt för att trakassera enskilda utvecklare.

Ställa frågor på listan distribuerar belastningen bland utvecklare. Den individuella utvecklare (speciellt om han är projektledare) kan vara för upptagen för att svara på dina frågor.

De flesta e-postlistor arkiveras och arkiv indexeras av sökmotorer. Om du ställa din fråga på listan och det besvaras, skulle en framtida querent hitta din fråga och svaret på webben istället för att fråga det igen.

Om vissa frågor ses ställas ofta, kan utvecklare använda den informationen för att förbättra dokumentationen eller mjukvaran sig vara mindre förvirrande. Men om dessa frågor ställs i privata, har ingen fullständig bild av vad frågor ställs oftast.

Om ett projekt har både en „användare“ och en „utvecklare“ (eller „hacker“) e-postlista eller webbforum, och du inte hacka på koden, fråga i „användare“ listan / forum. Förutsätt inte att du kommer att vara välkomna på utvecklarens listan, där de är benägna att uppleva din fråga som brus störa deras utvecklare trafik.

Men om du är säker på din fråga är icke-trivialt, och du får inget svar på „användare“ listan / forum i flera dagar, prova „utvecklare“ en. Du skulle vara klokt att lurar där för några daysor åtminstone granska de sista dagarna av arkiverade meddelanden, för att lära sig de lokala folkways innan du postar (faktiskt detta är goda råd om alla privata eller halvprivata lista).

Om du inte kan hitta ett projekts sändlista adress, men bara se adressen till ansvariga för projektet, gå vidare och skriva till den ansvarige. Men även i det fallet, inte anta att sändlistan inte existerar. Nämn i din e-post som du försökte och kunde inte hitta en lämplig sändlista. Också nämna att du inte har några invändningar mot att ha ditt budskap vidarebefordras till andra människor. (Många tror att den privata e-post bör förbli privat, även om det inte finns något hemligt i den. Genom att låta ditt budskap till vidarebefordras du ger din korrespondent ett val om hur du hanterar din e-post.)

Använd meningsfulla, specifika ämnes rubriker

På e-postlistor, diskussionsgrupper eller webbforum, är föremål header din gyllene tillfälle att locka kvalificerade experter uppmärksamhet på cirka 50 tecken eller färre. Slösa inte det på babbel som „Snälla hjälp mig“ (för att inte tala „PLEASE HELP ME !!!!“, meddelanden med ämnen som som får kastas med reflex). Försök inte att imponera på oss med djupet av din ångest; använda utrymmet för en super-kortfattad problembeskrivning istället.

En bra avtal för ämnes rubriker, som används av många tech stödorganisationer, är „objekt – avvikelse“. „Objektet“ delen anger vad sak eller grupp av saker är att ha ett problem, och „avvikelse“ delen beskriver avvikelsen från förväntat beteende.

dum:
HJÄLP! Video fungerar inte korrekt på min laptop!

smarta:
X.org 6.8.1 deformerade muspekaren, Fooware MV1005 vid. chipset

smartare:
X.org 6.8.1 muspekaren på Fooware MV1005 vid. chipset – är deformerade

Processen med att skriva ett „objekt-avvikelse“ beskrivning hjälper dig att organisera dina tankar om problemet mer i detalj. Vad påverkas? Bara muspekaren eller annan grafik också? Är detta specifika för X.org versionen av X? Till version 6.8.1? Är detta specifika för Fooware video chipset? Att modellera MV1005? En hackare som ser resultatet kan omedelbart förstå vad det är som du har problem med och problem du har, med ett ögonkast.

Mer allmänt, tänk att titta på index för ett arkiv av frågor, med bara ämnesrader visar. Gör din ämnesrad spegla din fråga tillräckligt väl att nästa person söker arkivet med en fråga som liknar din kommer att kunna följa tråden till ett svar i stället för att publicera frågan på nytt.

Om du ställer en fråga i ett svar, se till att ändra ämnesraden för att indikera att du frågar en fråga. En ämnesrad som ser ut som „Re: test“ eller „Re: ny bugg“ är mindre sannolikt att locka användbara mängder av uppmärksamhet. Också pare citat av tidigare meddelanden till det minimum som cluing i nya läsare.

Inte bara slog svar på en meddelandelista för att starta en helt ny tråd. Detta begränsar dina åhörare. Vissa postläsare, som mutt, tillåter användaren att sortera efter tråd och sedan gömma meddelanden i en tråd genom att vika tråden. Folk som gör det kommer aldrig att se ditt meddelande.

Ändra ämnet inte är tillräcklig. Mutt, och förmodligen andra postläsare, ser på annan information i e-post s rubriker att tilldela den till en tråd, inte ämnesraden. Istället startar en helt ny e-post.

På webbforum reglerna för god praxis är något annorlunda, eftersom meddelandena är oftast mycket mer hårt bundna till specifika diskussionstrådar och ofta osynligt utanför dessa trådar. Ändra motivet när ställer en fråga som svar är inte nödvändigt. Inte alla forum tillåter även separata ämnesrader på svaren, och nästan ingen läser dem när de gör. Men att ställa en fråga i ett svar är en tvivelaktig praxis i sig, eftersom den endast kommer att ses av dem som tittar här tråden. Så, om du inte är säker på att du vill bara be folket för närvarande aktiva i tråden, starta en ny.

Gör det enkelt att svara

Finishing din fråga med „Skicka ditt svar till …“ gör det ganska osannolikt att du kommer att få ett svar. Om du inte orkar att ta även de få sekunder som behövs för att upprätta en korrekt Svara till header i post agent, kan vi inte brytt sig om att ta ännu ett par sekunder att tänka på ditt problem. Om ditt e-postprogram inte tillåter detta, få en bättre postprogram. Om ditt operativsystem inte stöder någon e-postprogram som tillåter detta, få en bättre operativsystem.

I webbforum, be om ett svar via e-post är direkt oförskämd, såvida du inte anser att informationen kan vara känslig (och någon kommer, av någon okänd anledning, låt dig men inte hela forumet vet det). Om du vill ha en e-postkopia när någon svarar i tråden, begära att webbforum skicka det; denna funktion stöds nästan överallt i alternativ som „titta här tråden“, „skicka e-post på svar“, etc.

Skriv i klart, grammatiska, rätt-stavat språk

Vi har hittat av erfarenhet att människor som är slarvig och slarviga skribenter är oftast också slarvig och slarvig på att tänka och kodning (ofta nog att satsa på, i alla fall). Svara på frågor för vårdslös och slarviga tänkare inte givande; Vi skulle snarare ägna vår tid på annat håll.

Så uttrycker din fråga tydligt och väl är viktigt. Om du inte orkar göra det, kan vi inte brytt sig om att uppmärksamma. Spendera den extra ansträngningen att polera ditt språk. Det behöver inte vara stel eller formella – i själva verket, hacker kulturen värderar informell, FULL AV SLANG och humoristisk språk som används med precision. Men det måste vara exakt; Det måste finnas någon indikation på att du tänker och uppmärksamma.

Stava, punktera, och kapitalisera på rätt sätt. Blanda inte ihop „sin“ med „det är“, „lös“ med „förlora“, eller „diskret“ med „diskret“. Inte skriva i VERSALER; detta läses som skrika och anses oförskämd. (All-smalls är endast något mindre irriterande, eftersom det är svårt att läsa. Alan Cox kan komma undan med det, men det går inte.)

Mer allmänt, om du skriver som en halvkunnig boob du kommer mycket sannolikt att ignoreras. Så använd inte genvägar instant-messaging. Stavning „du“ som „u“ gör att du ser ut som en halvkunnig boob att spara två hela knapptryckningar. Värre: skriver som en l33t Scriptkiddie hax0r är den absoluta dödsstöten och garanterar att du kommer att få något annat än stenig tystnad (eller i bästa fall en rågad portion förakt och sarkasm) i gengäld.

Om du ställer frågor i ett forum som inte använder ditt modersmål, kommer du att få en begränsad mängd slack för stavning och grammatiska fel – men utan extra slack alls för lättja (och ja, vi kan oftast upptäcka denna skillnad). Dessutom, om du inte vet vad din ondentens språk, skriver på engelska. Upptagen hackare tenderar att helt enkelt spola frågor på språk de inte förstår, och engelska är arbetsspråket av Internet. Genom att skriva på engelska minimerar du dina chanser att din fråga kommer att kastas oläst.

Om du skriver på engelska, men det är ett andra språk för dig, är det god ton att varna potentiella respondenter till potentiella svårigheter och språkalternativ för att komma runt dem. Exempel:

Engelska är inte mitt modersmål; ursäkta skrivfel.

Om du talar $ SPRÅK, vänligen maila / PM mig; Jag kan behöva hjälp att översätta min fråga.

Jag är bekant med de tekniska termer, men vissa slanguttryck och idiom är svårt för mig.

Jag har postat min fråga i $ SPRÅK och engelska. Jag ska vara glad att översätta svaren, om du bara använder det ena eller det andra.

Skicka frågor i lättillgängliga, standardformat

Om du gör din fråga på konstgjord svår att läsa, är det mer sannolikt att föras över till förmån för en som inte är det. Så:

Skicka klartext post, inte HTML. (Det är inte svårt att stänga av HTML.)

MIME-bilagor är oftast OK, men bara om de är verkliga innehåll (t.ex. en bifogad källfilen eller plåster), och inte bara standardtext som genereras av e-postklienten (t.ex. en annan kopia av ditt meddelande).

Skicka inte e-post där hela stycken är ensamstående flerfaldigt inslagna linjer. (Det gör det för svårt att svara på bara en del av meddelandet.) Antag att dina respondenter kommer att läsa e-post på 80 tecken gemensamma text visas och ange ditt radbyte därefter, till något mindre än 80.

Dock inte linda data (t.ex. loggfil dumpar eller sessions avskrifter) vid varje kolumnbredd fast. Data bör ingå som-är, så de svarande kan ha förtroende för att de ser vad du såg.

Skicka inte MIME quoted-printable-kodning till en engelskspråkig forum. Denna kodning kan vara nödvändigt när du postar på ett språk ASCII täcker inte, men många e-post agenter stöder inte det. När de bryter, alla dessa = 20 glyfer utspridda igenom texten är fula och störande – eller kan aktivt saboterar semantiken för din text.

Aldrig, aldrig förväntar hackare att kunna läsa slutna proprietära dokumentformat som Microsoft Word eller Excel. De flesta hackare reagerar på dessa ungefär lika bra som du skulle för att ha en hög med rykande svingödsel dumpas på din tröskel. Även när de kan klara, ogillar de att behöva göra det.

Om du skickar e-post från en Windows-maskin, stäng av Microsofts problematisk „Smarta Citat“ -funktionen (From Verktyg> Alternativ för autokorrigering, rensa smarta citat kryssrutan i Autoformat vid inskrivning.). Detta är så att du undviker att strö skräptecken via din e-post.

I webbforum, inte missbruka „smiley“ och „HTML“ funktioner (när de är närvarande). En smiley eller två är oftast OK, men färgad fantasi texten tenderar att göra människor tror att du är lamt. Allvarligt överanvända smileys och färg och teckensnitt gör du komma iväg som en fnittrig tonårsflicka, som är i allmänhet inte en bra idé om du inte är mer intresserad av sex än svaren.

Om du använder en grafisk-användargränssnitt postklient som Netscape Messenger, MS Outlook, eller deras gelikar, se upp så att man kan bryta mot dessa regler när det används med standardinställningarna. De flesta sådana kunder har ett menybaserat „Visa källa“ kommandot. Använd detta på något i ditt skickade brev mapp, verifiera skicka oformaterad text utan onödiga bifogade crud.

Var precis och informativ om ditt problem

Beskriv symptomen på ditt problem eller bugg noggrant och tydligt.

Beskriv den miljö där den förekommer (maskin, OS, program, vad som helst). Ge din leverantörs distribution och versionsnivå (t.ex. „Fedora Core 7“, „Slackware 9.1“, etc.).

Beskriv den forskning du gjorde för att försöka förstå problemet innan du ställde frågan.

Beskriv de diagnostiska steg du tog för att försöka ringa in problemet själv innan du ställde frågan.

Beskriv eventuella eventuellt relevanta de senaste förändringarna i din dator eller programvarukonfiguration.

Om det alls är möjligt, ett sätt att återskapa problemet i en kontrollerad miljö.

Gör det bästa du kan för att föregripa de frågorna en hacker kommer att be, och besvara dem i förväg i din förfrågan om hjälp.

Ge hackare möjlighet att återskapa problemet i en kontrollerad miljö är särskilt viktigt om du rapporterar något du tycker är en bugg i koden. När du gör detta, dina odds att få ett användbart svar och den hastighet med vilken du sannolikt kommer att få det svaret både förbättrar enormt.

Simon Tatham har skrivit en utmärkt essä med titeln Hur man rapporterar fel effektivt. Jag rekommenderar starkt att du läser den.

Volymen är inte precisionen

Du måste vara exakt och informativ. Denna ände serveras inte bara genom att dumpa stora mängder kod eller data i en begäran hjälp. Om du har en stor, komplicerad testfall som bryter ett program, försök att trimma den och göra den så liten som möjligt.

Du måste vara exakt och informativ. Denna ände serveras inte bara genom att dumpa stora mängder kod eller data i en begäran hjälp. Om du har en stor, komplicerad testfall som bryter ett program, försök att trimma den och göra den så liten som möjligt.

Detta är användbart för åtminstone tre skäl. Ett: att bli sedd att satsa på att förenkla frågan gör det mer troligt att du får ett svar, två: förenkla frågan gör det mer troligt att du får ett användbart svar. Tre: I processen att förfina din felrapport, kan du utveckla en fix eller komma runt själv.

Ha inte bråttom att hävda att du har hittat en bugg

När du har problem med ett program, inte påstå att du har hittat en bugg om du inte är väldigt, väldigt säker på din mark. Tips: om du inte kan ge en källkod patch som fixar problemet, eller en regressionstester mot en tidigare version som visar felaktiga beteende, är du förmodligen inte säker nog. Detta gäller för webbsidor och dokumentation, också; Om du har hittat ett dokumentations „bugg“, ska du leverera ersättningstexten och vilka sidor man ska gå vidare.

Kom ihåg att det finns många andra användare som inte upplever ditt problem. Annars skulle du ha lärt dig om det när man läser dokumentationen och söka på webben (du gjorde det innan klaga, inte du?). Detta innebär att mycket förmodligen det är du som gör något fel, inte programvaran.

De människor som skrev programvaran arbetar mycket hårt för att få det att fungera så bra som möjligt. Om du påstår att du har hittat en bugg, kommer du att impugning sin kompetens, vilket kan väcka anstöt vissa av dem även om du har rätt. Det är speciellt odiplomatiskt att skrika „bug“ i ämnesraden.

När frågar din fråga, är det bäst att skriva som om du antar att du gör något fel, även om du är privat ganska säker på att du har hittat en verklig bugg. Om det verkligen är en bugg, kommer du att höra om det i svaret. Spela det så utvecklarna kommer att vilja be om ursäkt till dig om felet är verklig, snarare än så att du kommer skyldiga dem en ursäkt om du har ställt till det.

KRYPANDE är inte en ersättning för att göra dina läxor

Vissa människor som får att de inte ska bete plumpt eller arrogant, krävande ett svar, retirera till den motsatta ytterligheten av lismande. „Jag vet att jag är bara en patetisk nybörjare förlorare, men …“. Detta är störande och gagnlöst. Det är särskilt irriterande när det är kopplat med vaghet om själva problemet.

Slösa inte din tid, eller vår, på råprimat politik. Istället presenterar bakgrundsfakta och din fråga så tydligt som möjligt. Det är ett bättre sätt att positionera dig än genom krypande.

Ibland webbforum har separata platser för nybörjare frågor. Om du känner att du har en nybörjare fråga, bara åka dit. Men inte kräla där heller.

Beskriv problem symptom, inte era gissningar

Det är inte nyttigt att berätta hackare vad du tycker orsakar ditt problem. (Om dina diagnostiska teorier var sådana hot stuff, skulle du vara konsult andra om hjälp?) Så, se till att du talar om för dem rå symptom på vad som går fel, snarare än dina tolkningar och teorier. Låt dem göra tolkningen och diagnos. Om du känner att det är viktigt att ange din gissning, tydligt märka det som sådant och beskriva varför det svaret inte fungerar för dig.

dum:
Jag får back-to-back SIG11 fel på kärnsammanställer, och misstänker ett hårfäste spricka på en av moderkort spår. Vad är det bästa sättet att kontrollera för dem?

bra:
Min hembyggda K6 / 233 på en FIC-PA2007 moderkort (VIA Apollo VP2 chipset) med 256MB Corsair PC133 SDRAM börjar få frekvent SIG11 fel ca 20 minuter efter påslag under kärnan samman, men aldrig i de första 20 minuterna . Omstart inte startar klockan, men stängs av under natten gör. Byta ut alla RAM hjälpte inte. Den relevanta delen av en typisk sammanställa sessionsloggen följer.

Sedan föregående punkt verkar vara en tuff en för många människor att förstå, här är en fras för att påminna dig: „Alla diagnostiker är från Missouri.“ Det amerikanska statens officiella motto är „Visa mig“ (tjänade 1899, när kongressledamoten Willard D. Vandiver sa „Jag kommer från ett land som höjer majs och bomull och cockleburs och demokrater, och skummande vältalighet varken övertygar inte heller tillfredsställer mig. Jag är från Missouri. Du måste visa mig. „) I diagnostiker“ fall, det är inte en fråga om skepticism, utan snarare en bokstavlig, funktionell behov av att se det som är så nära som möjligt till samma råa bevis på att du ser, snarare än dina gissningar och sammanfattningar. Visa oss.

Beskriv ditt problem symptom i kronologisk ordning

De ledtrådar mest användbara i att räkna ut något som gick fel ofta ligga i händelserna omedelbart före. Så ska ditt konto beskriva exakt vad du gjorde och vad maskinen och programvara gjorde, som leder upp till blowup. I fallet med kommandoraden processer, som har en session log (t.ex. med hjälp av skript verktyg) är mycket användbar och citera de relevanta tjugotal linjer.

Om programmet som blåste upp på dig har diagnostiska alternativ (t.ex. -v för verbose), försök att välja alternativ som kommer att lägga till nytta felsökningsinformation till avskriften. Kom ihåg att mer är inte nödvändigtvis bättre; Försök att välja ett felsökningsnivå som kommer att informera snarare än att drunkna läsaren i skräp.

Om ditt konto slutar vara lång (mer än cirka fyra stycken), kan det vara bra att kortfattat ange problemet där uppe, sedan med den kronologiska berättelsen. På så sätt kommer hackare vet vad man ska titta efter i att läsa ditt konto.

Beskriv målet, inte steget

Om du försöker att ta reda på hur man gör något (i motsats till rapportering en bugg), börja med att beskriva målet. Först då beskriva den speciella steg mot det som du är blockerad på.

Ofta människor som behöver teknisk hjälp har ett mål på hög nivå i åtanke och fastnar på vad de tycker är en särskild väg mot målet. De kommer för att få hjälp med steg, men inser inte att vägen är fel. Det kan ta betydande ansträngningar för att komma förbi detta.

Stupid:
Hur får jag färgväljaren på FooDraw program för att ta ett hexadecimalt RGB-värde?

Smart:
Jag försöker byta färgtabellen på en bild med värden på min välja. Just nu är det enda sättet jag kan se att göra detta är genom att redigera varje bord kortplats, men jag kan inte få FooDraw s färgväljaren för att ta ett hexadecimalt RGB-värde.

Den andra versionen av frågan är smart. Det gör ett svar som tyder ett verktyg bättre lämpad för uppgiften.

Fråga inte folk att svara genom privata e-post

Hackare tror lösa problem bör vara en offentlig, öppen process under vilken en första försök på ett svar kan och bör korrigeras om någon mer kunniga meddelanden om att det är ofullständig eller felaktig. Också, medhjälpare får en del av sin lön för att vara respondenter från att bli sedd för att vara kompetent och kunnig av sina kamrater.

När du ber om en privat svar, du stör både processen och belöningen. Gör inte detta. Det är respondentens val om du vill svara privat – och om han eller hon gör, är det oftast för att han eller hon tycker att frågan är för dåligt bildade eller uppenbar att vara intressant för andra.

Det finns ett begränsat undantag från denna regel. Om du tror att frågan är sådan att du sannolikt kommer att få många svar som alla är närbesläktat, då de magiska orden är „e-post till mig och jag ska sammanfatta svaren för gruppen“. Det är artig att försöka rädda e-postlista eller diskussionsgrupp en flod av väsentligen identiska inlägg – men du måste hålla löftet att sammanfatta.

Var tydlig om din fråga

Öppna frågor tenderar att uppfattas som öppna ändar tids sänkor. Dessa människor som mest sannolikt att kunna ge dig ett användbart svar är också de mest trafikerade människor (om bara för att de tar på de mest jobbar själva). Folk gillar som är allergiska mot öppna ändar tids sänkor, vilket de tenderar att vara allergisk mot öppna frågor.

Du är mer sannolikt att få en användbar respons om du är tydlig med vad du vill respondenterna att göra (ge pekare, skicka koden, kontrollera din lapp, vad som helst). Detta kommer att fokusera sina insatser och implicit sätta en övre gräns för den tid och energi en svarande måste avsätta till att hjälpa dig. Detta är bra.

För att förstå världen experterna lever i, tänk på expertis som en riklig resurs och tid att svara som en knapp en. Den mindre av en tid engagemang som du implicit be om, desto mer sannolikt är det att du får ett svar från någon riktigt bra och riktigt upptagen.

Så det är bra att rama din fråga att minimera den tid engagemang som krävs för en expert till fält det – men det är ofta inte samma sak som att förenkla frågan. Således, till exempel, „Vill du ge mig en pekare till en bra förklaring av X?“ Är oftast en smartare fråga än „Skulle du förklara X, snälla?“. Om du har några funktionsstörningar kod, är det oftast smartare att be för någon att förklara vad som är fel med det än det är att be någon att fixa det.

När man frågar kod

Fråga inte andra att felsöka din trasiga kod utan att ge en ledtråd vad för slags problem de ska söka efter. Posta ett par hundra rader kod, säger „det fungerar inte“, kommer att få dig ignoreras. Posta ett dussin rader kod, säger „efter rad 7 Jag hade förväntat mig att se , men inträffade istället“ är mycket mer benägna att få dig ett svar.

Det mest effektiva sättet att vara exakt en kod problem är att ge en minimal bugg-demonstrerar testfall. Vad är en minimal testfall? Det är en illustration av problemet; bara tillräckligt med kod för att uppvisa den oönskade beteende och inte mer. Hur gör man en minimal testfall? Om du vet vilken linje eller kodavsnitt producerar den problematiska beteende, gör en kopia av den och lägga precis tillräckligt stöd kod för att producera en komplett exempel (dvs tillräckligt att källan är godtagbart för kompilatorn / tolken / vad programmet bearbetar den) . Om du inte kan begränsa den till en viss del, gör en kopia av källan och börja ta bort bitar som inte påverkar den problematiska beteende. Ju mindre din minimala testfall är, desto bättre (se avsnittet „Volym är inte precision“).

Generera en riktigt liten minimal testfall kommer inte alltid att vara möjligt, men försöker är bra disciplin. Det kan hjälpa dig att lära dig vad du behöver för att lösa problemet på egen hand – och även när det inte gör det, hackare vilja se att du har försökt. Det kommer att göra dem mer samarbetsvillig.

Om du bara vill ha en kodgranskning, säger så mycket på framsidan, och se till att nämna vilka områden du tycker kanske framför allt behöver översyn och varför.

Lägg inte upp läxor frågor

Hackare är bra på att upptäcka läxor frågor; de flesta av oss har gjort dem själva. Dessa frågor är för dig att träna, så att du kommer att lära av erfarenheterna. Det är OK att be om tips, men inte för hela lösningar.

Om du misstänker att du har passerat en läxa fråga, men kan inte lösa det ändå, försök att be i en användargrupp forum eller (som en sista utväg) i en „användare“ lista / forum i ett projekt. Medan hackare kommer upptäcka det, kan en del av de avancerade användarna åtminstone ge dig en ledtråd.

Rensa onödiga förfrågningar

Motstå frestelsen att stänga din förfrågan om hjälp med semantiskt-null frågor som „Kan någon hjälpa mig?“ Eller „Finns det ett svar?“ Först: om du har skrivit ditt problem beskrivning halvvägs kompetent, sådan uppsatt-on frågor är på bästa överflödig. Andra: eftersom de är överflödiga, hackare hitta dem irriterande – och kommer sannolikt att återvända logiskt oklanderliga men avvisande svar som „Ja, du kan få hjälp“ och „Nej, det finns ingen hjälp för dig.“

Generellt frågar ja-eller-nej-frågor är en bra sak att undvika om du inte vill att en ja-eller-inget svar.

Inte flagga din fråga som „Brådskande“, även om det är för dig

Det är ditt problem, inte vårt. Påstå brådska är mycket sannolikt att vara kontraproduktiva: de flesta hackare kommer helt enkelt ta bort sådana meddelanden som oförskämd och själviska försök att framkalla omedelbar och särskild uppmärksamhet. Vidare ordet „Brådskande“ (och andra liknande försök att fånga uppmärksamhet i ämnesraden) ofta utlöser spamfilter – avsedda mottagarna kan aldrig se det alls!

Det finns ett halv undantag. Det kan vara värt att nämna om du använder programmet i vissa högprofilerade plats, en som hackare kommer bli upphetsad över; i så fall, om du är under tidspress, och du säger så artigt, kanske folk blir intresserade nog att svara snabbare.

Detta är en mycket riskabel sak att göra, men eftersom hackare „metric för vad som är spännande skiljer troligen från din. Utstationering från den internationella rymdstationen skulle kvalificera, till exempel, men att publicera på uppdrag av en feel-good välgörande eller politisk orsak skulle nästan säkert inte. Faktum posting „Brådskande: Hjälp mig rädda luddiga sälungar!“ Kommer säkert få dig skydde eller flammade även av hackare som tror fuzzy sälungar är viktiga.

Om du hittar denna mystiska, åter läsa resten av denna how-to upprepade gånger tills du förstår det innan du skickar något alls.

Artighet skadar aldrig, och ibland hjälper

Var artig. Använd „Please“ och „Tack för er uppmärksamhet“ eller „Tack för din fråga“. Gör det klart att du uppskattar den tid människor spenderar hjälper dig gratis.

För att vara ärlig, det är inte lika viktigt som (och kan inte ersätta) är grammatiskt, tydlig, exakt och beskrivande, undvika proprietära format etc .; hackare i allmänhet skulle snarare få något bryska men tekniskt skarpa felrapporter än artigt vaghet. (Om detta pussel du, kom ihåg att vi värde en fråga från vad den lär oss.)

Men om du har fått dina tekniska ankor i rad, gör artighet öka dina chanser att få ett användbart svar.

(Vi måste konstatera att den enda allvarlig invändning vi har fått från veteran hackare att denna HOWTO är med hänsyn till vår tidigare rekommendation att använda „Tack på förhand“. Vissa hackare känner här betecknar en avsikt att inte tacka någon efteråt. Vår rekommendation är antingen säga „Tack på förhand“ först och tackar respondenter efteråt, eller uttrycka artighet på ett annat sätt, till exempel genom att säga „Tack för er uppmärksamhet“ eller „Tack för din fråga“.)

Följ upp med en kort notering på lösningen

Skicka en anteckning efter att problemet har lösts till alla som hjälpt dig; låt dem veta hur det kom ut och tacka dem igen för deras hjälp. Om problemet lockade allmänt intresse i en e-postlista eller diskussionsgrupp, är det lämpligt att bokföra uppföljning där.

Optimalt ska svaret vara att tråden startades av den ursprungliga frågan utstationering, och borde ha „fasta“, „SATT“ eller en lika självklar tagg i ämnesraden. På sändlistor med snabb vändning, en potentiell respondent som ser en tråd om „Problem X“ slutar med „Problem X – FAST“ vet inte slösa hans / hennes tid ens läsa tråden (såvida (s) han personligen finner Problem X intressant ) och kan därför använda den tiden att lösa ett annat problem.

Din uppföljning behöver inte vara lång och engagerade; en enkel „Howdy – det var en misslyckad nätverkskabel! Tack, alla. – Bill „skulle vara bättre än ingenting. I själva verket är ett kort och koncist sammandrag bättre än en lång avhandling om inte lösningen har verklig teknisk djup. Säg vilka åtgärder löste problemet, men du behöver inte spela hela felsökningssekvensen.

För problem med vissa djup, är det lämpligt att skicka en sammanfattning av felsökningshistoria. Beskriv din sista problemet uttalande. Beskriv vad som fungerade som en lösning, och ange påverkbara vändsgränder efter det. De återvändsgränder bör komma efter den rätta lösningen och andra sammanfattande material, snarare än att vända uppföljningen i en deckare. Namnge namnen på människor som hjälpte dig; du kommer att få vänner på det sättet.

Förutom att vara artig och informativ, kommer denna typ av uppföljning hjälpa andra som söker arkivet av sändlista / diskussionsgrupp / forum för att veta exakt vilken lösning hjälpt dig och därmed kan också hjälpa dem.

Sist och inte minst, bidrar denna typ av uppföljning alla som hjälpte känner en tillfredsställande känsla av nedläggning om problemet. Om du inte är en techie eller hacker själv, lita på oss att denna känsla är mycket viktigt att de gurus och experter som du tryckt på hjälp. Problem berättelser som leden ut i olösta intighet är frustrerande saker; hackare kliar att se dem löst. Den goodwill som kliar som kliar tjänar du kommer att vara mycket, mycket hjälp för dig nästa gång du behöver ställa en fråga.

Fundera på hur du skulle kunna hindra andra från att ha samma problem i framtiden. Fråga dig själv om en dokumentation eller FAQ plåster skulle hjälpa, och om svaret är ja skicka den patch till ansvariga.

Bland hackare, är denna typ av god uppföljning beteende faktiskt viktigare än konventionella artighet. Det är hur du får ett rykte om att spela bra med andra, som kan vara en mycket värdefull tillgång.

Hur man ska tolka svar

RTFM och STFW: Hur berätta Du har Allvarligt skruvas upp

Det är en gammal och heliga traditionen: om du får ett svar som lyder „RTFM“, den person som skickade den tycker att du borde ha läst Fucking Manual. Han eller hon är nästan säkert rätt. Gå läsa det.

RTFM har en yngre släkting. Om du får ett svar som lyder „STFW“, den person som skickade den tycker att du borde ha sökt Jävla webben. Han eller hon är nästan säkert rätt. Gå söka det. (Den mildare version av detta är när du säger „Google är din vän!“)

I webbforum, kan du också få veta att söka forumet arkiven. I själva verket kan någon ens vara så vänlig att ge en pekare till den tidigare tråden där problemet var löst. Men lita inte på detta övervägande; gör ditt arkiv rannsakan innan du frågar.

Ofta den person som talar om att göra en sökning har manuell eller webbsidan med den information du behöver öppna, och titta på det som han eller hon typer. Dessa svar innebär att svars tänker (a) den information du behöver är lätt att hitta, och (b) du lära dig mer om du söker upp den information än om du har det sked-fed till dig.

Du ska inte vara förolämpade av detta; genom hacker standarder, är din respondenten visar dig en grov slags respekt genom att helt enkelt inte ignorera dig. Du bör istället vara tacksamma för detta grandmotherly vänlighet.

Om du inte förstår …

Om du inte förstår svaret, inte omedelbart studsa tillbaka en efterfrågan på förtydligande. Använd samma verktyg som du använde för att försöka svara på din ursprungliga fråga (manualer, FAQ, webben, skickliga vänner) för att förstå svaret. Sedan, om du fortfarande behöver be om klargöranden, uppvisar vad du har lärt.

Anta till exempel att jag säger dig: „Det låter som att du har ett fast zentry; du behöver för att klara det „Då: Här är en dålig uppföljning fråga:“.? Vad är en zentry „Här är en bra uppföljning fråga:“ OK, jag läste mannen sidan och zentries nämns endast under -z och -p switchar . Ingen av dem säger något om clearing zentries. Är det en av dessa eller är jag missat något här? “

Hantering av råhet

Mycket av det som ser ut som elakhet i hackerkretsar är inte avsedd att väcka anstöt. Snarare är det en produkt av den direkta, cut-through-the-skitsnack kommunikationsstil som är naturligt att människor som är mer bekymrad över att lösa problem än att göra andra känner sig varm och fuzzy.

När du uppfattar råhet, försök att reagera lugnt. Om någon verkligen agerar ut, är det mycket troligt en senior person på listan eller diskussionsgrupp eller forum kommer att kalla honom eller henne på det. Om detta inte sker och du tappar humöret, är det troligt att den personen du förlorar den på betedde inom hacker samfundets normer och du kommer att behandlas vid fel. Detta kommer att skada dina chanser att få den information eller hjälp du vill ha.

Å andra sidan, kommer du ibland köra över elakhet och poser som är ganska meningslöst. Flip-sidan av ovanstående är att det är acceptabel form att slam verkliga brottslingar ganska hårt, dissekera deras dåligt uppförande med en skarp verbal skalpell. Var väldigt, väldigt säker på din mark innan du försöker detta, dock. Linjen mellan korrigera en ohövlighet och starta en meningslös e-gräl är tunn nog att hackare själva inte sällan blunder över det; om du är nybörjare eller en outsider, dina chanser att undvika en sådan blunder är låga. Om du är ute efter information snarare än underhållning, det är bättre att hålla fingrarna från tangentbordet än att riskera detta.

(Vissa människor hävdar att många hackare har en mild form av autism eller Aspergers syndrom, och faktiskt saknar några av hjärnan kretsar som smörjer „normal“ människa social interaktion. Detta kan eller inte kan vara sant. Om du inte är en hacker själv , kan det hjälpa dig att klara av våra egenheter om du tycker om oss som hjärnskadad Gå höger vidare Vi kommer inte vård,.. vi gillar att vara vad det är vi är, och i allmänhet har en sund skepsis kliniska etiketter).

I nästa avsnitt kommer vi att tala om en annan fråga; den typ av „elakhet“ du ser när du missköter.

På Inte Reagera som en förlorare

Oddsen är du kommer att skruva upp ett par gånger på hacker forum – på ett sätt som beskrivs i den här artikeln, eller liknande. Och du kommer få veta exakt hur du skruvas upp, möjligen med färgglada reserverade. Offentligt.

När detta händer är det värsta du kan göra gnälla om sina erfarenheter, anspråk på att ha verbalt misshandlade, efterfrågan ursäkter, skrika, hålla andan, hotar stämningar, klaga till människors arbetsgivare, lämna toalettsitsen upp, etc. Istället Här är vad du gör:

Få över den. Det är normalt. I själva verket är det hälsosamt och lämpligt.

Gemenskapsnormer inte försörja sig själva: De är underhålls av människor att aktivt tillämpa dem, synligt, offentligt. Inte gnälla om att all kritik borde ha förmedlat via privat e-post: Det är inte hur det fungerar. Det är inte heller lämpligt att insistera du har personligen förolämpad när någon kommenterar att en av dina påståenden var fel, eller att hans åsikter skiljer sig åt. De är loser attityder.

Det har varit hacker forum där, av någon missriktad känsla av hyper artighet, är deltagarna förbjudna från att skicka någon felsökning med varandras inlägg, och berättade „Säg ingenting om du är ovillig att hjälpa användaren.“ Det resulte avgång klipska deltagare till andra ställen får dem att stiga ned i menings jollra och blir värdelös som tekniska forum.

Drivet „friendly“ (på det sättet) eller användbart: Välj en.

Kom ihåg: När det hacker säger att du har skruvas upp, och (oavsett hur gruffly) berättar att inte göra det igen, han agerar av oro för (1) du och (2) sitt samhälle. Det skulle vara mycket lättare för honom att ignorera dig och filtrera dig ur hans liv. Om du inte kan hantera att vara tacksam, åtminstone ha lite värdighet, inte gnälla, och förvänta dig inte att behandlas som en bräcklig docka bara för att du är en nykomling med ett teatraliskt överkänslig själ och vanföreställningar om rätten .

Ibland människor kommer att attackera dig personligen, flamma utan uppenbar anledning, etc., även om du inte skruva upp (eller har bara skruvas upp i sin fantasi). I detta fall är klaga på sättet att verkligen skruva upp.

Dessa flamers är antingen Lamers som inte har en aning om, men anser sig vara experter, eller blivande psykologer testa att du ska skruva upp. De andra läsare ignorera antingen dem eller hitta sätt att hantera dem på egen hand. De flamers beteende skapar problem för sig själva, som inte har att röra dig.

Låt inte dig själv dras in i ett e-gräl, heller. De flesta flammor är bäst ignoreras – efter att du har kontrollerat om de är verkligen lågor, inte pekare till de sätt på vilka du har skruvas upp, och inte skickligt chiffre svar på din verkliga frågan (det händer också).

Frågor att inte fråga

Här är några klassiska dumma frågor, och vad hackare tänker när de inte besvarar dem.

Fråga: Var kan jag hitta program eller resurs X?
Fråga: Hur kan jag använda X för att göra Y?
Fråga: Hur kan jag konfigurera mitt skal prompten?
F: Kan jag konvertera en AcmeCorp dokument till en Tex-fil med Bas-o-matic fil omvandlare?
Fråga: Min {program, konfiguration, SQL-uttryck} fungerar inte
Fråga: Jag har problem med min Windows-dator. Kan du hjälpa till?
Fråga: Mitt program fungerar inte. Jag tror systemet anläggning X är bruten.
Fråga: Jag har problem med att installera Linux eller X. Kan du hjälpa till?
Fråga: Hur kan jag knäcka root / stjäla kanal-ops privilegier / läs någons e-post?
F:

Var kan jag hitta program eller resurs X?

A:

Samma ställe jag skulle finna det, lura – i andra änden av en webbsökning. Ghod, inte alla vet hur man använder Google ännu?

F:

Hur kan jag använda X för att göra Y?

A:

Om vad du vill är att göra Y, ska du ställa den frågan utan föregående antar att använda en metod som inte kan vara lämpliga. Frågor om denna form visar ofta en person som inte bara okunniga om X, men förvirrad över vad problemet Y de lösa och alltför fixerade på detaljerna i deras speciella situation. Det är i allmänhet bäst att ignorera sådana människor tills de definierar deras problem bättre.

F:

Hur kan jag konfigurera mitt skal prompten?

A:

Om du är smart nog att ställa denna fråga, du är smart nog att RTFM och ta reda på själv.

F:

Kan jag konvertera en AcmeCorp dokument till en Tex-fil med Bas-o-matic fil omvandlare?

A:

Prova det och se. Om du gjorde det, skulle du (a) lär svaret, och (b) sluta slösa min tid.

F:

Min {programmet, konfiguration, SQL-uttryck} fungerar inte

A:

Detta är inte en fråga, och jag är inte intresserad av att spela Tjugo frågor att bända din faktiska frågan ur dig – jag har bättre saker att göra. På att se något som detta, är min reaktion normalt för en av följande:

har du något annat att tillägga till det?

åh, det är för dåligt, jag hoppas du få fast.

och detta har exakt vad de ska göra med mig?

F:

Jag har problem med min Windows-dator. Kan du hjälpa till?

A:

Ja. Kasta ut att Microsoft skräp och installera ett operativsystem med öppen källkod som Linux eller BSD.

Obs: Du kan ställa frågor om Windows-maskiner, om de handlar om ett program som har någon officiell Windows bygga, eller interagerar med Windows-maskiner (dvs, Samba). Bara inte bli förvånad av svaret att problemet är med Windows och inte programmet, eftersom Windows är så trasig i allmänhet att det är väldigt ofta fallet.

F:

Mitt program fungerar inte. Jag tror systemet anläggning X är bruten.

A:

Även om det är möjligt att du är den första personen att märka en uppenbar brist i systemanrop och bibliotek tungt används av hundratals eller tusentals människor, är det ganska troligt att du är helt clueless. Extra skador kräver extraordinära bevis; när du gör ett påstående som den här, måste du backa upp det med tydlig och uttömmande dokumentation av misslyckande fallet.

F:

Jag har problem med att installera Linux eller X. Kan du hjälpa till?

A:

Nej, jag skulle behöva praktisk tillgång till din maskin för att felsöka detta. Gå frågar din lokala Linuxanvändargrupp för praktisk hjälp. (Du hittar en lista över användargrupper här.)

Obs: frågor om installation Linux kan vara lämpligt om du är på ett forum eller e-postlista om en viss fördelning, och problemet är med den distro; eller på lokala användargrupper forum. I det här fallet, se till att beskriva de exakta detaljerna i misslyckandet. Men gör försiktig söka först, med „linux“ och alla misstänkta bitar av hårdvara.

F:

Hur kan jag knäcka root / stjäla kanal-ops privilegier / läs någons e-post?

A:

Du är en lowlife för att vilja göra sådana saker och en idiot för att be en hacker för att hjälpa dig.

Bra och dåliga frågor

Slutligen kommer jag att illustrera hur man ställa frågor på ett smart sätt genom exempelvis; par frågor om samma problem, frågade på ett dumt sätt och en i ett smart sätt.

Stupid: Var kan jag få reda på saker om Foonly Flurbamatic?
Denna fråga bara skriker efter „STFW“ som ett svar.

Smart: Jag använde Google för att försöka hitta „Foonly Flurbamatic 2600“ på webben, men jag fick inga användbara träffar. Kan jag få en pekare till programmeringsinformation på den här enheten?
Detta har redan STFWed och låter som det kan vara ett verkligt problem.

Stupid: Jag kan inte få koden från projekt foo att sammanställa. Varför är det bryts?
Den querent förutsätter att någon annan skruvas upp. Arrogant git …

Smart: Koden från projekt foo inte kompilera under Nulix version 6.2. Jag har läst FAQ, men det har inte något i det om Nulix-relaterade problem. Här är en utskrift av min sammanställning försök; är det något jag gjorde?
Den querent har specificerat miljön, läs FAQ, visar felet, och inte antar sina problem är någon annans fel. Detta kan vara värt lite uppmärksamhet.

Stupid: Jag har problem med mitt moderkort. Kan någon hjälpa?
J. Random Hacker svar på detta kommer sannolikt att vara „Right. Behöver du rapningar och blöjbyte, också? „, Följt av ett slag av Delete.

Smart: Jag försökte X, Y och Z på S2464 moderkort. När det inte fungerade, försökte jag A, B och C. Notera den nyfikna symptomet när jag försökte C. Uppenbarligen florbish är grommicking, men resultaten är inte vad man kan förvänta sig. Vilka är de vanliga orsakerna till grommicking på Athlon MP moderkort? Någon som har idéer för fler tester jag kan köra för att sätta fingret på problemet?
Denna person, på den andra sidan verkar värdig ett svar. Han / hon har ställt ut problemlösning intelligens snarare än att passivt vänta på svar att släppa från höjden.

I den sista frågan, märker den subtila men viktiga skillnaden mellan krävande „Ge mig ett svar“ och „Snälla hjälp mig räkna ut vilka ytterligare diagnostik jag kan köra för att nå upplysning.“

I själva verket är i form av den sista frågan noga baserad på en verklig händelse som hände i augusti 2001 på sändlistan linux-kernel (lkml). I (Eric) var den som ställer frågan då. Jag såg mystiska låsningar på en Tyan S2462 moderkort. På listan levererade den kritiska information jag behövde för att lösa dem.

Genom att ställa frågan på det sätt jag gjorde, jag gav folk något att tugga på; Jag gjorde det enkelt och attraktivt för dem att engagera sig. Jag visade respekt för mina kamrater förmåga och uppmanade dem att rådgöra med mig som en peer. Jag visade också respekt för värdet av sin tid genom att berätta de återvändsgränder jag hade redan kör ned.

Efteråt, när jag tackade alla och påpekade hur väl processen hade fungerat, observerat en lkml medlem att han trodde att det hade fungerat inte för att jag är en „namn“ på den listan, men eftersom jag ställde frågan i rätt form.

Hackare är på vissa sätt en mycket hänsynslös meritokrati; Jag är säker på att han hade rätt, och att om jag hade betett sig som en svamp skulle jag ha flammat eller ignoreras oavsett vem jag var. Hans förslag att jag skriver upp hela händelsen som instruktion till andra ledde direkt till sammansättningen av denna guide.

Om du inte kan få ett svar

Om du inte kan få ett svar, ska du inte ta det personligt att vi inte känner att vi kan hjälpa dig. Ibland medlemmarna i bett gruppen kan helt enkelt inte vet svaret. Inget svar är inte samma sak som ignoreras, men förvisso är det svårt att se skillnaden från utsidan.

I allmänhet, helt enkelt på nytt skicka din fråga är en dålig idé. Detta kommer att ses som onödigt irriterande. Ha tålamod: personen med ditt svar kan vara i en annan tidszon och sov. Eller det kan vara att din fråga inte var välformade till att börja med.

Det finns andra källor för hjälp kan du gå till, ofta källor bättre anpassat till en nybörjare behov.

Det finns många online och lokala användargrupper som är entusiaster om programvaran, även om de kanske aldrig har skrivit något program själva. Dessa grupper utgör ofta så att människor kan hjälpa varandra och hjälpa nya användare.

Det finns också gott om kommersiella företag som du kan ingå avtal med för att få hjälp, både stora och små. Var inte bestörta vid tanken på att behöva betala för lite hjälp! Trots allt, om din bil motor blåser en topplockspackning, är chansen att du skulle ta den till en verkstad och betala för att få fast. Även om programmet inte kostar dig något, kan du inte förvänta dig att stöd att alltid komma gratis.

För populära program som Linux, det finns minst 10.000 användare per utvecklare. Det är bara inte möjligt för en person att hantera supportsamtal från över 10.000 användare. Kom ihåg att även om du måste betala för support, är du fortfarande betalar mycket mindre än om du var tvungen att köpa programvaran samt (och support för programvara stängd källkod är oftast dyrare och mindre kompetent än stöd för öppen källkod) .

Hur att svara på frågor i ett hjälpsamt sätt

Var försiktig. Problem relaterad stress kan göra folk verkar oförskämd eller dum, även när de inte är.

Svar på en första gärningsmannen off-line. Det finns inget behov av offentlig förnedring för någon som kan ha gjort ett ärligt misstag. En riktig nybörjare kanske inte vet hur man söker arkiv eller när FAQ lagras eller bokförts.

Om du inte vet säkert, säger så! En fel men auktoritativ klingande svar är värre än ingen alls. Pekar inte någon ner en fel väg bara för att det är kul att låta som en expert. Var ödmjuk och ärlig; föregå med gott exempel för både querent och dina kamrater.

Om du inte kan hjälpa, inte hindrar. Inte skämta om förfaranden som kan kasserar användarens inställningar – de fattiga sap kan tolka dessa instruktioner.

Be sondering frågor för att framkalla fler detaljer. Om du är bra på det här, kommer querent lära sig något – och så kanske ni. Försök att vända dåliga frågan till ett bra; minns att vi var alla nybörjare en gång.

Medan ibland motiverat muttrade RTFM vid svar till någon som är bara en lat slusk, en pekare till dokumentation (även om det är bara ett förslag till Google för en nyckelfras) är bättre.

Om du ska svara på frågan alls, ger bra värde. Inte tyder kludgy lösningar när någon använder fel verktyg eller tillvägagångssätt. Föreslå bra verktyg. Omformulera frågan.

Svara på själva frågan! Om querent har varit så noggrann som att göra sin forskning och har i frågan om att X, Y, Z, A, B och C har redan provat utan goda resultat är det ytterst föga att svara med „Försök A eller B „eller med en länk till något som bara säger“ Försök X, Y, Z, A, B eller C. „.

Hjälp ditt samhälle lära av frågan. När du fältet en bra fråga, fråga dig själv: „Hur skulle det relevant dokumentation eller FAQ måste ändra så att ingen har att besvara detta igen?“ Då skicka en lapp till dokumentet ansvariga.

Om du gjorde forskning för att svara på frågan, visa dina färdigheter snarare än att skriva som om du drog svaret ur din rumpa. Svara en bra fråga är som att mata en hungrig människa en måltid, men lär dem forskning kompetens genom exempel visar dem hur man odlar mat för en livstid.

Närliggande resurser

Om du behöver undervisning i grunderna i hur persondatorer, Unix, och Internet arbetet, se The Unix och Internet Fundamen HOWTO.

När du släpper programvara eller skriva lappar för mjukvara, försöka följa riktlinjerna i Programvaran Release Practice HOWTO.

Tack

Evelyn Mitchell bidrog några exempel dumma frågor och inspirerade „Hur man ger ett bra svar“ avsnittet. Mikhail Ramendik bidrog vissa särskilt värdefulla förslag till förbättringar.

Comments are closed.