Så att ställa frågor på ett smart sätt


Link: http://www.catb.org/~esr/faqs/smart-questions.html
Author: Eric Steven Raymond

Swedish translation by Andrey Fomin

Ansvarsfriskrivning

Många projekt webbplatser länka till dokument i sina avsnitt om hur man kan få hjälp. Det är bra, det är användningen som vi tänkt – men om du är en webmaster att skapa en sådan länk för projektet, var vänlig välj 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 upprepade gånger bli utsatta av idioter som tror att ha publicerat detta dokument är det vårt jobb att lösa alla världens tekniska problem.

Om du läser det här dokumentet eftersom du behöver hjälp, och du går bort med det intryck man kan få det direkt från författarna till det här dokumentet , ä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 programvara eller hårdvara som du har att göra med, chokla 99,9 % av den tid som inte kommer att vara oss . Om du inte vet säkert att en av författarna är expert på vad du arbetar med , lämna oss ensamma och alla kommer att bli lyckligare.

Inledning

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

Nu när användningen av öppen källkod har blivit utbredd, kan du ofta få så bra svar från andra , mer erfarna användare 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 på det sätt som vi rekommenderar här i allmänhet 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 de. Om vi inte gjorde det, skulle vi inte vara här. Om du ger oss en intressant fråga att tugga på att vi kommer att vara tacksam för dig , 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 , är “ Bra fråga ! “ En stark och uppriktig komplimang.

Trots det , 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 reflexmässigt otrevlig mot nybörjare och de okunniga . Men detta är inte riktigt sant.

Vad vi är , unapologetically , är fientlig mot 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 det är tids sänkor – de tar utan att ge tillbaka , och de slösar tid vi skulle ha spenderat på en annan fråga mer intressant och en annan person mer värd 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 det, och förvänta dig inte att alla ska ta ett intresse för de 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å det vi gör bäst .

Vi är ( till stor del ) volontärer . Vi tar time out för hektiskt för att svara på frågor , och ibland är vi överväldigade med dem . Så vi filtrera hänsynslöst . Framför allt vi slänger frågor från människor som verkar vara förlorare för att spendera våra svar på frågor tid mer effektivt , om vinnare .

Om du finner denna attityd vidrig , nedlåtande eller arrogant , kolla dina antaganden . Vi ber dig inte att knäböja till oss – i själva verket skulle de flesta av oss älskar inget mer än att behandla dig som en jämlike och välkomnar dig in i vår kultur , om du sätter 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 den typ av attityd som leder till kompetens – alert , tankfull , uppmärksam , villig att vara en aktiv partner i att utveckla 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 svar är att ställa det som en person med smarts , självförtroende , och ledtrådar som bara råkar behöva hjälp vid ett särskilt problem .

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

Innan du frågar

Innan du ställer en teknisk fråga med e – post , eller i en nyhetsgrupp , eller på en webbplats chatt styrelse , gör följande :

Försök att hitta ett svar genom att söka arkiv forumet som du planerar att lägga 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 be 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 , vilket kommer att bidra till att fastställa att du inte är en lat svamp och slösa bort människors tid . Ännu bättre , visa vad du har lärt dig från att göra dessa saker . Vi gillar att svara på frågor för personer som har visat att de kan lära av svaren .

Använd taktik som gör en Google-sökning på texten oavsett felmeddelande du får (sökning Google grupper samt webbsidor ) . Detta kan mycket väl ta dig direkt till fixa dokumentation eller en e-postlista tråd svara på din fråga . Även om det inte , säger “ Jag googlade på följande fras 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 spelar in vad söker vunnit “ t-hjälp . Det kommer också att hjälpa till att styra andra människor med liknande problem som din tråd genom att länka söktermerna vad förhoppningsvis ditt problem och upplösning tråd .

Ta den tid du behöver. Förvänta dig inte 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 tänker att du gjorde , och kommer att vara mer villiga att hjälpa till om du kommer förberedd . Inte omedelbart eld hela din arsenal av frågor bara för att din första sökning visade upp några 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 ingen 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 ganska sannolikt att svara med onödigt bokstavlig svar samtidigt tänka “ Dum fråga … “ , och hoppas att upplevelsen av att få vad du bad om snarare än vad du behövde J. Random Hacker kommer att lära dig en läxa .

Aldrig antar att du har rätt till ett svar . Du är inte , du är inte , trots allt , att betala 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 underförstått bidrar till upplevelsen av samhället snarare än att bara passivt kräver 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 sida ska jag ha kontrollerat ? “ Är mer benägna att få svar än “ Posta den exakta proceduren jag ska använda . “ Eftersom du är vilket gör det tydligt 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 i att välja var du ställa din fråga . Du kommer sannolikt att ignoreras eller avfärdas som en förlorare , om du :

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

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

