Jak se správně ptát

Eric Steven Raymond,Thyrsus Enterprises,esr@thyrsus.com
Rick Moen,rick@linuxmafia.com
© 2001 Eric S. Raymond

Překlad

16. dubna 2004, překlad verze 3.0 anglického originálu.
27. září 2004, opravy od Jakuba Vrány.

Upozornění

Stránky mnoha projektů uvádějí odkaz na tento dokument jako nápovědu. To je v pořádku, to jsme zamýšleli – pokud ale na své stránce takový odkaz vytváříte, zdůrazněte prosím, že nejsme helpdesk pro váš projekt!

Bez takového upozornění (jak jsme zjistili) budeme opakovaně obtěžováni idioty, kteří se domnívají, že zveřejnění podobného dokumentu nás zavazuje řešit veškeré technické problémy světa.

Pokud čtete tento dokument ve snaze získat pomoc, a odnášíte si dojem, že tuto pomoc získáte od nás, pak právě vy patříte mezi takové idioty.Nás se neptejte. Neodpovíme vám. Chceme vám jen ukázat, jak získat pomoc od těch, kteří vašim problémům rozumí, což z devětadevadesáti procent nejsme my. Pakliže si nejste jisti, že právě některý z autorů je odborníkem na váš problém, dejte nám raději pokoj a všechno bude lepší.

Úvod

Ve světě hackerůzáleží odpověď na vaši technickou otázku stejně tak na obtížnosti otázky samotné jako na tom, jak se zeptáte. Tato příručka si klade za cíl poučit vás o tom, jak se ptát tak, abyste získali uspokojivou odpověď.

Předně, hackeři mají rádi těžké problémy a dobré, stimulující otázky. Jinak bychom to nedělali. Za dobrou otázku budeme vděční; dobrá otázka je povzbuzení. Dobré otázky prohlubují chápání věci, a často odhalí problémy, kterých bychom si jinak nevšimli. Mezi hackery je „Dobrá otázka!“ skutečným komplimentem.

Přesto mají hackeři reputaci těch, kdo přijímají jednoduché otázky s jakýmsi nepřátelstvím či arogancí. Vypadá to, jako bychom byli na začátečníky a neználky drzí. Ale tak to není.

Jsme jen zaujatí vůči lidem, kteří nechtějí přemýšlet nebo se sami snažit předtím, než se začnou ptát. S takovými lidmi člověk pouze ztrácí čas, který se dá strávit nad jinou, zajímavější otázkou, nebo věnovat někomu, kdo spíš stojí za odpověď. Říkáme takovým lidem losers [lúzeři] (a z historických důvodů to někdy píšeme lusers).

Uvědomujeme si, že spousta lidí se nezajímá o technické detaily, chtějí prostě jen používat programy, které píšeme. Pro většinu lidí je počítač pouhý nástroj – mají spoustu lepších věcí na práci a svých starostí dost. To bereme na vědomí, a nečekáme, že se každý zajímá o technické záležitosti, které fascinují nás. Nicméně naše odpovědi jsou šité pro lidi, kteří takový zájem mají, a jsou připraveni se aktivně účastnit řešení daného problému. To se nezmění – a není ani proč. Jenom bychom se zhoršili v tom, co nám jde nejlépe.

Většina z nás jsou dobrovolníci. Taky máme spoustu práce, a najdeme si čas na zodpovídání otázek – které nás občas zavalují. Takže nemilosrdně filtrujeme. Zvláště zahazujeme otázky od loserů, abychom mohli svůj čas strávit plodněji nad otázkami těch ostatních.

Pokud vás takový postoj uráží nebo vám přijde arogantní, blahosklonný, či prostě nepřijatelný, zamyslete se nad svým postojem. Nemusíte se před nikým klanět – většina z nás bude upřímně jednat jako s rovným členem vlastní kultury s každým, kdo se bude trochu snažit. Je prostě marné snažit se pomoci někomu, kdo se nesnaží pomoct si sám. Nevědět – to je v pořádku. Dělat blbého v pořádku není.

K získání pozornosti není nutné mít patřičné technické schopnosti, zato je nutné projevit postoj, který ke schopnostem vede – pohotovost, přemýšlivost, pozornost, pečlivost. Pokud to považujete za diskriminaci, nežádejte osobní pomoc – můžete si přeci zaplatit technickou podporu.

Pokud si jdete pro pomoc, neměl byste vypadat jako loser. Nejlepší způsob, jak získat rychlou odpověď, je ptát se směle jako člověk, který chápe, jen prostě potřebuje s touto konkrétní věcí pomoci.

(Veškeré zlepšovací návrhy vítáme. Pište na esr@thyrsus.com. Tento text však není zamýšlen jako obecný průvodce netiketou, a přijímají se pouze návrhy ohledně získávání užitečných odpovědí na technické dotazy.Poznámka překladatele: připomínky směřujte pochopitelně anglicky k anglickému originálu, a to k aktuální verzi – překlad může být zpozdilý.)

Než se zeptáte

Než začnete klást otázky mailem nebo v news nebo na webovém fóru,

1. zkuste najít odpověď na webu.
2. zkuste najít odpověď v manuálu.
3. zkuste najít odpověď ve FAQ.
4. zkuste najít odpověď experimentováním.
5. zkuste se zeptat zkušenějšího kamaráda.
6. zkuste odpověď zjistit ze zdrojového kódu (jste-li programátor).

Když se ptáte, ukažte, že jste to už zkusili – ukážete, že nejste lenoch a příživník plýtvající cizím časem. Ještě lépe: ukažte, že jste se z dosavadních snah poučili. Rádi odpovídáme těm, kteří se z odpovědí poučí.

Zkuste najít text své chybové hlášky v Google. Možná se dostanete přímo na ten odstavec v dokumentaci nebo příspěvek v konferenci, který vaši otázku zodpoví. A i když ne, je lepší, když pak můžete do mailu napsat „Hledal jsem v Google, ale nic pořádného jsem nenašel“.

Svou otázku si připravte a promyslete. Na ukvapené otázky dostanete jen ukvapené odpovědi (nebo žádné). Čím víc bude znát, že jste se pokusili problém vyřešit ještě předtím, než jste se rozhodli žádat o pomoc, tím spíše se vám pomoci skutečně dostane.

