Hvordan til at spørge Smart måde

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


Eric Steven Raymond
Rick Moen
Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen
Revisionsoversigten
Revision 3.10 21 kan 2014 esr
Ny sektion Stack Overflow.
Revision 3.9 23 Apr 2013 esr
URL fixes.
Revision 3.8 19 Jun 2012 esr
URL fix.
Revision 3.7 06 Dec 2010 esr
Helpful hints for ESL speakers.
Revision 3.7 02 Nov 2010 esr
Flere oversættelser er forsvundet.
Revision 3.6 19 Mar 2008 esr
Mindre opdatering og nye links.
Revision 3.5 2 Jan 2008 esr
Typo fix og nogle oversættelse links.
Revision 3.4 24 Mar 2007 esr
Nye afsnit, “når du beder om koden”.
Revision 3.3 29 Sep 2006 esr
Foldet i et godt forslag fra Kai Niggemann.
Revision 3.2 10 Jan 2006 esr
Foldet i redigeringer fra Rick Moen.
Revision 3.1 28 Oct 2004 esr
Dokumentere «Google er din ven!
Revision 3.0 2 Feb 2004 esr
Store tilsætning af ting om korrekt etikette Webfora.
Indholdsfortegnelse

Ansvarsfraskrivelse

Ansvarsfraskrivelse
Mange projekt hjemmesider link til dette dokument i deres afsnit om hvordan man får hjælp. Det er fint, det er vi skal anvendes men hvis du er en webmaster at skabe sådan et link til dit projekt, kan du vise fremtrædende nær link varsel at vi ikke er en helpdesk til dit projekt!
Vi har lært den skrap måde, uden forudgående varsel, vi vil gentagne gange være generet af idioter, der mener at have offentliggjort dette dokument gør det vores opgave at løse alle verdens tekniske problemer.
Hvis du læser dette dokument, fordi du har brug for hjælp, og du væk med det indtryk, du kan det direkte fra forfatterne af dette dokument, er du en af de idioter, vi taler om. Ikke stille os spørgsmål. Vi vil bare ignorere dig. Vi er her for at vise dig, hvordan du får hjælp fra folk, der rent faktisk ved om software eller hardware du beskæftiger sig med, men 99,9% af tiden, der ikke vil være os. Medmindre du ved med sikkerhed, at en af forfatterne er ekspert i hvad du har at gøre med, lad os alene og alle vil være lykkeligere.
Introduktion
I en verden af hackere afhænger slags svar, du får dine tekniske spørgsmål meget den måde du stille spørgsmålene som om er vanskeligheden at udvikle svaret. Denne guide vil lære dig hvordan man kan stille spørgsmål en måde, der er mere tilbøjelige til at dig et tilfredsstillende svar.
Nu, hvor brugen af open source er blevet udbredt, kan du ofte som gode svar fra andre, mere erfarne brugere fra hackere. Det er en god ting; brugere har tendens til at være bare en lille smule mere tolerante over for slags fejl nybegyndere har ofte. Stadig, behandling af erfarne brugere som hackere i måder vi anbefaler her vil generelt være den mest effektive måde at nyttige svar ud af dem, også.
Den første ting at forstå er, at hackere faktisk som hårde problemer og gode, tankevækkende spørgsmål om dem. Hvis vi ikke gjorde det, ville ikke vi være her. Hvis du giver os et interessant spørgsmål at tygge, vil vi være taknemmelige for dig; gode spørgsmål er et incitament og en gave. Gode spørgsmål hjælpe os med at udvikle vores forståelse, og ofte afsløre problemer vi ikke måske har bemærket eller tænkte ellers. Blandt hackere er “Godt spørgsmål!” en stærk og oprigtig kompliment.
Trods dette har hackere ry for at møde enkle spørgsmål med hvad der ligner fjendtlighed eller arrogance. Det ligner sommetider vi refleksivt uhøfligt at nybegyndere og de uvidende. Men er det ikke virkelig sandt.
Hvad vi er, unapologetically, er fjendtligt indstillet over for folk, der synes at være uvillig til at tænke eller til at gøre deres eget hjemmearbejde før du stiller spørgsmål. Mennesker som der er tid dræn de tager uden at give tilbage, og de spilder tid, vi kunne have brugt endnu et spørgsmål mere interessante og en anden person mere værdig af et svar. Vi kalder mennesker som denne “tabere” (og af historiske grunde vi undertiden stave det “lusers”).
Vi indser at der er mange mennesker, der bare ønsker at bruge den software, vi skriver, og der har ingen interesse i at lære tekniske detaljer. For de fleste mennesker er en computer blot et redskab, et middel til ophør; de har vigtigere ting at gøre og liv at leve. Vi anerkender, at, og forventer ikke alle til at tage en interesse i de tekniske spørgsmål, der fascinerer os. Ikke desto mindre er vores stil af besvare spørgsmål tunet til mennesker, der tager en saadan interesse og er villige til at være aktive deltagere i problemløsning. Det kommer ikke til at ændre. Heller ikke bør det; Hvis det gjorde, ville vi blive mindre effektiv til de ting vi gør bedst.
Vi er (stort set) frivillige. Vi tage tid ud af travle liv til at besvare spørgsmål, og til tider vi er overvældet med dem. filtrerer vi hensynsløst. Navnlig, smider vi væk spørgsmål fra folk, der synes at være tabere for at bruge vores spørgsmål-besvarelse tid mere effektivt vinderne.
Hvis du finder denne holdning ubehagelig, nedladende og arrogant, tjekke dine antagelser. Vi spørger ikke dig til at erstatningsløsning os i virkeligheden, de fleste af os ville elske andet end at behandle dig som en ligeværdig og byder dig velkommen i vores kultur, hvis du lægger i den indsats, der kræves til at gøre dette muligt. Men det er simpelthen ikke effektive for os at forsøge at hjælpe mennesker, der ikke er villige til at hjælpe sig selv. Det er OK at være uvidende; Det er ikke OK at spille dum.
mens det er ikke nødvendigt at allerede være teknisk kompetent til at opmærksomhed fra os, det er nødvendigt at påvise slags attitude, der fører til kompetencealert, tankevækkende, opmærksomme, villig til at være en aktiv partner i at udvikle en løsning. Hvis du ikke kan leve med denne form for forskelsbehandling, foreslår vi, at du betale nogen for en kommerciel supportkontrakt i stedet for at spørge hackere at personligt donere hjælp for dig.
Hvis du beslutter dig at komme til os for at få hjælp, vil du ikke være blandt taberne. Du ønsker ikke at ligne en, enten. Den bedste måde at en hurtig og responsiv svar er at spørge det som en person med kløgt, tillid og spor, der bare tilfældigvis har brug for hjælp et særligt problem.
(Forbedringer til denne guide er velkomne. Du kan sende forslag til [email protected] eller [email protected]. Bemærk dog at dette dokument ikke er ment som en generel vejledning til netikette, og vi vil generelt forkaste forslag, der ikke specifikt relateret til at fremkalde nyttige svar i en teknisk forum.)
Før du spørger
Før du stiller et teknisk spørgsmål via e-mail, eller i en nyhedsgruppe eller en hjemmeside chat board, skal du gøre følgende:
  1. Prøv at finde et svar ved at søge i forum eller mailing liste du planlægger at sende til arkiv.
  2. Prøv at finde et svar ved at søge nettet.
  3. Prøv at finde et svar ved at læse manualen.
  4. Prøv at finde et svar ved at læse en FAQ.
  5. Prøv at finde et svar ved inspektion eller eksperimenter.
  6. Prøv at finde et svar ved at spørge en dygtig ven.
  7. Hvis du er en programmør, forsøge at finde svar ved at læse den kildekode.

Når du spørger dine spørgsmål, vise det faktum, at du har gjort disse ting først; Dette vil bidrage til at du ikke bliver en doven svamp og spilder folks tid. Endnu bedre, få vist, hvad du har lært fra at gøre disse ting. Vi vil besvare spørgsmål for folk, der har vist de kan lære af svarene.