cross- post till alltför många olika diskussionsgrupper

posta en personlig e – post till någon som är varken en bekant till dig 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 . Återigen , Google och andra web-sökning metoder är din vän . Använd dem för att hitta projektets webbsida närmast förknippas med maskin-eller programvara som ger dig svårigheter . Vanligtvis kommer det att ha kopplingar till en FAQ ( Frequently Asked Questions ) lista , och att projektet 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 de frågor du hittade ) inte hittar ni en lösning . Projektsidan kan också beskriva en bugg – rapporteringsförfarande, eller har en länk till en, i så fall följa den.

Skjut bort ett e – postmeddelande till en person eller ett 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 fri konsult . Gör inte optimistiska gissningar om huruvida din fråga kommer att vara välkomna – om du är osäker , skicka det på andra ställen , eller avstå från att skicka det alls .

När du väljer ett webbforum, nyhetsgrupp eller sändlista , litar inte på namnet i sig för långt , leta efter en FAQ eller charter för att kontrollera 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 för ord som rör ditt problem på nyhetsgrupper eller sändlistearkiven innan du postar . Det kan finna dig ett svar , och om inte det kommer att hjälpa dig att formulera en bättre fråga .

Inte shotgun – spränga alla tillgängliga hjälp kanaler på en gång , det är som att skrika och irriterar folk . Stega igenom dem mjukt .

Vet du 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 ett bibliotek eller verktygs bärbar över båda . Om du inte förstår varför det är ett misstag , 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 . Man är helt enkelt storleken på poolen av potentiella respondenter . En annan ä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 , är skickliga hackare och författare till populära program redan får mer än sin beskärda del av mis – riktade meddelanden . Genom att lägga till floden , kan man i extrema fall till och med vara droppen som får bägaren att rinna över – ganska många gånger , har bidragsgivare till populära projekt dras tillbaka sitt stöd , eftersom ytterligare skador i form av värdelösa e – posttrafiken till sina personliga konton blev outhärdlig .
Webb -och IRC- forum riktade mot nybörjare ger ofta det snabbaste svaret

Din lokala användargrupp , eller din Linux-distribution , kan annonsera ett webbforum eller IRC -kanal där nybörjare kan få hjälp . ( I icke- engelskspråkiga länder nybörjare forum är ännu mer benägna att e-postlistor . ) Dessa är bra första platser att ställa, särskilt 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 .

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

Innan du skickar meddelanden till alla webbforum , kolla om den 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 i alla fall , din webbomfattandesökmotor kanske inte har allt detta forum indexe nyligen.

Det finns en ökande tendens till projekt för att göra användarstöd via ett webbforumeller IRC-kanal , med e – post reserverad mer för utvecklings trafik . Så leta efter de kanaler som först när de söker projektspecifik hjälp.
Som ett andra steg , använd projektsändlistor

När ett projekt har en utveckling sändlista , skriver på sändlistan , inte till enskilda utvecklare , även om du tror att du vet vem som bäst kan besvara din fråga . Kontrollera dokumentationen av projektet och dess hemsida på adressen till ett projekt e-postlista , och använder den . Det finns flera goda skäl till denna policy :

Varje fråga tillräckligt bra för att bli tillfrågad av 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 lasten 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 den besvaras , skulle en framtida querent hitta din fråga och svaret på webben istället för att fråga igen .

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

Om ett projekt har både en “ användare “ och en “ utvecklare “ ( eller “ hacker “ ) sändlista eller webbforum, och du inte hacka på koden , fråga i “ user “ lista / forum . Förutsätt inte att du kommer att vara välkomna på utvecklarens listan , där de är sannolikt att uppleva din fråga så buller störa deras utvecklare trafik .

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

Om du inte kan hitta ett projekts sändlista adress , utan bara se adressen till den ansvarige för projektet , gå vidare och skriva till den ansvarige . Men även i detta fall , 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ändlistan . Också nämna att du inte har några invändningar mot att ha ditt meddelande vidarebefordras till andra människor . ( Många tror att privat e – post bör förbli privat, även om det inte finns något hemligt i den. Genom att låta ditt budskap för att vidarebefordras du ger din korrespondent ett val om hur du hanterar din e – post . )
Använd meningsfulla , specifika ämnes rubriker