Pozor na špatně položené otázky. Pokud se ptáte na základě špatných předpokladů, Hackerovic Lojza si nejspíš řekne „blbost …“ a odpoví zcela nepoužitelným doslovným řešením, které vaše otázka implikuje. Místo toho, co jste potřebovali, dostanete to, oč jste žádali.

Nepředpokládejte, že máte na odpověď nárok. Nemáte; koneckonců za ni nikomu neplatíte. Odpovědi se vám dostane, je-li vaše otázka zajímavá, podstatná nebo stimulující – taková, která nakonec prospěje všem zúčastněným a přispěje ke zkušenostem celé komunity, narozdíl od otázky, která pouze tahá rozumy z ostatních.

Je dobré ukázat, že jste sami připraveni pomoci při řešení problému. Spíše se dostane odpovědi otázkám „Mohl byste mě někdo nasměrovat?“, „Co mému příkladu chybí?“ a „Co bych si měl přečíst?“, než „Prosil bych přesný postup“, protože dáváte najevo, že jste připraveni dotáhnout věc do konce, když vám někdo ukáže kudy.

Když se ptáte

Zvolte pečlivě, koho se zeptat

Citlivě uvažte, kde se zeptat. Odpovědi se nejspíš nedočkáte (nebo s vámi rovnou bude zacházeno jako s loserem), pokud:

• pošlete svou otázku někam, kde se probírá jiné téma
• pošlete velmi elementární otázku do fóra, kde se probírají pokročilé technické detaily, nebo naopak
• pošlete svou otázku zároveň na několik různých míst
• pošlete svou otázku osobně někomu, koho neznáte, a kdo za váš problém nikterak nezodpovídá.

Špatně mířené otázky většinou hackeři zahazují, aby uchránili komunikační kanály před záplavou podružností. To si jistě nepřejete.

Prvním krokem je tedy zvolit pro svou otázku správné fórum. Google a prohledávání webu vůbec vám pomůže najít stránky projektu, který se vašich problémů týká co možná nejvíc. Obvykle tam najdete i odkazy na FAQ (= frequently asked questions, často kladené otázky), mailing listy a jejich archivy. Mailing list je ta poslední instance, pokud vaše vlastní snahy (včetně pročtení FAQ) selžou.

Vypálit svou otázku do neznáma je přinejmenším riskantní. Nepředpokládejte například, že se autor nějaké informační stránky chce stát vaším osobním poradcem. Nepředpokládejte ani, že vaše otázka je vítána. Pokud si nejste jisti, pošlete ji radši jinam, nebo neposílejte nic.

Při výběru vhodného mailing listu nebo newsgrupy se příliš nespoléhejte na jejich název; přečtěte si něco ze starších dotazů a odpovědí, ať víte, že jste na správném místě; případně zjistíte, jak to tam chodí. Správné je vyhledat ještě před odesláním otázky klíčová slova v archivu: když nezískáte přímo odpověď, dojdete třeba k lepší formulaci problému.

Ujasněte si své téma! Klasickou chybou je klást obecné programátorské otázky (řekněme vůči UNIXu či Windows) v konferenci věnované nějakému konkrétnímu jazyku či knihovně (která je portována na oba systémy). Pokud nechápete, proč je to chyba, radši nikam nepište, dokud to nepochopíte.

Obecně platí, že otázka veřejně zaslaná do správně vybraného fóra má mnohem větší šanci na odpověď než tatáž otázka zaslaná soukromě. Jednak si ji přečte víc lidí, jednak má i případná odpověď větší publikum. Hackeři radši zodpoví takovou otázku, která poučí mnohé, než takovou, která poslouží jen pár lidem.

Schopní hackeři a autoři oblíbeného softwaru dostávají spoustu špatně adresovaných zpráv. Pokud se k této záplavě přidáte, můžete se v krajním případě stát poslední kapkou – několikrát už přispěvatelé oblíbených projektů zcela zrušili uživatelskou podporu, protože objem zbytečných zpráv v osobní komunikaci byl neúnosný.

Nejrychleji najdete odpověď na webu nebo IRC kanálu pro nováčky

Vaše místní user group nebo Vaše linuxová distribuce má webové fórum nebo IRC kanál zřízený speciálně pro nováčky. To je dobrý první pokus, obzvláště pokud narazíte na nějaký jednoduchý problém. Na IRC kanálu možná dostanete odpověď obratem.

Pokud Vás zlobí nějaký program z konkrétní distribuce, možná bude lepší obrátit se nejdříve na fórum/maillist té které distribuce, a nikoli přímo na autory. Ti Vám nejspíše řeknou: „No tak použijte naší verzi.“

Než do webového fóra napíšete, poohlédněte se po nějakém vyhledávacím formuláři – pokud tam mají vyhledávání, zkuste nejdříve svůj problém najít v archivu. Pokud jste již hledali obecně na webu, stejně to zkuste i tady – možná, že Váš vyhledávač ještě nemá celé toto fórum zindexované.

Čím dál více projektů začíná pro podporu uživatelů používat web nebo IRC (a ponechává mailing listy jako nástroj komunikace vývojářů). Pokud se tedy Váš dotaz týká nějakého konkrétního projektu, zkuste nejdříve toto.

Jako druhou možnost použijte mailing list

Pokud má projekt svůj uživatelský mailing list, používejte ho – adresu najdete v dokumentaci nebo na webových stránkách projektu. Nepište jednotlivým vývojářům, i když si myslíte, že přesně víte, kdo by vaši otázku nejspíš zodpověděl. Je k tomu několik dobrých důvodů:

1. Problém, který stojí za otázku na vývojáře, má svou hodnotu pro celou skupinu uživatelů. Pokud se naopak obáváte, že vaše otázka je příliš hloupá na to, abyste ji posílali do mailing listu, nemá cenu obtěžovat s ní jednotlivé vývojáře.
2. Dotazy položené v mailing listu se přirozeně rozloží mezi jednotlivé vývojáře. Naproti tomu jednotlivec (obzvláště vedoucí projektu) bude nejspíše dosti zaneprázdněn.
3. Mailing listy jsou archivovány a dají se zpětně prohledávat. Takže další tazatel už případnou odpověď najde v archivu a nemusí se ptát znovu.
4. Pokud se jisté otázky stále opakují, pomůže to vývojářům sepsat lepší dokumentaci nebo vylepšit samotný software. Pokud se ptáte jednotlivců, nikdo nemůže mít kompletní přehled o tom, na co se uživatelé nejčastěji ptají.