Brug taktik som laver en Google søgning tekst af uanset hvilken fejlmeddelelse du får (søgning Google grupper samt websider). Dette kan godt tage dig direkte til lave dokumentation eller en postliste tråd besvare dit spørgsmål. Selv om det ikke, siger “Jeg googled følgende sætning, men ikke noget der kiggede lovende er en god ting at gøre i en e-mail eller nyheder bogføringer anmoder om hjælp, hvis kun fordi det registrerer, hvad søgninger vil ikke hjælpe. Det vil også bidrage til direkte andre folk med lignende problemer at din tråd ved at sammenkæde søgetermer hvad vil forhåbentlig være dit problem og opløsning tråd.
Tag dig tid. Forvent ikke at kunne løse et kompliceret problem med et par sekunder googling. Læse og forstå FAQ, læne sig tilbage, slappe af og overveje problemet før nærmer eksperter. Stoleos, de vil kunne fortælle fra dine spørgsmål hvor meget læsning og tænker du gjorde, og vil være mere villige til at hjælpe, hvis du kommer forberedt. Ikke straks ild din helt arsenal af spørgsmål, bare fordi din første søgning dukkede op ingen svar (eller for mange).
Forbered dit spørgsmål. Tænke det igennem. Jannies-klingende spørgsmål forhastet svar, eller ingen overhovedet. Jo mere gør du for at demonstrere, at have sat tanke og kræfter i at løse dit problem før de søger hjælp, jo mere sandsynligt er du rent faktisk at hjælp.
Pas at stille de forkerte spørgsmål. Hvis du spørger en, der er baseret fejlagtige antagelser, er J. tilfældige Hacker meget sandsynligt at svare med en unødigt bogstavelig svaret mens tænkning “dumt spørgsmål…”, og håber oplevelsen af at få, hvad du bad om i stedet for hvad du behov vil lære dig en lærestreg.
Aldrig antage, du har ret til et svar. Du er ikke; du betaler ikke, trods alt for servicen. Du vil tjene et svar, hvis du tjener det, ved at spørge en betydelig, interessant og tankevækkende spørgsmål som implicit bidrager til oplevelsen af Fællesskabet snarere end blot passivt krævende viden fra andre.
den anden side gør det klart at du er i stand og villige til at hjælpe ved at udvikle løsningen er en meget god start. “Vil nogen give en pointer?”, “Hvad er mit eksempel mangler?”, og “hvad websted bør jeg har tjekket?” er mere tilbøjelige til at besvaret end “Please post den nøjagtige procedure jeg skal brug.” fordi du gør det klart, at du virkelig villig til at fuldføre processen, hvis nogen kan bare pege dig i den rigtige retning.
 
Når du spørger
Vælg din forum omhyggeligt
Være følsomme i at vælge, hvor du stille dit spørgsmål. Du er tilbøjelige til at blive ignoreret, eller afskrevet som en taber, hvis du:
  • Send dine spørgsmål til et forum, hvor det er off topic
  • sende en meget elementære spørgsmål til et forum, hvor avancerede tekniske spørgsmål forventes, eller omvendt
  • Cross-post til for mange forskellige nyhedsgrupper
  • bogføre en personlig e-mail til en person, der er hverken en bekendt i jeres heller ikke personligt ansvarlig for at løse dit problem

Hackere blæse spørgsmål, der er uretmæssigt målrettet for at forsøge at beskytte deres kommunikationskanaler fra at blive druknet i irrelevans. Du ønsker ikke dette til at ske for dig.

Det første skridt er derfor at finde det rigtige forum. Igen, Google og andre metoder til søgningnettet er din ven. Brug dem til at finde websiden projekt mest tæt knyttet til hardware eller software giver dig problemer. Det har normalt links til en FAQ (Frequently Asked Questions) liste, og projektet postlister og deres arkiver. Disse postlister er de endelige steder at for at få hjælp, hvis din egen indsats (herunder læse de ofte stillede spørgsmål du fundet) ikke finder du en løsning. Projektside kan også beskrive en fejl-rapportering procedure, eller har et link til en; Hvis det er tilfældet, Følg det.
Skydning off en e-mail til en person eller et forum, som du ikke er bekendt med er risikabelt i bedste fald. For eksempel, ikke antage, at forfatteren af en informativ webside ønsker at være din gratis konsulent. Gør ikke optimistisk gæt om, hvorvidt dit spørgsmål vil være velkommen hvis du er usikker, sende det andre steder, eller afstå fra at sende det alle.
Når du vælger en Webforum, nyhedsgruppe eller mailing liste, ikke har tillid til navnet i sig selv for langt; kigge efter en FAQ eller charter til at kontrollere dit spørgsmål er om emnet. Læs nogle af de back trafik før udstationering du får en fornemmelse for hvordan tingene gøres der. I virkeligheden, er det en meget god idé at lave et søgeordssøgning efter ord vedrørende dit problem de nyhedsgruppe eller postliste arkiv, før du bogfører. Det kan finde du et svar, og hvis ikke det vil hjælpe dig formulere et bedre spørgsmål.
Ikke shotgun-blast alle tilgængelige hjælpkanaler én gang, det er ligesom råben og irriterer folk. gennem dem sagte.
Vide, hvad dit emne er! En af de klassiske fejl er at stille spørgsmål om Unix eller Windows programmerer grænseflade i et forum helliget et sprog eller bibliotek eller værktøj bærbare på tværs af begge. Hvis du ikke forstår hvorfor det er en fejltagelse, du ville være bedst ikke stille nogen spørgsmål alle indtil du får det.
Generelt er spørgsmål til en udvalgte offentlige forum mere tilbøjelige til at nyttige svar end tilsvarende spørgsmål til en privat. Der er flere grunde til dette. Et er simpelthen størrelsen af puljen af potentielle respondenter. En anden er størrelsen af publikum; hackere ville snarere besvare spørgsmål, der uddanner mange mennesker end spørgsmål tjener kun et par.
Forståeligt nok, dygtige hackere og forfattere i populær programmel allerede modtager mere end deres rimelige andel af mis målrettede meddelelser. Ved at tilføje til strømmen, kan du i ekstreme tilfælde endda være dråben, der bryder kamelens ryg helt et par gange, bidragydere til populære projekter har trukket deres støtte, fordi kollaterale skader i form af ubrugelige e-mail trafik til deres personlige konti blev uudholdeligt.
Stakoverløb
Søg, spørg stakken Exchange
I de seneste år, Fællesskabets stak udveksling af websteder har vist sig som en stor ressource for at besvare tekniske spørgsmål og er selv det foretrukne forum for mange open source projekter.
Start med en Google søgning før du ser stakken udveksling; Google indekserer det i realtid. Der er en meget god chance, nogen har allerede stillet et lignende spørgsmål, og stak udveksling steder er ofte nær toppen af søgeresultaterne. Hvis du ikke kan finde noget via Google, søge igen det specifikke websted, der er mest relevante for din forespørgsel (se nedenfor). Søgning med tags kan hjælpe med at indsnævre resultaterne.
Hvis du stadig ikke finde noget, skal du lægge dit spørgsmål den ene site hvor det er mest på-topic. Brug formateringsværktøjerne, især for kode, og tilføje tags, der er relateret til indholdet af din forespørgsel (især navn af programmeringssprog, operativsystem eller bibliotek du har problemer med). Hvis en commenter beder om mere information, redigere din vigtigste indlæg for at medtage den. Hvis nogen svar er nyttigt, skal du klikke på pil op for at upvote det; Hvis et svar giver en løsning dit problem, skal du klikke på checken under afstemningen pilene til at acceptere det som korrekte.
Stak Exchange er vokset til over 100 sites, men her er de mest sandsynlige kandidater:
  • Super User er for spørgsmål om generelle formål computing. Hvis dine spørgsmål handler ikke om kode eller programmer, som du taler med kun over en netværksforbindelse, går det sandsynligvis her.
  • Stakoverløb er for spørgsmål om programmering.
  • Server fejl er for spørgsmål om server og netværksadministration.