På e-postlistor, diskussionsgrupper och webbforum, är föremål header ditt gyllene tillfälle att locka kvalificerade experter uppmärksamhet i cirka 50 tecken eller färre . Slösa inte bort det på babbel som “ Hjälp mig “ ( än mindre “ Snälla hjälp mig ! “ , 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 beskrivning av problemet istället .

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

Durx:

HJÄLP ! Video fungerar inte på min laptop !

Umh:

X.org 6.8.1 deformerade musmarkören , Fooware MV1005 vid. chipset
smartare :

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

Processen med att skriva en “ 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 det specifika för X.org version av X ? För version 6.8.1 ? Är det specifikt för Fooware video chipset ? För att modellera MV1005 ? En hackare som ser resultatet kan omedelbart förstå vad det är som du har problem med och det problem du har , med ett ögonkast .

Mer allmänt , föreställa sig att titta på index för ett arkiv av frågor , med bara ämnesrader visar . Gör din ämnesraden spegla din fråga tillräckligt väl att nästa kille 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 ange att du frågar en fråga . Ett ämne linje som ser ut som “ Re : test“ eller “ Re : ny bug “ är mindre sannolikt att locka användbara mängder av uppmärksamhet . Också pare citat av tidigare meddelanden att de överensstämmer med cluing i nya läsare .

Inte bara slå svar på en meddelandelista för att starta en helt ny tråd . Detta begränsar dina åhörare . Vissa e-postläsare, som mutt , tillåter användaren att sortera efter tråd och sedan dölja 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 är rubriker för att tilldela den till en tråd , inte ämnesraden . Istället startar en helt ny e – post .

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

Gör det enkelt att svara

Efterbehandling 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 krävs för att upprätta ett korrekt Reply – To-fältet i ditt mail 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 e-postprogram . Om ditt operativsystem inte stöder någon e – postprogram som tillåter detta , få ett bättre operativsystem .

I Web forum , be om ett svar via e – post är regelrätt oförskämd , om du anser att informationen kan vara känslig ( och någon kommer , av okänd anledning , låt dig men inte hela forumet vet det ) . Om du vill ha en e – postkopianär någon svarar i tråden , begära att webbforum skicka det , denna funktion stöds nästan överallt i alternativ som “ titta på denna tråd “ , “ skicka e – post på svar “ , etc.
Skriv i klara, grammatiska , rätt – stavat språk

Vi har märkt av erfarenhet att människor som är vårdslösa och slarviga skribenter är oftast också oförsiktig och slarvig på att tänka och kodning ( ofta nog att satsa på , i alla fall ) . Svara på frågor för slarvig och slarviga tänkare är inte givande , vi skulle hellre tillbringar vår tid på andra ställen .

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ängning för att polera ditt språk . Det behöver inte vara stel eller formella – i själva verket , hacker kulturvärdeninformell , FULL AV SLANG och humoristiska 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 “ sina “ med „det är “ , “ lös “ med “ förlora “ , eller “ diskret “ med “ diskret“ . Skriv inte med stora bokstäver , det läses som skriker och anses vara oförskämd . ( All – smalls är bara 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 halvkunnigboob du kommer mycket sannolikt att ignoreras . Så inte använda genvägar instant- messaging . Stavning “ du “ som “ u “ gör att du ser ut som en halvkunnigboob att spara två hela tangenttryckningar . Sämre : att skriva ut som en l33t script kiddie 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 utbyte .

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 ditt respondentens språk , skriver på engelska . Upptagen hackare tenderar att helt enkelt spola frågor på språk som de inte förstår , och engelska är arbetsspråket på Internet . Genom att skriva på engelska som du minimerar dina chanser att din fråga kommer att kasseras 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 för potentiella svårigheter och alternativ för att komma runt dessa språk . 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åra 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 artificiellt svår att läsa , är det mer sannolikt att föras över till förmån för en som inte är . Alltså:

Skicka oformaterad text 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 ( till exempel en annan kopia av ditt meddelande ) .

Skicka inte e – post , där hela stycken är ensamstående multiplicera – 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 mail på 80 – teckenomfattandetext visas och ange din linje wrap därefter , till något mindre än 80 .

Dock inte linda in data (till exempel loggfilensoptippar eller sessions avskrifter ) vid varje kolumnbreddfast . Data bör ingå som – är , så respondenterna kan ha förtroende för att de ser vad du såg .

Skicka inte MIME quoted-printable -kodning till ett engelskspråkigt 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 tecken utspridda genom texten är fula och störande – eller kan aktivt sabotera semantiken i din text .

Aldrig, aldrig räkna med 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 vill att ha en hög med ångande svingödsel dumpas utanför dörren . Även när de kan klara , de ogillar att behöva göra det .

Om du skickar e – post från en Windows- maskin , stäng av Microsofts problematiska “ smarta citationstecken “ säkring (från Verktyg > Alternativ för autokorrigering , avmarkera kryssrutan smarta citat i Autoformat vid inskrivning . ) . Det är så att du undviker att strö skräptecken via din mail .

I webbforum, inte missbrukar “ smiley “ och “ HTML “ funktioner ( när de är närvarande ) . En smiley eller två är oftast OK , men färgat utsmyckad text tenderar att få folk att tro att du är lam . Allvarligt överanvända smileys och färg och teckensnitt får dig att komma iväg som en fnittrig tonåring , som är i allmänhet inte en bra idé om du är mer intresserad av sex än svar .

Om du använder ett grafiskt -user- interface postklient som t.ex. Netscape Messenger , MS Outlook , eller deras gelikar , se upp så att det kan strida mot dessa regler när de används med standardinställningarna . De flesta sådana kunder har en meny – baserad “ Visa källa “ -kommando . Använd detta på något i ditt skickade -postmapp , verifiera sändning av vanlig text utan onödiga bifogade crud .
Var exakt och informativ om ditt problem

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

Beskriv den miljö där den förekommer ( maskin , operativsystem , program , vad som helst ) . Ge din leverantörs distribution och frigörnivå(till exempel : “ Fedora Core 7 “ , “ Slackware 9.1 “ , etc. ) .

Beskriv den forskning som 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 möjligen relevanta senaste förändringarna i din dator eller konfigurationsprogram .

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

Gör det bästa du kan för att förutse frågorna en hacker kommer att ställa, och besvara dem i förväg i din begäran om hjälp .

Att ge hackare möjlighet att återskapa problemet i en kontrollerad miljö är särskilt viktigt om du rapporterar något som du tror är ett fel 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ättras 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 precision

Du måste vara exakt och informativ . Denna ände är inte betjänt av att helt enkelt dumpa enorma mängder kod eller data i en begäran om 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 kommer att få ett svar, två: att 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 dig själv.
Ha inte bråttom att hävda att du har hittat en bugg

När du har problem med ett program , inte hävda 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 åtgärdar problemet , eller en regression test mot en tidigare version som visar felaktiga beteende , är du antagligen inte säker nog . Detta gäller för webbsidor och dokumentation , också, om du har hittat en dokumentation “ bug “ , ska du ange ersättningstext och vilka sidor den ska gå vidare.

Kom ihåg att det finns många andra användare som inte upplever problemet . Annars skulle du ha lärt sig om det när man läser dokumentationen och söka på webben ( du gjorde det innan du klagar , eller hur ? ) . Det innebär att mycket sannolikt det är du som gör något fel , inte programvaran .

De människor som skrev programmet 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 kränka vissa av dem även om du har rätt . Det är särskilt odiplomatiska att skrika “ bug “ på ämnesraden .

När du 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 , du kommer att höra om det i svaret . Spela det så de ansvariga kommer att vilja be om ursäkt till dig, om felet är verklig , i stället så att du kommer är skyldig 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 sig oförskämt eller arrogant , kräver ett svar , dra sig tillbaka till den motsatta ytterligheten av lismande . “ Jag vet att jag är bara en patetisk nybörjare förlorare , men … “ . Det är störande och onödigt. Det är särskilt irriterande när det är i kombination med vaghet om själva problemet .

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

Ibland webbforumhar separata platser för nybörjare frågor . Om du känner att du har en newbie fråga , bara gå dit . Men inte kräla där heller .
Beskriv problemet symptom , inte dina gissningar

Det är inte bra att berätta för hackare vad du tror orsakar problemet . ( Om dina diagnostiska teorier var sådana hot stuff , skulle du ha hört andra om hjälp ? ) Så, se till att du berättar 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 .

Umh:

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

Min hembyggda K6/233 på ett FIC – PA2007 moderkort ( VIA Apollo VP2 chipset ) med 256MB Corsair PC133 SDRAM börjar bli frekventa SIG11 fel ungefär 20 minuter efter påslag under kärnan sammanställer , men aldrig i de första 20 minuterna . Omstart inte starta om klockan , men stängs av under natten gör. Att byta ut alla RAM hjälpte inte . Den relevanta delen av en typisk sammanställa sessionsloggenföljer .

Eftersom den föregående punkten 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 . “ Den 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 från Missouri . du måste visa mig . “ ) i diagnostiker “ fall , det är inte en fråga om skepsis , utan snarare en bokstavlig , funktionellt behov av att se allt som är så nära som möjligt till samma råa bevis som 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 ligger ofta 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 . Vid kommandoraden processer , som har en sessionslogg(t.ex. med hjälp av skript verktyg ) och citerar de relevanta tjugotal linjer är mycket användbart .

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

Om ditt konto hamnar är långa ( mer än cirka fyra stycken ) , kan det vara lämpligt att kortfattat ange problemet upp toppen , följ 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 ta reda på hur man gör något ( i motsats till att rapportera en bugg ) , börja med att beskriva målet . Först då beskriva särskilda steget mot det som du är blockerade på .

Ofta människor som behöver teknisk hjälp har ett mål på hög nivå i sinnet och fastna på vad de tycker är en viss väg mot målet . De kommer för att få hjälp med det steget , men inser inte att sökvägen är fel . Det kan ta avsevärd ansträngning för att komma förbi detta .

Umx :

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

Jag försöker byta ut färgtabellen på en bild med värden på mitt val . 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 att ett svar som antyder ett verktyg bättre lämpad för uppgiften .
Fråga inte folk att svara med privat e – post

Hackare tror lösa problem bör vara en allmän , öppen process under vilken ett första försök på ett svar kan och bör rättas till om någon mer kunniga märker att den är ofullständig eller felaktig . Även medhjälpare få 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 det här . Det är respondentens val om du vill svara privat – och om han gör det , är det oftast för att han tycker att frågan är för sjuk – formade eller uppenbar för att vara intressant för andra.

Det finns ett begränsat undantag från denna regel. Om du tror att frågan är så 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 den 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 öppen tids sänkor . Dessa människor mest sannolikt att kunna ge dig ett användbart svar är också de mest upptagna människor ( om bara för att de tar på de mest arbetar själva) . Folk gillar det är allergiska mot tillsvidaretidssänkor , vilket de brukar vara allergisk mot öppna frågor .

Du är mer sannolikt att få ett bra svar om du är tydlig om vad du vill att de svarande att göra ( ge pekare , skicka koden , kontrollera din lapp , vad som helst ) . Detta kommer att fokusera sina ansträngningar och implicit sätta en övre gräns för den tid och energi som en respondent 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 du implicit be om , desto mer sannolikt är det att få ett svar från någon riktigt bra och verkligen upptagen .

Så det är bra att rama in din fråga för att minimera den tid engagemang som krävs för att en expert för att sätta in den – men det är oftast inte samma sak som att förenkla frågan . Således , till exempel, “ Kan du ge mig en pekare till en bra förklaring av X ? “ Är oftast en smartare fråga än “ Kan du förklara X , snälla ? “ . Om du har lite dåligt fungerande kod , är det oftast smartare att be någon att förklara vad som är fel med det än vad det är att be någon att fixa det .
När man frågar kod

Be inte andra att felsöka din trasiga kod utan att ge en antydan vilken typ av problem de ska leta efter . Posta några hundra rader kod , säger “ det fungerar inte “ , kommer att få dig ignoreras . Posta ett dussin rader kod , säger “ efter linjen 7 Jag hade förväntat mig att se , men inträffade istället “ är mycket mer benägna att ge dig ett svar .

Det mest effektiva sättet att vara exakt en kod problem är att ge en minimal bugg – visar testfall . Vad är en minimal testfall ? Det är en illustration av problemet, precis tillräckligt kod för att uppvisa den icke önskvärda 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 lagom stödjande kod för att producera en komplett exempel ( dvs. nog att källan är godtagbar för kompilator / tolk / vad programmet bearbetar det ) . Om du inte kan begränsa den till en viss del , gör en kopia av käll och börja ta bort bitar som inte påverkar det problematiska beteendet . Ju mindre din minimala testfall är , desto bättre ( se avsnittet “ Volym är inte precision “ ) .

Generera en riktigt liten minimal testfall är inte alltid möjligt , men att försöka är god 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 provat . Det kommer att göra dem mer samarbetsvillig .

Om du bara vill ha en kodgranskning , säger så mycket på framsidan, och var noga med att tala om vilka områden som du tror kan särskilt behöva ö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 råd , men inte för hela lösningar .

Om du misstänker att du har klarat en läxa fråga , men kan inte lösa det ändå , försök att fråga i en användargrupp forum eller ( som sista utväg ) i en “ användare “ lista / forum för ett projekt . Medan hackare kommer att upptäcka det , kan en del av de avancerade användarna åtminstonege dig en ledtråd .
Beskära onödiga förfrågningar

Motstå frestelsen att avsluta 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 din problembeskrivning halvvägs kompetent , sådan uppsatt – på frågorna är på bäst överflödig. För det andra : för att de är överflödiga , hackare hitta dem irriterande – och kommer sannolikt att återvända logiskt oklanderlig 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 för att undvika om du vill ha 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 kontraproduktivt : de flesta hackare kommer att 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 . Dessutom utlöser ordet “ Brådskande “ ( och andra liknande försök att fånga uppmärksamheten i ämnesraden ) ofta spamfilter – din avsedda mottagare kan aldrig se det alls !

Det är en semi- undantag. Det kan vara värt att nämna om du använder programmet i någon hög profil plats , en som hackare kommer att bli upphetsad över , i så fall , om du är under tidspress , och du säger så artigt , folk kan få tillräckligt intresserade för att svara snabbare .

Detta är en mycket riskabel sak att göra , men eftersom hackare “ mått för vad som är spännande skiljer sig troligen från din. Skriv från den internationella rymdstationen skulle kvalificera sig , till exempel, men att publicera på uppdrag av en må-bra välgörenhet eller politisk orsak skulle nästan säkert inte . Faktum är att publicera “ Brådskande : Hjälp mig rädda luddiga sälungar “ kommer säkert att få dig skytt eller flammade även av hackare som tror fuzzy sälungar är viktiga .

Om du hittar denna mystiska , åter läsa resten av detta hur – till flera gånger tills du förstår den innan du postar något alls .

Artighet skadar aldrig , och ibland hjälper

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

För att vara ärlig , är det inte lika viktigt som ( och kan inte ersätta ) är grammatisk , klara , precisa och beskrivande , undvika proprietära format etc. hackare i allmänhet hellre få något brysk men tekniskt skarpa felrapporter än artigt vaghet . ( Om detta pussel dig , kom ihåg att vi värdesätter en fråga av 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 allvarliga invändning som 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 det betecknar en avsikt att inte tacka någon efteråt . Vår rekommendation är att antingen säga “ Tack på förhand “ först och tacka respondenterna 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 anteckning om 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 rönt allmänt intresse i en e-postlista eller diskussionsgrupp , är det lämpligt att lägga på uppföljning där.

Optimalt ska svaret vara att tråden startades av den ursprungliga frågan utstationering , och bör ha “ FAST „, “ SATT “ eller en lika självklar tag 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 ( om inte ( 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 inblandade , ett enkelt “ Howdy – det var en misslyckad nätverkskabel ! Tack , alla. – Bill “ skulle vara bättre än ingenting . I själva verket är en 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.

Vid problem med lite djup , är det lämpligt att lägga in 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 ska komma efter den rätta lösningen och andra sammanfattande material , snarare än att vända uppföljningen i en deckare . Namnge namn på personer som hjälpt dig , du kommer att få vänner på det sättet .

Förutom att vara tillmötesgående och informativ , kommer denna typ av uppföljning hjälpa andra att söka i arkiv mailing-list/newsgroup/forum att veta exakt vilken lösning hjälpte 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 för gurus och experter som du tryckt på för att få hjälp . Problem berättelser som Trail Off i olösta intighet är frustrerande saker , hackare kliar att se dem löst . Den goodwill som skrapa som kliar tjänar du kommer att vara mycket , mycket hjälp för dig nästa gång du behöver för att ställa en fråga .

Fundera på hur du skulle kunna förhindra att andra har 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 den ansvarige .

Bland hackare , är denna typ av god uppföljning beteende faktiskt viktigare än vanlig artighet . Det är hur du får ett rykte om att spela bra med andra , vilket kan vara en mycket värdefull tillgång .
Hur man ska tolka svar
RTFM och STFW : Så identifierar du har allvarligt skruvas upp

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

RTFM har en yngre släkting . Om du får ett svar som lyder “ STFW “ , den person som skickade det 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 Web forum , kan du också få veta att söka forumet arkiven . I själva verket kan någon till och med vara så vänlig att ge en pekare till den tidigare tråden där problemet var löst . Men lita inte på denna ersättning, göra ditt arkiv – sökning innan du frågar .

Ofta den som talar om för dig att göra en sökning har manualen eller webbsidan med den information du behöver öppna och tittar på det som han eller hon typer . Dessa svar betyder att han tycker ( a ) den information du behöver är lätt att hitta , och ( b ) kommer du att lära dig mer om du söker upp den information än om du har det matade med sked till dig .

Du ska inte bli kränkt av detta , genom hacker standarder , är din respondenten visar dig en grov slags respekt genom att helt enkelt inte ignorera dig . Du bör i stä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 begäran om förtydligande . Använd samma verktyg som du använde för att försöka svara på din ursprungliga fråga ( manualer , FAQs , webben , duktiga vänner ) för att förstå svaret . Sedan, om du fortfarande behöver be om klargöranden , ställa ut det du har lärt dig .

Anta till exempel att jag säger : “ 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 : Här är en bra uppföljning fråga : “ “ Vad är en zentry ? “ OK , jag läste manualsidan och zentries nämns bara under – z och – p växlar . Ingen av dem säger något om att rensa zentries . Är det någon av dessa eller har jag missat något här ? “

Hantering av råhet

Mycket av det som ser ut som ohövlighet i hacker- kretsar är inte avsedd att väcka anstöt . Snarare är det en produkt av den direkta , cut – through-the – skitsnack kommunikationsstilsom är naturligt för människor som är mer bekymrade om att lösa problem än att göra andra känner 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 nyhetsgrupp eller forum kommer att kalla honom eller henne på det . Om det inte sker , och du tappar humöret , är det troligt att den person du förlorar det på betedde inom hacker samhällets 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 poserande som är ganska meningslöst . The flip- sidan av ovanstående är att det är acceptabel form till 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å sin mark innan du försöker detta , dock . Gränsen mellan att korrigera en incivility 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 utomstående , dina chanser att undvika en sådan blunder är låga . Om du 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 en del av hjärnan kretsar som smörjer “ normal “ mänsklig social interaktion . Detta kan eller kan inte vara sant . Om du inte är en hacker själv . . , kan det hjälpa dig att klara av våra egenheter , om du tänker på oss som hjärnskadade Gå höger framåt vi inte kommer att bry sig , vi gillar att vara vad det är vi är , och har i allmänhet en sund skepsis om kliniska etiketter ) .

I nästa avsnitt kommer vi att tala om en annan fråga , den typ av “ råhet “ du ser när du missköter sig .
På inte reagera som en förlorare

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

När detta händer , är det värsta du kan göra gnälla om upplevelsen , säger sig ha blivit verbalt misshandlade , efterfrågan ursäkter , skrika , håll andan , hotar stämningar , klaga till människors arbetsgivare , lämna toalettsitsen upp , etc. Istället här är vad du gör :

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

Gemenskapsnormer inte hålla sig : De är underhålls av människor att aktivt tillämpa dem , synligt , offentligt. Inte gnälla att all kritik borde ha förmedlat via privat e – post : Det är inte hur det fungerar . Inte heller är det lämpligt att kräva att du har blivit personligen förolämpad när någon säger att en av dina påståenden var fel , eller att hans åsikter skiljer sig åt . De är förlorare attityder .

Det har varit hacker forum där , av någon missriktad känsla av hyper artighet , är deltagare förbjudna från att publicera någon felsökning med varandras inlägg , och berättade “ Säg inget om du är ovillig att hjälpa användaren . “ Den resulte avgång klipska deltagare på andra håll får dem att sjunka in i meningslösa babbel och blir oanvändbara som tekniska forum .

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

Kom ihåg : När som hacker säger att du har skruvas upp , och ( oavsett hur gruffly ) säger åt dig 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 , åtminstoneha lite värdighet , inte gnälla , och förvänta dig inte att bli behandlad 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 folk kommer att attackera dig personligen , flamma utan en uppenbar anledning , etc. , även om du inte skruva upp ( eller har bara skruvas upp i sin fantasi ) . I detta fall är klagar vägen att verkligen skruva upp .

Dessa flamers är antingen Lamers som inte har en aning om , men anser sig vara experter , eller blivande psykologer att testa att du kommer att skruva upp . De andra läsare antingen ignorera 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 vilka hackers 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 prompt ?
F: Kan jag konvertera en AcmeCorp dokument till en TeX -fil med hjälp av bas – o-matic -fil omvandlare?
F: Min { program , konfiguration , SQL-uttryck } fungerar inte
Fråga: Jag har problem med min Windows- maskin . Kan du hjälpa till ?
Fråga: Mitt program fungerar inte . Jag tror att systemet anläggning X är trasig .
Fråga: Jag har problem med att installera Linux eller X. Kan du hjälpa till ?
Fråga: Hur kan jag knäcka rot / stjäla kanal – ops privilegier / läsa någons e – post ?

F:

Var kan jag hitta program eller resurs X ?

A :

Samma ställe jag skulle hitta den , idiot – 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 det du vill är att göra Y , ska du ställa den frågan utan att i förväg anta att använda en metod som inte kan vara lämpliga . Frågor av denna form visar ofta en person som inte bara okunniga om X , men förvirrad om vad problemet Y de är lösa och för fixerade på detaljerna i deras särskilda situation . Det är i allmänhet bäst att ignorera dessa människor tills de definierar sina problem bättre .

F:

Hur konfigurerar jag mitt skal prompt ?

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 hjälp av 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 { program , 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åga ur dig – jag har bättre saker att göra . Den ser ut ungefär så här , är min reaktion normalt av något av följande :

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

åh, det är synd , jag hoppas du får det åtgärdat .

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

F:

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

A :

Ja. Kasta ut att Microsoft skräp och installera ett open-source operativsystem som Linux eller BSD .

Obs : Du kan ställa frågor som rör 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 överraskad av svaret att problemet är med Windows och inte programmet , eftersom Windows är så trasig i allmänhet att det är mycket ofta fallet .

F:

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

A :

Även om det är möjligt att du är den första personen att märka en uppenbar brist i systemanrop och bibliotek kraftigt används av hundratals eller tusentals människor , är det snarare mer troligt att du är helt clueless . Extraordinära påståenden kräver extraordinära bevis, när du gör ett påstående som denna , 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 . Gå be din lokala Linuxanvändargrupp för praktisk hjälp. ( Du kan hitta en lista på 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 att distro , eller på lokala användargrupperforum . I det här fallet , se till att beskriva de exakta detaljerna i misslyckandet . Men gör noggrann sökning först , med “ linux “ och alla misstänkta bitar av hårdvara .

F:

Hur kan jag knäcka rot / stjäla kanal – ops privilegier / läsa någons e – post ?

A :

Du är ett avskum 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 att ställa frågor på ett smart sätt genom exempel , par frågor om samma problem , frågade på ett dumt sätt och en på ett smart sätt .

Umh : Var kan jag få reda på saker om Foonly Flurbamatic ?

Denna fråga bara tigger om “ STFW “ som svar .
Glx : Jag använde Google för att försöka hitta “ Foonly Flurbamatic 2600 “ på webben , men jag fick några användbara träffar . Kan jag få en pekare till information programmering på den här enheten ?

Detta har redan STFWed , och låter som han kan ha ett verkligt problem .

Umx : Jag kan inte få koden från projekt foo att sammanställa . Varför är det trasigt ?

Querent förutsätter att någon annan skruvas upp . Arrogant git …
Glx : Koden från projekt foo inte kompilera i 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 ?

Querent har specificerat miljön , läs FAQ , visar felet , och inte antar hans problem är någon annans fel . Detta kan vara värt lite uppmärksamhet .

Umx: Jag har problem med mitt moderkort . Kan någon hjälpa ?

J. Random Hacker svar på detta kommer sannolikt att vara “ höger . Behöver du rapning och blöjbyte , också? “ Följt av ett slag på Delete-tangenten .
Glx: 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 om fler tester jag kan köra för att sätta fingret på problemet ?

Denna person , å andra sidan verkar värdig ett svar. Han / hon har ställt ut problemlösning intelligens i stället för att passivt vänta på svar att falla 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 vad ytterligare diagnostik jag kan köra för att nå upplysning. “

I själva verket är den form av den sista frågan är nära baserad på en verklig händelse som hände i augusti 2001 på sändlistan linux – kernel ( lkml ) . Jag ( Eric ) var den som ställer frågan då. Jag såg mystiska låsningar på ett Tyan S2462 moderkort . På listan levererade den kritiska information som 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 med att berätta dem de återvändsgränder som jag hade redan köra ner .

Efteråt , när jag tackade alla och påpekade hur väl processen hade fungerat , observerat en lkml ledamot att han trodde att det hade fungerat inte för att jag är ett “ 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 jag skulle ha flammat eller ignoreras oavsett vem jag var . Hans förslag som jag skriver upp hela incidenten 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 den frågade gruppen kan helt enkelt inte vet svaret . Inget svar är inte samma sak som ignoreras , men visserligen är det svårt att se skillnaden från utsidan .

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

Det finns andra källor för hjälp du kan 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 sluta avtal med för att få hjälp , både stora och små . Bli inte förfärad vid tanken på att behöva betala för lite hjälp ! Trots allt, om din bilmotor 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 kosta dig något , kan du inte räkna med att stödet för 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 stöd för program med sluten 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 få människor att verka oförskämd eller dum även när de inte är.

Svara på ett 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 där FAQ lagras eller publiceras .

Om du inte vet säkert , säger så ! Ett fel men auktoritativa klingande svar är värre än ingen alls . Rikta 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 . Gör inte skämt om förfaranden som kan kasserar användarens inställning – den stackars SAP tolkar dessa instruktioner .

Ställ utforskande frågor för att få fram mer information . Om du är bra på det här , kommer querent lära sig något – och så kanske du . Försök att vända den dåliga frågan till en bra en , kom ihåg att vi var alla nybörjare en gång .

Medan muttrade RTFM ibland motiverat när du svarar på någon som är bara en lat slusk , en pekare till dokumentation ( även om det bara är 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 föreslå kludgy lösningar när någon använder fel verktyg eller förhållningssätt . Föreslå bra verktyg . Reframe uteslutet.

Svara på själva frågan ! Om frågeställaren har varit så noggrann som att göra sin forskning och har i den fråga som X , Y , Z , A , B och C har redan försökt utan gott resultat , är det ytterst föga hjälp 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är sig från frågan . När du fältet en bra fråga , fråga dig själv “ Hur skulle sådana handlingar och FAQ måste ändra så att ingen har att svara på det här igen ? “ Då skickar en lapp till dokumentet ansvariga.

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

Relaterade resurser

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

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

Erkännanden

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

Comments are closed.