Pokud má projekt jak „uživatelský“, tak „vývojářský“ mailing list, pište nejdříve do uživatelského – pakliže se aktivně nepodílíte přímo na psaní kódu. Na vývojářském listu byste nejspíše obtěžovali.

Pokud jste si nicméně jisti, že vaše otázka je závažná, a na uživatelském listu se Vám několik dní nedostalo odpovědi, zkuste vývojářský list. Než tam ale napíšete, porozhlédněte se, jak to tam chodí – to se ostatně týká každého (polo)soukromého mailing listu.

Pokud se vám nedaří najít adresu mailing listu, ale znáte adresu vedoucího projektu, napište mu. Nepředpokládejte však, že mailing list neexistuje – napište, že jste se ho pokusili najít, ale nenašli. Zmiňte se rovněž, že vám nevadí, bude-li vaše zpráva přeposlána dalším lidem. (Mnoho lidí má za to, že osobní korespondence je přísně soukromá, i když neobsahuje nic tajného. Dáte-li korespondentovi možnost zprávu přeposílat, může se teprve rozhodnout, jak s vaším mailem naloží).

Použijte smysluplný, výstižný „Subject:“

Hlavička „Subject:“ vám dává možnost upoutat pomocí padesáti písmen pozornost kvalifikovaného odborníka. Takže ji nepromarněte bláboly typu „pomozte prosím“ (natožpak „POMOC!!!!! PROSÍM!!!!!!“ – takové zprávy se rovnou mažou). Nesnažte se nikoho dojmout svým trápením, ale pregnatně vyslovte svůj problém.

Užitečnou konvencí je používat „Subject:“ tvaru „téma – problém“, přičemž „téma“ popisuje, které věci se problém týká, a „problém“ je popis chyby. Například:

• Špatně: POMOC! Nefunguje mi na laptopu grafika!
• Dobře:Deformovaný kurzor v XFree86 4.1, chipset Fooware MV1005
• Lépe: Kurzor v XFree86 4.1 s chipsetem Fooware MV1005 – je deformovaný

Takový popis usměrňuje tok myšlenek směrem k podstatným detailům: co je přesně špatně? Jenom kurzor, nebo i ostatní grafika? Týká se to výhradně XFree86? Ve verzi 4.1? Speciálně s chipsetem Fooware? Model MV1005? Je hned vidět, s čím máte problém, a jaký přesně je to problém.

Představte si, že se obsah archivu zobrazuje jen jako řádky se Subjectem. Napište svůj subject tak, aby další člověk se stejným problémem mohl jít vyšlapanou cestou, a nemusel se ptát znovu na totéž.

Pokud v odpovědi kladete další otázky, změňte Subject zprávy tak, aby bylo jasné, že obsahuje další otázky. Subject jako „Re: test“ asi nikoho nezaujme. Rovněž ocitujte relevantní části předchozí korespondence, aby se mohli zapojit i nově příchozí.

Chcete-li v mailing listu začít novou debatu, nezačínejte odpovědí na některou z předchozích zpráv – omezíte své publikum. Některé poštovní programy (např. mutt) umožňují řadit zprávy do threadů („vláken“ vzájemně navazujících zpráv) a tyto thready vizuálně „zabalit“. Takoví uživatelé vaši zprávu nikdy neuvidí.

V takovém případě nestačí ani změnit Subject – zprávy se threadují i podle jiných hlaviček. Začněte zbrusu novou zprávou.

Na webových fórech je situace trošku jiná: zprávy jsou často úzce svázány s konkrétním threadem, a mimo něj se nezobrazují. V takovém případě není nutné měnit subject, když kladete další otázky (ostatně některá fóra to ani neumožnují). Nicméně další otázky, položené v odpovědích, uvidí jen ti, kteří už současný thread sledují. Pokud si tedy nejste jisti, že se chcete zeptat stávajícího publika, začněte nový thread.

Odpovědět musí být snadné

Končí-li vaše zpráva slovy „Odpovězte mi prosím na adresu …“, nejspíše žádnou odpověď nedostanete. Pokud nevěnujete ani těch pár vteřin tomu, abyste si správně nastavili „Reply-To:“, těžko bude někdo věnovat čas vašim problémům. Pokud to váš poštovní program neumožňuje, pořiďte si lepší. Pokud pro váš operační systém takové programy nejsou, pořiďte si lepší operační systém.

Žádat na webovém fóru separátní odpověď emailem je vyložená nevychovanost, pakliže se nejedná o nějaké citlivé informace. Chcete-li být mailem upozorněni na odpověď, použijte přímo funkcí toho webového fóra – většinou máte možnost „sledovat tento thread“ nebo „odebírat odpovědi“.

Pište jasně, spisovně a bez překlepů.

Zkušenost nás učí, že ledabylí a nepozorní pisatelé většinou také nedbale uvažují (a programují). Odpovídat takovým je k ničemu. Radši budeme dělat něco jiného.

Vyjádřit se přesně a jasně je velmi důležité. Pokud vám to nestojí za námahu, nám to nestojí za pozornost. Svůj jazyk pečlivě pročistěte. Nemusí být upjatý či formální – hackeři spíše ocení neformální, slangový, vtipný jazyk, pakliže se v něm vyjadřujete přesně. Váš zájem a soustředění musí být zřejmé.

Používejte správně interpunkci a velká písmena. Nepište VŠECHNO KAPITÁLKAMI – to se považuje za psanou formu křiku a za protivnost. (Všechna malá nejsou o moc lepší, protože se špatně čtou. Alanu Coxovi to projde, ale vám ne.)

Obecně vzato, píšete-li jako pologramotné nemehlo, budou vás ignorovat. Odezvou na projev někoho, kdo se vyjadřuje jako fuckt d0st wostrey týpeck, bývá jen ticho (nebo posměch).