Flere projekter har deres egne specifikke websteder, herunder Android, Ubuntu, TeX/LaTeX og SharePoint. Tjekke webstedet stak Exchange en opdateret liste.
Web, og IRC fora
Din lokale brugergruppe eller din Linuxdistribution, kan annoncere en webforum eller IRC kanal hvor nybegyndere kan hjælp. (I ikke-engelsktalende lande newbie fora er stadig mere tilbøjelige til at være adresselister.) Disse er gode første steder at bede, især hvis du tror du kan have udløst over et relativt simpelt eller fælles problem. En annoncerede IRC kanal er en åben invitation til at stille spørgsmål der og ofte svar i realtid.
I virkeligheden, hvis du fik det program, der giver dig problemer fra en Linuxdistribution (som er almindelig i dag), kan det være bedre at spørge i distro’s forum/liste før du prøver det program projekt forum/liste. Projektets hackere kan bare sige, “bruge vores bygge”.
Før du sender til en Webforum, tjekke hvis det har en søgefunktion. Hvis det gør, kan du prøve et par søgeordssøgninger for noget som dit problem; Det kan bare hjælpe. Hvis du har en generel websøgning før (som du bør have), søge i forumet alligevel; din Web-dækkende søgemaskine kan ikke have alle dette forum indekseret for nylig.
Der er en stigende tendens for projekter at gøre brugerstøtte over en webforum eller IRC kanal, med e-mail mere forbeholdt udvikling trafik. se efter disse kanaler første når de søger projekt-specifikke hjælp.
Som et andet trin, bruge projektet postlister
Når et projekt har en udvikling postliste, skrive til postlisten, ikke til individuelle udviklere, selv hvis du tror, du ved, hvem der bedst kan besvare dit spørgsmål. Dokumentationen af projektet og dets hjemmeside adressen i en projektets postlister, og bruge den. Der er flere gode grunde til denne politik:
  • Spørgsmål godt nok at blive spurgt af en udvikler vil også være af værdi for hele gruppen. Omvendt, hvis du har mistanke om dit spørgsmål er for dum til en postliste, det er ikke en undskyldning for at chikanere individuelle udviklere.
  • Stille spørgsmål listen fordeler belastningen blandt udviklere. Den individuelle udvikler (især hvis han er projektlederen) kan være for optaget til at svaredine spørgsmål.
  • De fleste postlister er arkiveret og arkiverne er indekseret af søgemaskiner. Hvis du spørger dine spørgsmål på listen, og det er besvaret kunne en fremtidig querent finde dit spørgsmål og svaret nettet i stedet for at bede om det igen.
Hvis visse spørgsmål er set stilles ofte, kan udviklere bruge disse oplysninger til at forbedre dokumentationen eller selve softwaren til at være mindre forvirrende. Men hvis disse spørgsmål bliver bedt om i private, ingen har den komplette billede af hvilke spørgsmål er stillet oftest.
Hvis et projekt har både en “bruger” og “forfatter” (eller “hacker”) postliste eller Webforum, og du ikke banalisere koden, Spørg i “bruger” liste/forum. ikke antage, at du vil være velkommen listen udvikler, hvor de er tilbøjelige til at opleve dit spørgsmål som støj forstyrre deres udvikler trafik.
Men hvis du er sikker på dit spørgsmål er ikke-triviel, og du får ingen svar i den “bruger” liste/forum i flere dage, prøv “forfatter”, en. Du ville være klogt at lure der for et par dage mindst gennemgå de sidste par dage af arkiverede meddelelser, at lære de lokale folkways før bogføring (faktisk er det gode råd om eventuelle private eller semi-private liste).
Hvis du ikke kan finde et projekt postliste adresse, men kun se adressen vedligeholderen af projektet, videre og skrive til vedligeholderen. Men selv ikke i dette tilfælde antager at postlisten ikke eksisterer. Nævner i din e-mail, at du prøvede og kunne ikke finde postlisten passende. Også nævne, at du ikke noget imod at have meddelelsen sendt til andre mennesker. (Mange mennesker tror, at private e-mail bør forblive private, selv om der ikke er noget hemmeligt i det. Ved at lade din meddelelse sendes give du din korrespondent et valg om, hvordan du håndterer dine e-mails.)
Brug meningsfulde, specifikke emne overskrifter
postlister, nyhedsgrupper eller Webfora er emneheaderen din gyldne mulighed for at tiltrække kvalificerede eksperter opmærksomhed i omkring 50 tegn eller færre. Spilder ikke det på plapre som “Behage hjælp mig” (endsige “PLEASE hjælp mig!!!”; meddelelser med emner som at få kasseret af refleks). Fors¯g ikke at imponere os med dybden af din angst; i stedet bruge pladsen for en super-præcise problembeskrivelse.
En god konvention om emnet overskrifter, bruges af mange tech støtte organisationer, er “objekt afvigelse”. “Objekt” del angiver hvilke ting eller gruppe af ting er at have et problem, og den “afvigelse” del beskriver afvigelsen fra forventede funktionsmåde.
Dum:
Hjælp! Video fungerer ikke korrekt min laptop!
Smart:
X.org 6.8.1 deform musemarkøren, Fooware MV1005 vid. chipset
Smartere:
X.org 6.8.1 musemarkøren Fooware MV1005 vid. chipset er misdannet
Processen med at skrive en “objekt-afvigelse” beskrivelse vil hjælpe dig med at organisere dine tanker om problemet mere detaljeret. Hvad er berørt? Blot musemarkøren eller anden grafik også? Er dette bestemt til X.org version af X? Til version 6.8.1? Er det specifikt for Fooware video chipsæt? Model MV1005? En hacker, der ser resultatet kan straks forstå, hvad det er, at du har et problem med, og det problem, du har, et øjeblik.
Mere generelt, Forestil dig at kigge indekset for et arkiv af spørgsmål, med bare emnelinjer viser. Gøre din emnelinjen, afspejler dit spørgsmål godt nok, at den næste person søgning arkiv med en lignende til dit spørgsmål vil være i stand til at følge tråden til et svar i stedet for at bogføre spørgsmålet igen.
Hvis du stiller et spørgsmål i et svar, skal du ændre emnelinjen for at indikere, at du spørger et spørgsmål. En emnelinje, der ligner “Re: test eller “Re: ny fejl er mindre tilbøjelige til at tiltrække nyttige mængder af opmærksomhed. Også, pare citat af tidligere meddelelser til det minimum, der er i overensstemmelse med cluing i nye læsere.
Ikke blot ramme svar en liste besked for at starte en helt ny tråd. Dette vil begrænse dit publikum. Nogle mail læsere, ligesom mumlen, tillader brugeren at sortere efter tråd og derefter skjule beskeder i en tråd ved at folde tråden. Folk, der gør, vil aldrig se din besked.
Ændring af emnet er ikke tilstrækkelig. Mumlen, og sandsynligvis også andre mail læsere, ser andre oplysninger i e-mail’s overskrifter skal knyttes til en tråd, ikke emnelinjen. I stedet starte en helt ny e-mail.
Webfora, er regler for god praksis lidt anderledes, fordi meddelelser er normalt meget mere stramt bundet til specifikke diskussionstråde og ofte usynlige udenfor disse tråde. Ændring af emnet, når man spørger et spørgsmål er svar ikke afgørende. Ikke alle fora tillade engang separat emnelinjer svarene, og næsten ingen læser dem, når de gør. Imidlertid stiller et spørgsmål i et svar er en tvivlsom praksis i sig selv, fordi det vil kun blive set af dem, der ser denne tråd. medmindre du er sikker på du vil bede kun folk aktive i tråden, start en ny.
Gør det nemt at svare
Efterbehandling din forespørgsel med “send dit svar til… “gør det ganske usandsynligt, du vil et svar. Hvis du ikke gider at tage selv de sekunder kræves for at oprette en korrekt svar til sidehovedet i din mailbrugeragent, vi gider ikke at tage endnu et par sekunder til at tænke over dit problem. Hvis dit e-mailprogram ikke tillader dette, får en bedre mailprogram. Hvis dit operativsystem ikke understøtter alle e-mail-programmer, der tillader dette, får en bedre driftssystem.
I Webfora, bede om et svar via e-mail er decideret uhøflig, medmindre du mener, at oplysningerne kan være følsomme (og nogen vil, for nogle ukendt årsag, lade dig, men ikke hele forum ved det). Hvis du ønsker en e-mail-kopi, når nogen svar i tråden, anmode om, at webforum sende det; Denne funktion understøttes næsten overalt under indstillinger som “Se denne tråd”, “send e-mail svar”, osv.
Skrive klart, grammatiske, korrekt stavet sprog
Vi har fundet af erfaring, at mennesker er skødesløse og sjusket forfattere er som regel også skødesløse og sjusket tænkning og kodning (ofte nok til at satse , alligevel). Besvare spørgsmål for skødesløse og sjusket tænkere er ikke givende; Vi ville hellere vil bruge vores tid andetsteds.
udtrykke din spørgsmål klart og godt er vigtigt. Hvis du ikke gider at gøre det, vi gider ikke at betale opmærksomhed. Bruge den ekstra indsats at polere dit sprog. Det behøver ikke at være stiv eller formelle faktisk hacker kultur værdier uformelle, slangy og humoristisk sprogbrug med præcision. Men det skal være præcis; der være nogle tegn på, at du tænker og opmærksomhed.
Stave, punktformet, og udnytte korrekt. Må ikke forveksle “sin” med “det er”, “løs” med “miste”, eller “diskrete” med “diskret”. Ikke skrive i alle CAPS; Dette er læst som råben og betragtes som uhøflig. (All-smalls er kun lidt mindre irriterende, da det er svært at læse. Alan Cox kan slippe af sted med det, men du kan ikke.)
Mere generelt, hvis du skriver som en semi-færdigheder boob du vil højst sandsynligt blive ignoreret. ikke bruge instant-messaging genveje. Stavning “dig” som “u” gør du ligne en semi-færdigheder boob gemme to hele tastetryk. Værre: at skrive som en l33t script barnlille hax0r er absolut dødsstødet og garanterer du vil modtage intet men stenede stilhed (eller i bedste fald en dynger hjælpe af foragt og sarkasme) til gengæld.
Hvis du stiller spørgsmål i et forum, der ikke bruger dit modersmål, vil du en begrænset mængde af slæk for stavning og grammatik fejl men ingen ekstra slack overhovedet for dovenskab (og ja, kan vi normalt spot forskellen). Også, medmindre du kender din respondent sprog, skrive engelsk. Travl hackere har tendens til at bare skylle spørgsmål i sprog de ikke forstår, og engelsk er arbejdssproget i internettet. Ved at skrive engelsk minimere du dine chancer, at dit spørgsmål vil blive kasseret ulæst.
Hvis du skriver engelsk, men det er et andet sprog for dig, er det god tone at advare potentielle respondenter til potentielle sprogvanskeligheder og muligheder for at få omkring dem.. Eksempler:
  • Engelsk er ikke mit modersmål; Undskyld, tastefejl.
  • Hvis du taler $LANGUAGE, behage email/PM mig; Jeg måske har brug for hjælp oversætte mit spørgsmål.
  • Jeg er bekendt med de tekniske termer, men nogle slang udtryk og idiomer er svært for mig.
  • Jeg har sendt mit spørgsmål i $LANGUAGE og engelsk. Jeg vil være glad for at oversætte svar, hvis du kun bruger den ene eller den anden.
Send spørgsmål i tilgængelige, standard formater
Hvis du gør dit spørgsmål kunstigt svært at læse, er det mere sandsynligt at blive forbigået til fordel for en, der ikke er. :
  • Sende almindelig tekst e-mail, ikke HTML. (Det er ikke svært at slå HTML.)
  • MIME vedhæftede filer er som regel OK, men kun hvis de er virkelige indhold (f.eks. en vedhæftet kildefilen eller patch), og ikke blot standardtekst genereret af din e-mailklient (f.eks. en anden kopi af din besked).
  • Undlad at sende e-mail, hvor hele afsnit er enkelt formere-ombrudte linjer. (Dette gør det også vanskeligt at svare blot en del af beskeden.) Antage, at din respondenterne vil læse mail 80 tegn hele teksten vises og indstille din linje wrap i overensstemmelse hermed, at noget mindre end 80.
  • Dog ikke at ombrydes data (f.eks. log fil lossepladser eller session afskrifter) enhver fast kolonnebredde. Data skal medtages som-er, respondenterne kan have tillid til at de kan se hvad du .
  • Undlad at sende MIME Quoted-Printable kodning til en engelsk-sprog forum. Denne kodning kan være nødvendigt, når du sender i et andet sprog ASCII ikke dække, men mange e-mail-agenter støtte ikke den. Når de bryder, alle disse = 20 glyffer spredt gennem teksten er grimme og distraherende eller aktivt kan sabotere semantikken i din tekst.
  • Aldrig, aldrig forvente hackere at læse lukkede proprietære dokumentformater gerne Microsoft Word eller Excel. De fleste hackere reagere disse om godt som du ønsker at have en bunke af dampende svinegødning dumpet dit dørtrin. Selv når de kan klare, harmes de at skulle gøre det.
  • Hvis du sender e-mail fra en Windowsmaskine, slukke for Microsofts problematisk “Typografiske anførselstegn” indslag (fra værktøjer > indstillinger for Autokorrektur, rydde afkrydsningsboksen krøllede anførselstegn under AutoFormat som du skriver.). Dette er du vil undgår overbrusning ulæselige tegn gennem din mail.
  • I Webfora, ikke misbrug “smiley” og “HTML” funktioner (når de er til stede). En smiley eller to er som regel OK, men farvet fancy tekst tendens til at gøre folk tror, du er halt. Alvorligt overusing smileys og farver og skrifttyper vil gøre dig komme ud som en giggly teenage pige, der ikke er generelt en god idé, medmindre du er mere interesseret i sex end svar.
Hvis du bruger en grafisk brugergrænseflade mailklient såsom Netscape Messenger, MS Outlook eller deres ligemænd, pas på at det kan krænke disse regler, når det bruges med standardindstillingerne. De fleste sådanne klienter har en menu-baserede “Vis kilde” kommando. Brug det noget i mappen sendte e-mails, bekræfter afsendelse af almindelig tekst uden unødvendige vedlagte crud.
Være præcise og informative om dit problem
  • Beskrive symptomerne dit problem eller bug omhyggeligt og klart.
  • Beskriv det miljø, hvor det forekommer (maskine, OS, overførelse, uanset). Give din kreditor distribution og udgivelse niveau (f.eks.: “Fedora Core 7″, “Slackware 9,1″, osv.).
  • Beskrive den forskning, du gjorde for at forsøge at forstå problemet, før du har stillet spørgsmålet.
  • Beskrive de diagnostiske trin du tog til prøve og pin ned problemet selv før du stillede spørgsmålet.
  • Beskrive eventuelt relevante nylige ændringer i din computer eller software konfiguration.
  • Hvis det overhovedet er muligt, give en måde at genskabe problemet i et kontrolleret miljø.

Gøre det bedste du kan for at foregribe spørgsmål en hacker vil spørge og svare dem forhånd i din anmodning om hjælp.