Ptáte-li se ve fóru, kde se mluví cizím jazykem, jistě vám prominou nějakou tu chybu v pravopise, ale lenost vám promíjet nebudou (a ten rozdíl se pozná). Dále, pokud nevíte, kterou řečí adresát(i) mluví, pište anglicky. Zprávu v jazyce, kterému nerozumí, každý hned smaže; a jazykem internetu je angličtina.

Posílejte otázky ve snadno přístupných formátech

Pokud uměle ztížíte čitelnost své otázky, nejspíš bude přeskočena ve prospěch nějaké čitelnější. Proto:

• Posílejte čistě textové maily (plain text), žádné HTML. Vypnout HTML není těžké.
• MIME přílohy jsou v pořádku, pakliže jsou opravdu k věci (přiložený zdrojový kód a podobně), a nejsou jen balastem vašeho poštovního programu (jako např. další kopie těla zprávy).
• Neposílejte maily, ve kterých jdou odstavce bez zalomení přes několik řádek. (Je složité odpovídat na části takového textu.) Předpokládejte, že váš mail bude číst někdo, kdo má čistě textový terminál, široký 80 znaků, a zalamujte podle toho řádky (tj. dříve než na osmdesátém znaku).
• Data (jako např. výstupní logy programů a chybová hlášení) naopak vůbec nezalamujte. Posílejte je tak jak jsou, ať má čtenář stejnou informaci, jakou vidíte vy.
• Nepište do anglicky mluvících konferencí s diakritikou. To je samozřejmě potřeba, pokud píšete jazykem, který se nevejde do ASCII, ale mnoho poštovních programů tato kódování neumí. A všechna ta „=20“ roztroušená po textu jsou opravdu hnusná.
• V žádném případě nečekejte, že se hacker bude snažit přečíst nějaký uzavřený proprietární formát, jako třeba Microsoft Word. Většina bude reagovat asi tak jako vy, kdyby vám někdo na práh vyklopil kýbl hnoje.
• Píšete-li z počítače, na kterém běží Windows, rozhodně vypněte stupidní „Smart Quotes“. Ve vašem mailu ubyde zbytečného balastu.
• Na webových fórech nezneužívejte „smajlíky“ a možnosti html – pokud je Vaše zpráva plná :-))))))) a barevného textu, čtenáři si řeknou, že jste blbeček nebo chichotající se šestnáctka (což vám možná dopomůže k sexuálním zážitkům, ale ne k odpovědím).

Používáte-li nějaký grafický poštovní program (Netscape Messenger, MS Outlook a tahle sorta) s jejich standardním nastavením, nejspíš některé z těchto pravidel porušujete. Tyto programy mívají funkci „View source (Zobrazit zdrojový text)“ – vyzkoušejte na svých odeslaných mailech, zda skutečně odesíláte jen čistý text, bez zbytečného balastu.

Popište problém co nejpřesněji

1. Popište příznaky problému nebo chyby co možná nejjasněji a nejpečlivěji.
2. Popište prostředí, ve kterém chyba nastává, tj. architekturu, operační systém, aplikaci, verzi, atd. Jmenujte distribuci a verzi systému (např. Red Hat 8.0, Slackware 5.1, atd.).
3. Popište, jak jste se k chybě dostali, a jak jste se ji pokusili odhalit, isolovat a pochopit ještě předtím, než jste se zeptali.
4. Popište relevantní změny v konfiguraci, které jste v poslední době provedli.
5. Pokuste se už předem zodpovědět případné doplňující otázky.

Simon Tatham napsal výborný článek o tom, jak správně hlásit chyby. Vřele doporučuji.

Množství není přesnost

Je třeba vyjádřit se přesně. K tomu nestačí zakomponovat do otázky obrovské množství kódu nebo dat. Posíláte-li rozsáhlý test, demonstrující chybu programu, pokuste se ho ořezat na co nejmenší konzistentní část.

Jsou pro to alespoň tři dobré důvody. Za prvé: snaha zjednodušit otázku vám spíše zaručí odpověď; za druhé: zjednodušení otázky spíše zaručí užitečnou odpověď; za třetí: při zjemňování vlastní otázky možná přijdete na odpověď sami.

Netvrďte, že jste našli chybu

Pokud máte problémy s nějakým softwarem, netvrďte hned, že jste našli chybu, pakliže si nejste opravdu jisti. Pokud zároveň nezasíláte opravu zdrojového kódu nebo zpětně ověřitelný test, který chybu demonstruje, pak si patrně jisti nejste.

Uvědomte si, že spousta lidí daný software používá, aniž by k takové chybě docházelo. Jinak byste na ni přišli už při čtení dokumentace nebo byste našli její popis na webu (což jste jistě zkusili ještě předtím, než jste se začali ptát, nebo ne?). Takže chyba je nejspíš na vaší straně, nikoli v programu.

Lidé, kteří ten software napsali, si dali velmi záležet na tom, aby fungoval nejlepším možným způsobem. Tvrdíte-li, že jste našli chybu, znamená to, že tu chybu udělali oni – což se jich většinou dotkne, i když máte pravdu. Zvláště nediplomatické je hulákat CHYBA! už v Subjectu.

Pište svůj dotaz raději z pozice toho, kdo podezřívá z chyby nejdřívsebe, i když si jste celkem jisti, že je to opravdu chyba softwaru. Pokud je to opravdu tak, v odpovědi se o tom jistě dočtete. Vývojář se nejspíš bude chtít omluvit – což je lepší než dlužit mu omluvu za vlastní zmatky.

Servilita vás neomlouvá z domácích prací

Někteří z těch, kteří vědí, že by otázka neměla působit neurvale či arogantně, se uchylují k opačnému extrému – ke skuhrání. Vím, že jsem jen ubohý začátečník a loser, ale …. Tím ničemu nepomůžete. Zvláště protivné je to ve spojení s vágně položenou otázkou.

Nemarněte svůj (ani náš) čas takovou neomalenou politikou. Raději co nejjasněji popište situaci a svůj problém.

Na webových fórech bývá speciální sekce pro nováčky – je-li tedy vaše otázka začátečnická, jděte rovnou sem. Ale ani tady neskuhrejte.

Popište příznaky problému, nikoli vlastní dohady

Nepovídejte hackerům, kde jsou příčiny vašich problémů. (Ptají se takoví machři, co to hned poznají, ostatních na radu?) Spíše než svoje teorie a interpretace jim popište příznaky problému. Diagnostika je na nich.

Špatně:

Při kompilaci jádra dostávám divné segfaulty, a něco se mi nepozdává na motherboardu: asi nějaký přerušený spoj. Jak to mám zkontrolovat?

Dobře:

Postavil jsem si K6/233 na motherboardu FIC-PA2007 (chipset VIA Apollo VP2) s 256MB Corsair PC133 SDRAM. Asi dvacet minut po bootu začínám dostávat segfaulty při kompilaci jádra; během prvních dvaceti minut nikdy ne. Po vypnutí přes noc se vyresetovaly hodiny, při rebootu ne. Vyswapovat celou paměť nijak nepomohlo. Následuje log typického případu.

Popište příznaky problému chronologicky

Nejužitečnější nápovědou při nějaké chybě bývá to, co bezprostředně předcházelo. Popište tedy přesně, co jste udělali, jak program odpověděl, a tak dále až k selhání programu. V případě textových programů, komunikujících pomocí příkazové řádky, je velmi užitečné přiložit záznam posledních – řekněme – dvaceti řádek (např. pomocí programu script).

Má-li program nějakou vnitřní diagnostiku (typicky -v jako verbose), zvažte pečlivě, které informace k záznamu přidat.

Pokud je nakonec popis chyby dlouhý (řekněme více než čtyři odstavce), může být užitečnější precizně zformulovat problém hned na začátku a pokračovat podrobnostmi. Čtenář pak ví, na co se při četbě soustředit.

Popište cíl, nikoli dílčí krok

Pokud zjišťujete, jak se udělá to či ono, hned na začátku popište svůj cíl. Teprve poté popisujte dílčí krok, který se vám nedaří.

Lidé hledající technickou pomoc mají často na mysli nějaký konečný cíl, a problémy mají s něčím, co považují za jeden z dílčích kroků vedoucích k tomuto cíli. Ptají se na radu ohledně tohoto kroku, a přitom třeba nevědí, že jdou po úplně špatné cestě.

Špatně:

Jak se ve FooDraw zjišťují RGB hodnoty barev?

Správně:

Snažím se nahradit tabulku barev jistého obrázku vlastními barvami. Nevidím jinou cestu než přepsat postupně všechny záznamy v tabulce, ale nedaří se mi ve FooDraw získat RGB hodnoty příslušných barev.

Druhá verze otázky je lepší – odpověď může obsahovat návrh na úplně jiné řešení úkolu.

Nežádejte soukromou odpověď

Hackeři jsou přesvědčeni, že řešení problémů má být věc veřejná a transparentní. Pokud si někdo další všimne, že odpověď je neúplná či chybná, může (a měla by) být doplněna či opravena. Rovněž je jim odměnou jistý kredit, který získají u kolegů, když dokáží kompetentně zodpovídat otázky veřejnosti.

Soukromá odpověď znemožňuje obojí. Nedělejte to. Je věcí odpovídajícího, jestli odpoví soukromě – a pokud ano, bude to nejspíš proto, že otázka není dost zajímavá pro ostatní.

Existuje jedna výjimka: je-li otázka taková, že lze očekávat mnoho navzájem podobných odpovědí, použijte kouzelná slůvka „odpovídejte na soukromý mail, shrnu pak odpovědi veřejně“. Je slušností ušetřit mailing list záplavy téměř identických odpovědí – ale musíte svůj slib dodržet.

Řekněte jasně, co chcete

Otázky s otevřeným koncem jsou jako časová výlevka (s otevřeným koncem). Lidé, kteří by mohli nejspíše zodpovědět váš dotaz, jsou většinou zároveň ti nejzaneprázdně­nější. Bývají alergičtí na časové výlevky – a na otázky s otevřeným koncem.

Užitečnou odpověď dostanete tím spíše, čím jasněji řeknete, co po adresátech vlastně žádáte (poučit vás o dokumentaci, poslat kód, vyzkoušet vaši opravu, reprodukovat chybu, cokoli). Jejich snaha získá jasný cíl a získají jistou horní mez pro odhad investované energie a času. Což je dobře.

Zkuste si představit odbornost jako hojně se vyskytující materiál a čas jako vzácnou bylinu. Čím menší časovou investici žádáte, tím spíše se vám dostane odpovědi od někoho skutečně schopného (a zaneprázdněného).

Je užitečné postavit otázku tak, aby se dala zodpovědět co nejrychleji – což není totéž jako otázku zjednodušit. Například: „Poradil byste mi, kde najdu dobré vysvětlení pro X?“ je lepší než „Vysvětlete mi prosím X“. Nebo: máte-li nějaký nefunkční kód, je lepší zeptat se, proč nefunguje, než žádat opravu.

Neptejte se na domácí cvičení

Hackeři většinou bezpečně rozeznají domácí úkoly – většina z nás je sama řešila. Tyto otázky si máte vyřešit sami, a poučit se. Můžete se samozřejmě zeptat na radu, ale nežádejte po nikom řešení základních věcí.

Pouze tehdy, pokud nedokážete s úlohou hnout, zkuste se zeptat. Otázka bude nepochybně odhalena jako domácí cvičení, ale možná Vám někdo naznačí směr.

Zbytečné otázky v kriminalistice

Odolejte pokušení uzavřít svou žádost bezvýznamnými otázkami jako „Mohl by mi prosím někdo pomoci?“ nebo „Neznáte nějaké řešení?“ Takové otázky jsou přinejlepším nadbytečné. Jelikož jsou nadbytečné, mají je hackeři za otravné – a mají sklon odpovídat na ně logicky bezchybnými větami typu „Ano, někdo Vám možná pomůže“ nebo „Ne, bohužel Vám není pomoci“.

Obecně vzato, neklaďte otázky typu ano-ne, pokud skutečně nežádáte odpověď typu ano-ne.