Giver hackere mulighed for at genskabe problemet i et kontrolleret miljø er især vigtigt, hvis du rapporterer noget du synes er en fejl i koden. Når du gør dette, forbedre dine odds for at få en hensigtsmæssig besvarelse og den hastighed, hvormed du er tilbøjelige til at , at besvarer både uhyre.
Simon Tatham har skrevet en fremragende essay med titlen hvordan man rapporterer fejl effektivt. Jeg kan varmt anbefale at du læser det.
Diskenheden er ikke præcision
Du skal være præcise og informative. Herpå serveres ikke blot dumping enorme mængder af kode eller data i en hjælpanmodning. Hvis du har en stor, kompliceret prøvesag, der er at bryde et program, forsøge at trimme det og gøre den lille som muligt.
Dette er nyttigt for mindst tre grunde. Et: at blive set at investere indsats i forenkle spørgsmålet gør det mere sandsynligt, får du et svar, to: forenkle spørgsmålet gør det mere sandsynligt, får du en hensigtsmæssig besvarelse. Tre: Ved at raffinere din fejlrapport, kan du udvikle en programrettelse eller løsning dig selv.
Ikke haste til at kræve, at du har fundet en fejl
Når du har problemer med et stykke software, påstå ikke du har fundet en fejl, medmindre du er meget, meget sikker din jord. Tip: medmindre du kan give en kildekode programrettelse, der løser problemet, eller en regression test mod en tidligere version, der viser forkert adfærd, du er sandsynligvis ikke sikker nok. Dette gælder for websider og dokumentation, også; Hvis du har fundet en dokumentation “bug”, du skal levere udskiftning tekst og hvilke sider det skal .
Husk, der er mange andre brugere, der ikke oplever dit problem. Ellers ville du har lært om det samtidig læse dokumentation og søge nettet (du gjorde, før klager, ikke du?). Det betyder, at meget sikkert det er dig, der gør noget forkert, ikke softwaren.
De mennesker, der skrev softwaren arbejde meget hårdtat gøre det arbejde såvel som muligt. Hvis du påstår du har fundet en fejl, vil du bestride deres kompetence, der kan støde nogle af dem, selvom du er korrekte. Det er især udiplomatisk at råbe “bug” i emnelinjen.
Når du beder dit spørgsmål, er det bedst at skrive som om du antage, at du gør noget forkert, selv om du er privat temmelig sikker på, du har fundet en faktiske fejl. Hvis der virkelig er en fejl, vil du høre om det i svaret. Spille det vedligeholderne vil gerne undskylde over for dig, hvis fejlen er reel, i stedet for at du vil skylder dem en undskyldning, hvis du har rodet.
Krybende er ikke en erstatning for at gøre dit hjemmearbejde
Nogle mennesker, der får de ikke opfører sig brutalt eller arrogant, kræver et svar, trække sig tilbage til den modsatte yderlighed af krybende. “Jeg ved, jeg er bare en patetisk newbie taber, men…”. Dette er distraherende og uhensigtsmæssig. Det er især irriterende, når det er koblet med uklarhed om det egentlige problem.
Spild ikke din tid eller vores, primat politik. I stedet præsentere baggrunden fakta og dit spørgsmål klart som du kan. Der er en bedre måde at positionere dig selv end ved krybende.
Undertiden har Webfora separate steder for newbie spørgsmål. Hvis du føler, du har en newbie spørgsmål, bare der. Men ikke kryben der enten.
Beskriv det problem symptomer, ikke dine gæt
Det er ikke hensigtsmæssigt at Fortæl hackere hvad du mener er årsag dit problem. (Hvis din diagnostiske teorier var sådan hot stuff, ville du consulting andre om hjælp?) , Sørg for at du fortæller dem symptomerne hvad der går galt, i stedet for din fortolkninger og teorier. Lad dem gøre fortolkning og diagnose. Hvis du føler det er vigtigt, at dit gæt, klart mærke det som sådan og beskrive hvorfor svaret ikke virker for dig.
Dum:
Jeg får back-to-back SIG11 fejl kerne udarbejder, og har mistanke om en hårgrænsen knæk et af bundkort sporene. Hvad er den bedste måde at tjekke for dem?
Smart:
Mit hjem-bygget K6/233 en FIC-PA2007 bundkort (VIA Apollo VP2 chipset) med 256MB Corsair PC133 SDRAM begynder at få hyppig SIG11 fejl omkring 20 minutter efter power-on i løbet af kerne udarbejder, men aldrig i de første 20 minutter. Genstart ikke genstarte uret, men kraftoverførsel ned natten gør. Bytte ud alle RAM hjalp ikke. Den relevante del af en typisk session kompileringslog følger.
Da det foregående punkt synes at være en hård én for mange mennesker at forstå, her er en sætning til minde om: “alle bilinspektionsteknikere er fra Missouri.” KR. statens officielle motto er “Vis mig” (tjent i 1899, da kongresmedlem Willard D. Vandiver sagde “jeg kommer fra et land, der rejser majs og bomuld og cockleburs og Demokrater, og skummende veltalenhed hverken overbeviser eller opfylder mig. Jeg er fra Missouri. Har du vise mig.”) I bilinspektionsteknikere sag, det er ikke et spørgsmål om skepsis, men snarere en bogstavelig, funktionelle behov for at se hvad er tæt som muligt den samme beviser, som du kan se, i stedet for dine gisninger og resuméer. Vis os.
Beskriv dit problem symptomer i kronologisk rækkefølge
Det spor mest nyttige i at finde ud af noget, der gik galt ofte ligge i de umiddelbart forudgående begivenheder. din konto bør beskrive præcist hvad du gjorde, og hvad maskine og software gjorde, fører op til blowup. I tilfælde af kommandolinjeværktøjet processer, under en session log (f.eks., hvordan du bruger hjælpeprogrammet script) og citere de relevante snes linjer er meget nyttig.
Hvis det program, der blæste du har diagnostiske muligheder (såsom – v for verbose), prøv at vælge indstillinger, der vil tilføje nyttige fejlfindingsoplysninger til udskriften. Husk, at mere ikke er nødvendigvis bedre; Prøv at vælge en debug niveau, der vil informere i stedet for at drukne læseren i junk.
Hvis din konto ender med at være lang tid (mere end omkring fire stk.), kan det være nyttigt at kortfattet tilstand problem op toppen, Følg med den kronologiske fortælling. På den måde, vil hackere vide hvad man skal se efter i læsning din konto.
Beskrive mål, ikke skridt
Hvis du forsøger at finde ud af at gøre noget (i modsætning til rapportering en bug), begynde med at beskrive målet. Kun derefter beskrive de særlige skridt i retning af det, at du er blokeret .
Ofte, folk der har brug for teknisk hjælp, har et højt mål for øje og sidder fast hvad de tror er en bestemt vej mod målet. De kommer for at få hjælp med skridt, men ikke klar over, at stien er forkert. Det kan tage væsentlig indsats for at komme forbi dette.
Dum:
Hvordan får jeg farvevælgeren FooDraw program til at tage den hexadecimale RGB-værdi?
Smart:
Jeg forsøger at erstatte farvetabel i et billede med værdier af mit valg. Lige nu den eneste måde jeg kan se at gøre dette er ved at redigere hver tabel slot, men jeg kan ikke Foodraws Farvevælger til at tage den hexadecimale RGB-værdi.
Den anden version af spørgsmålet er smart. Det giver et svar, der tyderen værktøj bedre egnet til opgaven.
Spørg folk svare via privat e-mail
Hackere tror problemløsning bør være en offentlig og gennemsigtig proces under som et første forsøg et svar kan og bør korrigeres, hvis nogen mere velinformerede bemærker, at det er ufuldstændige eller ukorrekte. Også får hjælpere nogle af deres belønning for at være respondenter fra at blive set at være kompetente og vidende af deres jævnaldrende.
Når du beder om en privat svar, forstyrrer du både processen og belønning. Ikke gør dette. Det er sagsøgtes valg om at svare privat og hvis han eller hun ikke, er det som regel fordi han eller hun mener, at spørgsmålet er alt for dårligt udformet eller indlysende at være interessant for andre.
Der er en begrænset undtagelse fra denne regel. Hvis du tror, at spørgsmålet er sådan, at du er tilbøjelige til at mange svar, der er alle nøje lignende, er de magiske ord “e-mail mig, og jeg vil opsummere svar til gruppen”. Det er høfligt at forsøge at gemme mailing liste over eller nyhedsgruppe en oversvømmelse af væsentligt identisk bogføringer men du er nødt til at holde løftet om at opsummere.
Være eksplicit om dit spørgsmål
Åbne spørgsmål har tendens til at blive opfattet som åben tid dræn. De mennesker, der er mest sandsynligt, at være i stand til at give dig en nyttig svar er også de travleste mennesker (hvis kun fordi de tager den mest arbejde sig selv). Folk kan lide der er allergiske over for ubegrænset tid dræn, således de tendens til at være allergiske over for spørgsmål med åbne svarmuligheder.
Du er mere tilbøjelige til at en nyttig reaktion hvis du eksplicit om, hvad du ønsker respondenterne at (give pejlemærker, sende kode, indskrive jeres lappe, uanset). Dette vil fokusere deres indsats og implicit sætte en øvre grænse den tid og energi en svarperson skal afsætte til at hjælpe dig. Dette er godt.
For at forstå den verden eksperterne lever i, Tænk ekspertise som en rigelig ressource og tid til at reagere som en sjælden en. Mindre af en gang engagement du implicit spørger til, jo mere sandsynligt du er at et svar fra nogen virkelig god og virkelig travlt.

  det er nyttigt at ramme dit spørgsmål for at minimere den tid engagement kræves for en ekspert at feltet det men det er ofte ikke de samme ting som forenkle spørgsmålet. Således, for eksempel, “vil du give mig en pegepind til en god forklaring X?” er normalt en smartere spørgsmål end “vil du forklare X, please?”. Hvis du har nogle fejl kode, er det som regel klogere at spørge nogen til at forklare, hvad der er galt med det end at spørge nogen til at ordne det.