Neoznačujte svůj problém za „urgentní“ (i když pro vás třeba je)

To je přeci váš problém, ne náš. Většina hackerů takovou zprávu smaže jakožto sobecký pokus vyloudit si speciální pozornost.

Existuje výjimka: když svůj problém řešíte na nějakém důležitém místě, které hackery zaujme; v takovém případě, pokud vás opravdu tlačí čas, a slušně požádáte, mohl by někdo skutečně odpovědět o něco rychleji.

Ovšem zdaleka to není jisté, protože hackerův žebříček „zajímavosti“ je patrně jiný než váš. Zprávě z mezinárodní orbitální stanice se jistě dostane promptní odpovědi, zato dobře myšlené charitativní (nebo politické) pobídce nejspíš ne. Napíšete-li Urgentní: Zachraňte nebohá tuleňátka!, pravděpodobně se vám vyhnou i ti, kteří považují nebohá tuleňátka za důležitou věc.

Pokud vám to přijde divné, čtěte si tento návod pořád dokola, dokud mu neporozumíte, a pak se teprve ptejte.

Zdvořilost neškodí, a občas i pomáhá

Buďte zdvořilí: „prosím“, „děkuji za pozornost“ atd. Važte si času, který je vám zdarma věnován.

Popravdě řečeno, zdvořilost není tak důležitá jako přesnost, jasný, popisný jazyk, vyhýbání se uzavřeným formátům atd. (a nemůže je nahradit); hackeři raději dostávají lehce břitké, zato však technicky přesné zprávy, než zdvořilé plky. (Přijde-li vám to divné, pamatujte, že hodnotíme otázku podle toho, co nás naučí.) Nicméně, je-li zpráva technicky v pořádku, zdvořilost zvýší vaše šance.

Zašlete stručnou zprávu o úspěšném řešení.

Poté, co problém vyřešíte, zašlete zprávu všem, kteří vám pomohli. Povězte jim, jak to odpadlo, a poděkujte. Pokud si problém získal veřejný zájem, měli byste zaslat zprávu do mailing listu.

Odpověď by měla navazovat na thread s původní otázkou, a Subject by měl obsahovat „VYŘEŠENO“ (SOLVED, FIXED) či podobně. Tam, kde je provoz dostatečně rychlý, si čtenář threadu „Problém X“ hned všimne zprávy „Problém X – VYŘEŠENO“ a nemusí číst celý thread (pakliže ho ovšem problém X nezaujme), a ušetřený čas může věnovat řešení jiných problémů.

Vaše závěrečná zpráva nemusí být dlouhá – lepší něco než nic; „Zdravím, nakonec to bylo špatným kabelem. Díky. Pepa“. Nakonec je krátké shrnutí lepší než detailní elaborát (pakliže se ovšem nejedná o skutečně hluboký problém). Sdělte ostatním, co přesně pomohlo, nemusíte celý problém rekapitulovat.

U hlubších otázek je správné zaslat shrnutí postupných snah a oprav. Popište výsledné řešení, jakož i slepé cesty (to ovšem až po správném řešení – nemá to být detektivka). Jmenovitě poděkujte řešitelům. Nakonec si ještě získáte nové přátele.

Taková závěrečná zpráva dá všem zúčastněným pocit zdárně vyřešeného problému. Pokud sám nejste technický typ či hacker, věřte, že tento pocit je pro odborníky, kterých se ptáte, velmi důležitý. Problémy vedoucí do neznáma nebo nikam je frustrují a svědí. Pokud jim toto svědění poškrábete, získaná dobrá karma vám u příští otázky může hodně pomoci.

Považte, jak byste mohli ostatním tento problém v budoucnu ušetřit; zda by nebylo dobré rozšířit či upravit dokumentaci. Pošlete takovou opravu správci dokumentace.

Mezi hackery je takové chování uznávanější než tradiční zdvořilost. Takto se získává reputace toho, kdo hraje s ostatními, což je výrazné aktivum.

Jak interpretovat odpovědi

RTFM a STFW, aneb jste úplně mimo

Existuje dávná a uctívaná tradice: dostanete-li odpověď „RTFM“, znamená to, že si máte Read The Fucking Manual, neboli že si máte, kurva, přečíst manuál. Což je nejspíš pravda. Jděte si ho přečíst.

RTFM má mladšího sourozence: opdověď „STFW“ znamená, že byste měli Search The Fucking Web, neboli podívat se, kurva, na web. Což je nejspíš pravda. Jděte hledat.

Často má člověk, který vám takto odpovídá, manuál či příslušnou stránku přímo před očima. Taková odpověď znamená, že podle jeho názoru je (a) velmi snadné kýženou informaci najít (b) mnohem užitečnější najít ji sám než ji dostat od maminky na talířku.

Nemusíte se kvůli tomu urážet; dle měřítek platných mezi hackery vám vlastně projevuje svého druhu respekt, když vaší otázku neignoruje. Měli byste mu spíš poděkovat.

Pokud odpovědi nerozumíte

Pokud odpovědi nerozumíte, nepište si rovnou pro vysvětlení. Stejnými metodami, kterými jste hledali odpověď na svou původní otázku, se pokuste najít i vysvětlení odpovědi. Pokud se i pak potřebujete ještě zeptat, ukažte opět, že jste se poučili.

Dostanete-li například odpověď „Nejspíš Vám podpěra šprajcla trakci – zkuste jí prošťouchnout“, pak typická špatná reakce je „Co je to podpěra?“. Mnohem lepší je: „V manuálu se o podpěrách píše jen v kapitole o karbidových hořácích, ale o prošťuchování tam nic není. Nebo jsem něco přehlédl?“.

Jak zvládat neurvalost

To, co často vypadá jako arogance či nezdvořilost, není většinou myšleno nijak zle. Mnohem spíše je to jen produktem komunikace jdoucí přímo skrze řečičky – která je přirozená pro lidi, které spíš zajímá řešení problému než to, jestli se i všichni ostatní cítí dobře a příjemně.

Dostane-li se vám neurvalé odpovědi, snažte se zůstat v klidu. Pokud někdo opravdu vyvádí, nejspíše mu někdo z místních domluví. Pokud se tak nestane, a vy ztratíte nervy, dost možná to dopadne tak, že on se choval jak je v kraji zvykem, a někdo domluví vám. Tím klesají vaše šance získat to, proč jste původně přišli.