Når du beder om koden
Spørg andre til at fejlfinde din brudt kode uden at give en antydning hvad slags problem de bør være at søge efter. Udstationering et par hundrede kodelinjer, siger “det ikke virker”, får du ignoreret. Udstationering en halv snes linjer kode, er siger “efter linie 7 jeg ventede at se <x>, men <y>opstod i stedet” meget mere tilbøjelige til at dig et svar.
Den mest effektive måde at være præcis om en kode problem er at give en minimal bug-demonstrere prøvesag. Hvad er en minimal prøvesag? Det er en illustration af problemet; lige nok kode at udstille den uønskede adfærd og ikke mere. Hvordan laver du en minimal prøvesag? Hvis du ved, hvad linje eller en sektion af kode producerer den problematiske adfærd, lave en kopi af det og Tilføj lige nok støtte kode for at producere et komplet eksempel (dvs nok, at kilden er acceptabel for den kompileren/tolk/whatever program behandler det). Hvis du ikke kan indsnævre den ned til et bestemt afsnit, lave en kopi af kilden og begynd at fjerne klumper, der ikke påvirker den problematiske adfærd. Jo mindre din minimal prøvesag er, jo bedre (Se afsnittet kaldet “Volumen er ikke precision”).
Generere en rigtig lille minimal prøvesag vil ikke altid være muligt, men forsøger at er god disciplin. Det kan hjælpe dig med at lære, hvad du har brug at løse problemet egen hånd og selv når det ikke sker, hackere gerne se at du har prøvet. Det vil gøre dem mere samarbejdsvillig.
Hvis du blot ønsker en kode anmeldelse, siger meget op foran, og sørg for at nævne hvad områder du mener måske især brug for anmeldelse og hvorfor.
Undlad at lægge hjemmearbejde spørgsmål
Hackere er god til at spotte hjemmearbejde spørgsmål; de fleste af os har gjort dem selv. Disse spørgsmål er for dig at træne, vil du lære af erfaringerne. Det er OK at bede om nemlig antydninger, men ikke for hele løsninger.
Hvis du har mistanke om du har været gået et hjemmearbejde spørgsmål, men kan ikke løse det anyways, prøv at spørge i en bruger gruppe forum eller (som en sidste udvej) i en “bruger” liste/forum af et projekt. Mens hackere vil stedet det, kan nogle af de avancerede brugere i det mindste give dig et vink.
Sveske meningsløst forespørgsler
Modstå fristelsen til at lukke din anmodning til hjælp med semantisk-null spørgsmål som “Kan nogen hjælpe mig?” eller “Er der et svar?” Først: Hvis du har skrevet dit problembeskrivelse halvvejs kompetent, sådan dingler på spørgsmål er i bedste fald overflødige. For det andet: fordi de er overflødige, hackere finder dem generende og som sandsynligvis vil returnere logisk upåklagelig men afvisende svar som “Ja, du kan blive hjulpet” og “Nej, der er ingen hjælp for dig.”
Generelt beder ja eller nej spørgsmål er en god ting at undgå, medmindre du ønsker et ja eller nej svar.
Ikke flag dit spørgsmål som “Hastende”, selv om det er for dig
Det er dit problem, ikke vores. Om hastetilfælde er meget sandsynligt, at være kontraproduktiv: de fleste hackere vil simpelthen slette sådanne meddelelser som uhøflig og egoistisk forsøg på at fremkalde øjeblikkelig og særlig opmærksomhed. Derudover ordet ‘Haster’ (og andre lignende forsøg på at fange opmærksomhed i emnelinjen) ofte udløser spamfiltre de ønskede modtagere kan aldrig se det alle!
Der er en semi-undtagelse. Det kan være værd at nævne, hvis du bruger programmet i nogle højt profilerede sted, som hackere får begejstret; i et sådant tilfælde, hvis du er under tidspres, og du sige det høfligt, kan folk interesseret nok til at svare hurtigere.
Dette er en meget risikabel ting at gøre, men fordi hackerne metrikværdien for hvad er spændende nok er forskellig fra din. Bogføring fra den internationale rumstation vil kvalificere sig, for eksempel, men udstationering for en feel good velgørende eller politisk årsag vil næsten helt sikkert ikke. Faktisk udstationering “haster: hjælpe mig spare fuzzy babysæler!” får pålideligt du undgået eller flammede selv af hackere, der tror, fuzzy babysæler er vigtigt.
Hvis du finder dette mystiske, re Læs resten af denne how-to gentagne gange indtil du forstår det før udstationering noget overhovedet.
Høflighed gør ondt aldrig, og nogle gange hjælper
Vær høflig. Bruges “Please” og “Tak for din opmærksomhed” eller “Tak for din overvejelse”. Gøre det klart, du værdsætter gang folket bruge hjælper dig gratis.

 For at være ærlig, det er ikke vigtigt som (og kan ikke erstatte) er grammatiske, klare, præcise og beskrivende, undgå proprietære formater osv.; hackere vil i almindelighed hellere noget brysk men teknisk skarpe fejlrapporter end høflig vage. (Hvis det undrer dig, huske, at vi værdsætter et spørgsmål af hvad det lærer os.)