Na druhou stranu, občas narazíte na nezaslouženou a bezdůvodnou obhroublost. V takovém případě je zcela v pořádku drzouna proplesknout, a jeho drzosti natrhnout ostrým verbálním hákem. Nicméně, než to uděláte, buďte si zcela jisti, že jste v právu. Hranice mezi usměrněním nezdvořáka a vyhlášením zbytečné slovní války je dosti tenká, a hackeři ji nezřídka sami překračují. Jste-li nováček nebo cizinec, nejspíš se vám to stane velmi snadno. Pokud jste přišli pro informace a ne pro zábavu, raději od klávesnice dál.

(Někteří lidé tvrdí, že hackeři trpí lehčí formou autismu či Aspergerova syndromu, to jest nefungují u nich jisté základní modely „normálního“ chování. Možná ano, možná ne. Pokud nejste sám hacker, snad vám to pomůže vypořádat se s naší výstředností, když si budete myslet, že jsme postižení. Jak je libo. Nám je to jedno; my jsme rádi tím, čím jsme; k těmto nálepkám máme zdravě skeptický postoj.)

V dalším odstavci pohovoříme o poněkud odlišném tématu: o „nerudnosti“, kterou si můžete vysloužit svým vlastním vyváděním.

Nechovat se jako loser

Asi se vám párkrát stane, že se v hackerské komunitě ocitnete zcela mimo mísu – právě tak, jak to popisujeme v tomto článku, nebo podobně. A bude vám to dáno patřičně najevo, možná velmi květnatě. A to veřejně.

Když se to stane, nejhorší je naříkat, jak vám bylo ublíženo, vyžadovat omluvu, vyhrožovat žalobami, stěžovat si u zaměstnavatele, nechávat prkýnko nahoře, atp. Radši udělejte toto:

Povzneste se nad to. Je to normální. A snad i zdravé.

Komunitní zvyklosti se neudržují samy: jsou dány tím, že se jimi lidé řídí, že je viditelně a veřejně aplikují. Neskuhrejte, že se má osobní kritika vyřizovat soukromou poštou – tak to prostě nefunguje. Stejně tak je k ničemu označovat za osobní urážku, když někdo vyvrací vaše tvrzení, nebo má prostě jiný názor. To je loserský přístup.

Existují i veřejná fóra, kde je v zájmu jakési hyperzdvořilosti vůbec zakázáno zasílat zpochybňující zprávy, a pravidlo zní „Pokud nehodláte uživateli pomoci, neříkejte vůbec nic“. Následným přesunem schopných přispěvatelů jinam se z nich stávají bezvýznamné snůšky blábolů a jako technická fóra jsou k ničemu.

Pamatujte: když vám ten hacker říká (jakkoli drsně), že jste mimo, a ať už to neděláte, říká vám to (1) ve vašem zájmu a (2) v zájmu své komunity. Mnohem jednodušší by bylo vás prostě ignorovat. Mějte trochu důstojnosti, nefňukejte, a nečekejte, že s vámi někdo bude jednat jako se slečinkou, protože jste nováček s citlivou dušičkou.

Otázky, které se nekladou

Ukázka klasických stupidních otázek, a co si o nich hackeři myslí.

• Kde bych našel X?
• Tam kde já, blbečku – proboha, copak ještě někdo nezná Google?!
• Jak se Xem udělá Y?
• Pokud chceš udělat Y, tak při otázce nepředpokládej, že se to dělá Xem. Takoví lidé většinou nejenže nevědí o nic o X, ale ani neznají svůj problém Y. Většinou je nejlepší počkat, až se zeptají lépe.
• Jak si mám nakonfigurovat shell?
• Pokud jsi dost chytrý na to, aby ses ptal na takové věci, jistě také zvládneš RTFM a přijdeš na to sám.
• Dají se Mega-Convertorem konvertovat soubory z UltraOffice do TeXu?
• Zkus to a uvidíš. Kdybys to zkusil hned, pak bys (a) zjistil odpověď sám, (b) neplýtval mým časem.
• Můj program / konfigurák / příkaz nefunguje.
• To ani není otázka. Nebudu s tebou hrát vadí-nevadí; mám lepší věci na práci. Obvyklou odpovědí na takový dotaz bývá:
  • Ještě něco?
  • Hmm, tak to je špatný. Snad se to nějak spraví!
  • A se mnou to má společnýho co?
• Mám nějaký pokažený Windows. Co mám dělat?
• Vyhoď tu sračku a pořiď si nějaký operační systém, třeba BSD nebo Linux.
• Ten program nefunguje. Asi je v systému špatné X.
• Je samozřejmě možné, že jsi jako první odhalil nějakou zjevnou chybu v systémových voláních nebo knihovnách, které denně používají statisíce lidí, ale mnohem spíše jsi úplně mimo. Takováto kromobyčejná tvrzení si žádají mimořádně přesvědčivé důkazy. Měl bys to doložit vyčerpávající dokumentací a přesným popisem chyby.
• Nedaří se mi nainstalovat Linux a X. Nepomohl bys mi?
• Ne. Na to bych potřeboval u toho počítače sedět. Zeptej se v místní Linux user group. (Jejich seznam najdeš tady.)
• Jak se dá prolomit rootovské heslo / číst cizí pošta?
• Pokud chceš něco z toho udělat, jseš lump. Pokud přitom žádáš hackera o radu, jseš blbec.

Dobré a špatné otázky

Nakonec budeme ilustrovat dobré a špatné otázky na příkladech. Vždycky jedna dobře položená a jedna špatně položená otázka na stejné téma.

• Špatně:Kde bych našel něco o Krajáči Mléka?
  Ten si koleduje o STFW.
• Dobře: Hledal jsem na Google „Krajáč Mléka 2600“, ale nic užitečného jsem nedostal. Kde bych našel nějaký programátorský popis krajáčů?
  Tenhle už STFWoval, a zřejmě opravdu potřebuje pomoci.
• Špatně:Zdrojáky z foo-projektu se vůbec nezkompilují. Co s tím je?
  Předpokládá, že chybu udělali jiní, což je arogantní.
• Dobře: Nedaří se mi zkompilovat foo na Nulixu 6.2; četl jsem FAQ, ale o problémech na Nulixu tam nic není. Zasílám kompilační log. Dělám něco špatně?
  Popsal vývojové prostředí, přečetl FAQ, nepřipisuje své problémy chybě někoho jiného. Ten možná stojí za pozornost.
• Špatně: Mám problémy s myší. Mohl by mi někdo pomoci?
  „Jasně. Jestli se bojíš koček, mám i pastičky“. Delete.
• Dobře: Zkoušel jsem X, Y a Z na nefunkční myš Confuse-a-cat 68. Nepomohlo to, zkusil jsem A, B a C. Všimněte si toho divného pištění při C. Hužva asi rourácí, ale nebubří přitom zlemejže. Co bývá u těchto myší příčinou rourácení? Co mám ještě otestovat?
  Tenhle stojí za odpověď. Je schopen sám hledat řešení – nečeká na pomoc shůry.

U poslední otázky si všimněte jemného, ale podstatného rozdílu mezi „Poraďte mi co mám dělat“ a „Pomozte mi najít způsob, jak sám dojdu osvícení“.

Forma té poslední otázky je postavená na skutečné diskusi, která proběhla v srpnu 2001 na linux-kernel mailing listu (lkml). Ptal jsem se já.

Ptáte-li se takto, prokazujete respekt vůči schopnostem svých bližních, a rovněž úctu k jejich drahocenému času, když ukážete, které slepé cesty jste už vyzkoušeli.

Nakonec, když jsem všem poděkoval a pochvaloval si, jak jsme to pěkně rozlouskli, poznamenal někdo, že to není tím, že jsem na lkml „někdo“, ale protože jsem se správně zeptal.

Hackerská kultura je v jistém smyslu diktaturou meritokracie. Kdybych se choval jako pako, jistě by mě ignorovali. Z tehdejšího návrhu, abych tu historku sepsal formou návodu pro ostatní, vzešel tento článek.

(Poznámka překladatele: v originále se problém týká „motherboardu“, což v angličtině umožnuje jazykovou hru – nabídnout tazateli „přebalování a zásyp“. Bohužel česky „motherboard“ je asi „motherboard“; nebo „základní deska“. Proto tedy kočka a „myš“. ESR jistě nemá problém s rozchozením my­ši.)

Když se vám nedostane odpovědi

Když vám nikdo neodpoví, neberte si to osobně, že vám nemůžeme pomoci. Třeba to prostě nikdo neví. Neodpovědět je něco jiného než ignorovat otázku, i když zvenčí je jistě těžké to rozeznat.

Poslat svůj dotaz jednoduše znovu není dobrý nápad. To se bere jako zbytečné otravování.

Jsou i jiná místa, kde by vám mohli pomoci, často i lépe uzpůsobená potřebám nováčků. Kromě online diskusí existují i místní skupinky softwarových nadšenců, které se scházejí právě za účelem vzájemné pomoci, zvláště pak pomoci začátečníkům.

Existuje také spousta komerčních společností, malých i velkých, u kterých si můžete sjednat pomoc. Neděste se myšlenky, že byste za to měli platit! Koneckonců, když se vám porouchá motor, také ho vezmete do servisu, kde musíte za opravu zaplatit. I když jste software získali zadarmo, neznamená to přeci, že veškerá podpora bude také zdarma.

U oblíbeného a rozšířeného softwaru, jakým je třeba Linux, připadá na jednoho vývojáře třeba 10,000 uživatelů. Není prostě možné pomáhat deseti tisícům lidí. Pamatujte, že i když musíte za pomoc zaplatit, pořád platíte výrazně méně, než kdybyste si museli kupovat i software samotný (a podpora pro komerční software bývá ostatně dražší a horší než pro open source).

Jak odpovídat k užitku tazatele

Buďte přátelští. Když člověka stresuje nějaký problém, může působit jako otrava či blbec, i když není.

První nepravosti vyřiďte soukromě. Není třeba veřejně ponižovat někoho, kdo se v dobré víře třeba jen zmýlil. Úplný začátečník třeba ani neví, jak prohledávat archivy, že něco jako FAQ vůbec existuje, a kde.

Pokud si nejste jisti, řekněte to! Špatná, přitom odborně znějící rada, je horší než žádná. Nenavádějte nikoho na pochybné cesty jen proto, že chcete vypadat jako expert. Buďte poctiví; buďte dobrým příkladem tazateli i ostatním.

Nemůžete-li pomoci, nerušte. Nedělejte si legraci z něčeho, co může uživateli úplně rozhodit systém – nějaký ubožák se tím třeba bude řídit.

Klaďte doplňující otázky, chtějte detaily. Budete-li to dělat dobře, tazatel se něco naučí – a vy také. Zformulujte špatnou otázku dobře. Všichni jsme bývali začátečníci.

Odpovědět líné kůži RTFM je jistě v pořádku; odkaz na dokumentaci (třeba jen na Googlovský dotaz) je lepší.

Pokud už odpovídáte, poraďte správný postup. Nenavrhujte mazané triky, jak problém obejít, když někdo používá špatný postup. Navrhněte čisté řešení a správné nástroje. Přeformulujte otázku.

Pomozte ostatním poučit se. Narazíte-li na dobrou otázku, pouvažujte nad tím, jak by se dala současná dokumentace vylepšit, aby se nikdo nemusel ptát znovu. Pošlete takovou opravu správci dokumentace.

Pokud vás odpověď stála jisté úsilí a zkoumání, ukažte, jak jste toho dosáhli. Netvařte se, že jste odpověď vytáhli z klobouku. Zodpovědět otázku je jako nakrmit hladového – ukázat cestu vedoucí k odpovědi je jako naučit hladového hospodařit.

Související

Potřebujete-li radu o základních principech fungování počítačů, UNIXu a Internetu, přečtěte si The Unix and Internet Fundamentals HOWTO.

Pokud produkujete nějaký software nebo opravujete stávající, snažte se dodržovat postupy popsané v Software Release Practice HOWTO.