Men hvis du har fået din tekniske ænder i træk, høflighed øger dine chancer for at få en hensigtsmæssig besvarelse.
(Vi konstatere, at den kun alvorlige indvending, vi har modtaget fra veteran hackere til denne HOWTO er med hensyn til vores tidligere henstilling om at bruge “Tak forhånd”. Nogle hackere føler det konnoterer hensigt ikke at takke nogen bagefter. Vores anbefaling er at enten sige “Tak forhånd” først og takke respondenterne bagefter, eller udtrykkelige høflighed i en anden måde, som ved at sige “Tak for din opmærksomhed” eller “Tak for din overvejelse”.)
Følge op med en kort note om løsning
Sende en note, når problemet er blevet løst til alle, der hjalp dig; Lad dem vide, hvordan det kom ud og gang takke dem for deres hjælp. Hvis problemet tiltrukket af almen interesse i en mailing liste over eller nyhedsgruppe, er det passende at skrive opfølgning der.
Optimalt, svaret bør være til den tråd startet af den oprindelige spørgsmål udstationering, og bør have ‘faste’, ‘Løst’ eller et lige så indlysende tag i emnelinjen. postlister med hurtig ekspeditionstid, en potentiel svarperson, der ser en tråd om “Problem X” slutter med “Problem X fast” ved ikke for at spilde sin tidselv at læse tråden (medmindre (s) han personligt finder Problem X interessant) og kan derfor bruge dengang et andet problem.
Din opfølgning behøver ikke at være lange og indviklede; en simpel “Howdy det var en mislykket netværkskabel! Tak, alle. Bill ville være bedre end ingenting. Faktisk er en kort og sød Resumé bedre end en lang afhandling, medmindre løsningen har reelle tekniske dybde. Sige hvilke foranstaltninger løst problemet, men du behøver ikke replay hele fejlfinding sekvens.
For problemer med nogle dybde er det hensigtsmæssigt at opstille en oversigt over fejlfinding historie. Beskrive din endelige problem erklæring. Beskrive, hvad der virkede som en løsning og angive undgåelige blindgyder ovenpå. Blindgyder skulle komme efter den rigtige løsning og andre kortfattede materiale, i stedet for at gøre opfølgningen til en detektivhistorie. Nævne navnene personer, der har hjulpet dig; du vil venner på den måde.
Udover at være høflig og informative, vil denne form for opfølgning hjælpe andre søge Arkiv af mailing-liste/nyhedsgruppe/forum at vide præcis hvilken løsning har hjulpet dig og dermed kan også hjælpe dem med.
Sidst og ikke mindst, hjælper denne form for opfølgning alle, der har bistået føler en tilfredsstillende følelse af lukningen om problemet. Hvis du ikke er en techie eller hacker selv, stoleos, at denne følelse er meget vigtigt at guruer og eksperter du tappet for hjælp. Problem fortællinger, der trail off i uløste intetheden er frustrerende ting; hackere kløe at se dem løst. Den goodwill, der ridse at klør optjener du vil være meget, meget nyttigt for dig næste gang du skal stille et spørgsmål.
Overvej, hvordan du muligvis forhindre andre i at have det samme problem i fremtiden. Spørg dig selv om en dokumentation eller FAQ patch ville hjælpe, og hvis svaret er ja send, der patch til vedligeholderen.
Blandt hackere er denne form for god opfølgning opførsel faktisk vigtigere end konventionelle høflighed. Det er, hvordan du får ry for at spille godt sammen med andre, som kan være et meget værdifuldt aktiv.
Hvordan man skal fortolke svar
RTFM og STFW: Sådan at fortælle du har alvorligt skruet
Der er en gammel og hellige tradition: Hvis du får et svar, der hedder “RTFM”, den person, der sendte det mener du skal have læse den skide Manual. Han eller hun er næsten helt sikkert rigtigt. læse det.
RTFM har en yngre slægtning. Hvis du får et svar, der hedder “STFW”, mener den person, der sendte det du skal have søgt de Fucking nettet. Han eller hun er næsten helt sikkert rigtigt. søge i den. (Den mildere version af dette er, når du får at vide “Google er din ven!”)
I Webfora, kan du også blive fortalt at søge forum arkiv. Nogen kan faktisk endda være venlig at give en henvisning til den tidligere tråd, hvor problemet blev løst. Men ikke er afhængige af denne betragtning; gøre din Arkiv-søgning før du spørger.
Ofte, har den person, der fortæller dig at lave en søgning manualen eller webside med de oplysninger du har brug for åbne, og ser det som han eller hun typer. Disse besvarelser betyder at modtageren tænker (a) de nødvendige oplysninger er let at finde, og (b) du vil lære mere hvis du søge informationer end hvis du har det spoon-fed til dig.
Du bør ikke blive stødt af dette; hacker standarder, din respondent viser du en grov form for respekt ved blot ikke ignorere dig. Du bør i stedet være taknemmelige for denne grandmotherly venlighed.
Hvis du ikke forstår…
Hvis du ikke forstår svaret, ikke straks hoppe tilbage et krav om en afklaring. Brug de samme værktøjer, som du brugte til at prøve og besvare dit oprindelige spørgsmål (manualer, FAQ, Web, dygtige venner) for at forstå svaret. Hvis du stadig nødt til at bede om en afklaring, udvise derefter, hvad du har lært.
Antag f.eks., at jeg fortælle dig: “det lyder som om du har fået et fast zentry; du bliver nødt til at klare det.” Da: her er en dårlig opfølgning spørgsmål: “Hvad er en zentry?” Her er en god opfølgning spørgsmål: “OK, jeg læste den mand sider og zentries er kun nævnt under – z og -pswitche. Ingen af dem siger noget om clearing zentries. Er det en af disse eller er jeg mangler noget her?”
Beskæftiger sig med rudeness
Meget af hvad der ligner rudeness i hacker kredse ikke er beregnet til at give lovovertrædelse. Det er derimod et produkt af den direkte, snit gennem bullshit kommunikation stil, der er naturlige for mennesker, der bekymrer sig mere om at løse problemer end at gøre andre føler sig varm og fuzzy.
Når du opfatter uhøflighed, forsøge at reagere roligt. Hvis nogen virkelig handler ud, er det meget sandsynligt, en højtstående person liste over eller nyhedsgruppe eller forum vil kalde ham eller hende det. Hvis der ikke sker og du mister dit temperament, er det sandsynligt, at den person, du mister det opfører sig inden for de hackersamfundet normer og du vil blive betragtet som skyld. Dette vil gøre ondt dine chancer for at få oplysninger eller hjælp, du ønsker.
den anden side vil du lejlighedsvis kører på tværs af uhøflighed og poseren, der helt umotiveret. Bagsiden af ovenstående er, at det er acceptabel form at smække virkelige lovovertrædere ganske svært, dissekere deres dårlige opførsel med en skarp verbal skalpel. Være meget, meget sikker din jord, før du forsøger dette, dog. Linjen mellem korrigere en incivility og starte en meningsløs flamewar er tynd nok, at hackere, selv ikke sjældent bommert på tværs af det; Hvis du er en newbie eller en outsider, er dine chancer for at undgå sådan en bommert lav. Hvis du er ude efter oplysninger i stedet for underholdning, er det bedre at holde fingrene fra tastaturet end at risikere dette.
(Nogle mennesker hævder, at mange hackere har en mild form for autisme eller Aspergers syndrom, og mangler faktisk nogle af hjernen kredsløb, der smører “normale” menneskelig social interaktion. Dette kan eller kan ikke være rigtigt. Hvis du ikke er en hacker dig selv, det kan hjælpe dig med at klare vores særheder, hvis du tænker os som hjerne-skadede. lige videre. Vi vil ikke pleje; Vi kan lide at være hvad det er, vi er, og generelt har en sund skepsis om kliniske etiketter.)
I næste afsnit vil vi snakke om en anden sag; slags “rudeness” vil du se når du være uartig.
ikke reagerer som en taber
Odds er du vil skrue op et par gange hacker gruppeforaene i måder beskrevet i denne artikel, eller lignende. Og du vil at vide, præcis hvordan du skruet op, eventuelt med farverige sidebemærkninger. I det offentlige.
Når dette sker, er det værste du kan gøre jamre over oplevelsen, hævder, at de er blevet verbalt overfaldet, kræver undskyldninger, skrige, hold din ånde, truer med retssager, klage til folks arbejdsgivere, forlade toiletsædet op, osv. I stedet, her er hvad du gør:
Komme over det. Det er normalt. I virkeligheden, er det sundt og hensigtsmæssigt.
Fællesskabets normer ikke opretholder sig selv: de er vedligeholdt af mennesker aktivt anvender dem, synligt, i det offentlige. Ikke klynke at al kritik bør transporteres via privat e-mail: thats ikke hvordan det fungerer. Eller er det nyttigt at insistere du har været personligt fornærmet, når nogen kommentarer, en af dine påstande var forkert, eller at hans opfattelser. Dem, der er taberen holdninger.
Der har været hacker fora hvor, ud over nogle misforstået følelse af hyper-høflighed, deltagerne er udelukket fra udstationering ethvert fejlsøgningsudstyr med en andens indlæg, og fortalte “ikke sige noget hvis du er villig til at hjælpe brugeren.” Den resulterende afgangsstedet kunne deltagerne til andre steder får dem til at gå ned i meningsløse plapre og blive ubrugelig som tekniske fora.
Overdrevent “venlige” (i denne mode) eller nyttige: vælge en.
Husk: Når at hacker fortæller dig, at du har skruet op, og (uanset hvordan skal) fortæller dig om ikke at gøre det igen, han handler ud af bekymring for (1) du og (2) sit samfund. Det ville være meget lettere for ham at ignorere dig og filtrere dig ud af sit liv. Hvis du ikke kan klare at være taknemmelig, i det mindste har lidt værdighed, ikke klynke og ikke forvente at blive behandlet som en skrøbelig dukke, bare fordi du er en nybegynder med en teatralsk overfølsomme sjæl og vrangforestillinger af retten.
Sommetider mennesker vil angribe dig personligt, flamme uden en påviselig grund, osv., selvom du ikke skrue op (eller har kun skruet i deres fantasi). I dette tilfælde, klager, er den måde at virkelig skrue op.
Disse flamers er enten lamers, hvem der ikke har en anelse om, men mener selv at være eksperter eller vordende psykologer teste, om du vil skrue op. De andre læsere enten ignorere dem, eller finde måder at håndtere dem egen hånd. Flamers’ opførsel skaber problemer for sig selv, som ikke behøver at bekymrer dig.
Lad dig blive trukket ind i en flamewar, enten. De fleste flammer ignoreres bedst efter du har kontrolleret, om de virkelig er flammer, ikke henvisninger til de måder, hvorpå du har skruet op, og ikke så smart kryptograferede svar til dit egentlige spørgsmål (dette sker godt).
Spørgsmål ikke at stille
Her er nogle klassiske dumme spørgsmål, og hvad hackere tænker, når de ikke besvare dem.
Q:
Hvor kan jeg finde programmet eller ressource X?
A:
Samme sted jeg ville finde det, nar i anden enden af en websøgning. Ghod, ikke alle ved hvordan man bruger Google endnu?
Q:
Hvordan kan jeg bruge X for at gøre Y?
A:
Hvis du ønsker, er at gøre Y, skal du stille spørgsmålet uden pre formode, anvendelse af en metode, der ikke kan være passende. Spørgsmål af denne form er ofte tegnen person, der er ikke blot uvidende om X, men forvirret over hvad problemet Y de er løse og også fikseret detaljerne i deres særlige situation. Det er generelt bedst at ignorere sådanne mennesker, indtil de definerer deres problem bedre.
Q:
Hvordan kan jeg konfigurere min shell lynhurtig?
A:
Hvis du er smart nok til at stille dette spørgsmål, du er smart nok til RTFM og finde ud af dig selv.
Q:
Kan jeg konvertere et AcmeCorp dokument til en TeX fil ved hjælp af bas-o-matic fil konverter?
A:
Prøv det og se. Hvis du gjorde det, ville du (a) lære svaret og b stoppe spilde min tid.
Q:
Min {program, konfiguration, SQLsætning} virker ikke
A:

Dette er ikke et spørgsmål, og jeg er ikke interesseret i at spille 20 spørgsmål for at lirke dine faktiske spørgsmål ud af dig jeg har bedre ting at gøre. at se noget som dette, er min reaktion normalt en af følgende fremgangsmåder:

  • har du noget andet at tilføje til det?
  • Åh, det er ærgerligt, jeg håber du får det fast.
  • og det er præcis hvad de skal gøre med mig?
Q:
Jeg har problemer med min Windowsmaskine. Kan du hjælpe?
A:
Ja. Smide ud at Microsoft trash og installere et open source operativsystem som Linux eller BSD.
Bemærk: du kan spørge spørgsmål relateret til Windows maskiner hvis de drejer sig om et program, der har en officiel Windows bygge, eller interagerer med Windowsmaskiner (dvs., Samba). Bare ikke blive overrasket over det svar, at problemet er med Windows og ikke programmet, fordi Windows er brudt generelt at det meget ofte er tilfældet.
Q:
Mit program virker ikke. Jeg tror systemet facilitet X er brudt.
A:
Mens det er muligt, at du er den første person til at mærke en indlysende mangel i systemkald og biblioteker stærkt bruges af hundredeller tusindvis af mennesker, er det mere sandsynligt, at du er totalt clueless. Ekstraordinære påstande kræver ekstraordinære beviser; Når du foretager en påstand som denne, skal du sikkerhedskopiere det med klare og udtømmende dokumentation for den manglende sag.
Q:
Jeg har problemer med at installere Linux eller X. Kan du hjælpe?
A:
Nej. Jeg havde brug for praktisk adgang til din maskine til at fejlfinde dette. Spørg din lokale Linuxbrugergruppe til praktisk hjælp. (Du kan finde en liste over brugergrupper her.)
Note: spørgsmål om installation Linux kan være passende, hvis du er et forum eller en postliste om en bestemt fordeling, og problemet er med denne distro; eller lokale grupper brugerfora. I dette tilfælde være sikker på at beskrive den nøjagtige oplysninger fiasko. Men forsigtig søge først, med “linux” og alle mistænkelige stykker hardware.
Q:
Hvordan kan jeg knæk root/stjæle kanal-ops privilegier/læse nogens e-mail?
A:
Du er en lowlife for at ønske at gøre sådanne ting og en idiot for at spørge en hacker til at hjælpe dig.
Gode og dårlige spørgsmål
Endelig vil jeg illustrere, hvordan til at stille spørgsmål en smart måde med et godt eksempel; par spørgsmål om det samme problem, et bad i en dum måde og en en smart måde.
Dum: Hvor kan jeg finde ud af ting om den Foonly Flurbamatic?
Dette spørgsmål tigger bare om “STFW” som et svar.
Smart: Jeg brugte Google for at forsøge at finde “Foonly Flurbamatic 2600” på nettet, men jeg fik ingen nyttige hits. Kan jeg en pointer til programmering oplysninger om denne enhed?
Denne ene har allerede STFWed, og lyder som om der kan være et reelt problem.
Dumt: Jeg kan ikke koden fra projekt foo at kompilere. Hvorfor er det brudt?
Querent antages det, at en anden skruet. Arrogant git…
Smart: Koden fra projekt foo ikke kompilere under Nulix version 6.2. Jeg har læst FAQ, men det har ikke noget i det om Nulix-relaterede problemer. Her er en udskrift af min samling forsøg; er det noget jeg gjorde?
Querent har angivet miljø, læse FAQ, vises fejlen og er ikke under forudsætning af hans problemer er en andens skyld. Dette kan være værd at nogle opmærksomhed.
Dumt: Jeg har problemer med mit bundkort. Kan nogen hjælpe?
J. tilfældige hackers svar dette er sandsynligvis være “ret. Har du behov for bøvsen og diapering, for?”efterfulgt af en punch af deletetasten.
Smart: Jeg prøvede X, Y og Z S2464 bundkort. Når det ikke gjorde arbejde, jeg prøvet A, B, og C. Bemærk nysgerrig symptomet når jeg prøvet C. naturligvis florbish er grommicking, men resultaterne er ikke, hvad man kunne forvente. Hvad er de sædvanlige årsager til grommicking Athlon MP bundkort? Nogen fik ideer flere test jeg kan køre til pin ned problemet?
Denne person, den anden side synes fortjener et svar. Han/hun har udstillet problemløsning intelligens i stedet for passivt venteret svar til at falde fra high.
I det sidste spørgsmål, mærke en subtil, men vigtig forskel mellem krævende “Giv mig et svar” og “behage hjælp mig finde ud af, hvilke yderligere diagnostics kan jeg køre for at opnå oplysning.”
Faktisk er form af det sidste spørgsmål nøje baseret en virkelig hændelse, der skete i August 2001 postlisten linux-kernel (lkml). Jeg (Eric) var den stille spørgsmålet dengang. Jeg ser mystisk lockups en Tyan S2462 bundkort. Listemedlemmer leverede den kritiske oplysninger jeg havde brug at løse dem.
Ved at stille spørgsmålet, som jeg gjorde, gav jeg mennesker noget at tygge ; Jeg gjorde det nemt og attraktivt for dem at blive involveret. Jeg viste respekt for mine kammerater evne og inviteret dem til at rådføre sig med mig som en peer. Jeg viste også respekt for værdien af deres tid ved at fortælle dem de blindgyder, jeg havde allerede kørt ned.
Bagefter, når jeg takkede alle og bemærkede hvor godt processen havde arbejdet, en lkml medlem bemærkede, at han troede, det havde virket, ikke fordi jeg er et “navn” denne liste, men fordi jeg stillede spørgsmålet i ordentlig form.
Hackere er nogle måder en meget hensynsløse meritokrati; Jeg er sikkerhan var ret, og at hvis jeg havde opført sig som en svamp jeg ville have været flammede eller ignoreret uanset hvem jeg var. Hans forslag om, at jeg skriver op hele hændelsen som instruktion til andre førte direkte til sammensætningen af denne guide.
Hvis du ikke kan et svar
Hvis du ikke kan et svar, kan du ikke tage det personligt at vi ikke føler vi kan hjælpe dig. Nogle gange kan medlemmerne af gruppen stillede ikke blot kender svaret. Ingen svar er ikke det samme som at blive ignoreret, selvom det er ganske vist svært atøjeforskellen fra uden for.
Generelt er er blot re-udstationering din forespørgsel en dårlig idé. Dette vil blive betragtet som meningsløst irriterende. Har tålmodighed: person med dit svar kan være i en anden tidszone og søvn. Eller det kan være, at dit spørgsmål ikke var korrekt udformet til at begynde med.
Der er andre kilder til