Bevezető

A hackerek világában a technikai kérdésekre kapott válasz legalább annyira függ a kérdés stílusától, mint az adható válasz nehézségi szintjétől. Jelen útmutató arról szól, hogyan kell úgy kérdezni, hogy a legkielégítőbb válaszokhoz jussunk.

A legfontosabb dolog, hogy a hackerek nagyon szeretik a bonyolult problémákat és az azokkal kapcsolatos jó, gondolkodásra serkentő kérdéseket. Ha nem így lenne, itt se lennénk. Egy érdekes kérdés – amin jól elrágódhatunk – hálára kötelez minket; a jó kérdés a hacker kábszere és jutalma. A jó kérdések fejlesztik az értelmünket, gyakran olyan problémákra világítanak rá, amely egyébként rejtve lennének előlünk. Hacker körökben a „jó kérdés!” kifejezés őszinte elismerést fejez ki.

Mindezek ellenére úgy hírlik, a hackerek gőgösen és ellenségesen állnak az egyszerű kérdésekhez. Úgy tűnhet, durvák vagyunk a kezdőkkel, és nem foglalkozunk velük – de ez nem egészen van így.

Ami viszont igaz, hogy ellentmondást nem tűrően ellenségesek vagyunk azokkal, akik maguk semmire sem hajlandóak a kérdésfeltevés előtt. Az ilyen emberekre csak az időt pazarolnánk – csak kapni akarnak, adni soha. Az ilyenekre elvesztegetett időt érdekesebb kérdésekre fordíthatjuk, arra érdemesebbeket segíthetünk. Az ilyen embereket „vesztes”-nek hívjuk (losers, történelmi okokból gyakran így írjuk: „lusers”).

Úgy tapasztaljuk, sokan csak használni akarják az általunk írt programokat anélkül, hogy mindenféle technikai részlettel bíbelődnének. A legtöbb ember számára a számítógép csak egy eszköz a sok közül a célok elérése érdekében; egyébként egész mással foglalkoznak, élik a saját életüket. Ez tudomásul vesszük, úgyhogy senkitől sem várunk olyan szintű lelkesedést műszaki dolgok iránt, mint amilyet mi tanúsítunk. Mindezek mellett a mi válaszadási stílusunk azokhoz szól, akik tényleg érdeklődnek, és aktívan részt kívánnak venni a problémamegoldásban. Ez mindig is így lesz, de nem is szabad megváltoznia, hisz az csak a hatékonyságunk kárára válna.

Mi, hackerek, (nagyrészt) önkéntesen tesszük, amit teszünk. A drága időnkből veszünk el arra, hogy olyan mennyiségű kérdésre válaszolgassunk, hogy gyakran alig látszunk ki belőle. Ezért irgalmatlanul válogatunk. Különösen a vesztesek kérdéseit hajítjuk ki, hogy az időt – sokkal hatékonyabban – a győztesek kérdéseire fordíthassuk.

Ha a hozzáállásunkat valaki visszataszítónak, fennhéjázónak, esetleg gőgösnek vélné, annak javaslom, gondolja át még egyszer. Senki sem mondta, hogy térdre kell esni előttünk, sőt, tulajdonképpen mi lennénk a legboldogabbak, ha egyenlő partnerként beszélhetnénk a kérdezővel. Örömmel fogadunk magunk közé bárkit, aki megdolgozik érte. De a munkánk hatékonyságát rontja, ha olyanoknak segítünk, akik magukon sem akarnak. Aki ezt nem tudja elfogadni, annak javaslom, kössön hivatalos terméktámogatási szerződést, ne pedig a hackerektől várjon személyes segítség-adományokat.

Aki úgy dönt, tőlünk kér segítséget, nyilván nem akar a vesztesek közé tartozni. Még csak azt sem szeretné, ha úgy tűnne, közéjük tartozik. A gyors és megfelelő válasz érdekében nyerő stílusban kell kérdezni, hogy úgy tűnjön: a kérdező okos, magabiztos, és éppen csak az aktuális problémával kapcsolatban van szüksége segítségre.

(Az írással kapcsolatos észrevételeket, kiegészítéseket, javaslatokat szívesen fogadom a esr@thyrsus.com címen. (angolul – a ford.) Azt mindenesetre kérem figyelembe venni, hogy jelen írást nem általános netikett útmutatónak szántam. Visszadobok minden olyan javaslatot, amely nem kötődik szorosan a technikai fórumokon felteendő kérdésekhez, illetve válaszokhoz.)

Mielőtt kérdeznénk

Mielőtt technikai jellegű kérdést tennénk fel e-mailen, hírcsoportban vagy valamelyik weboldal chatjén, tegyük meg az alábbiakat:

1. művelet

1. Nyomozgassunk és kísérletezgessünk a válasz reményében!
2. Olvassuk el a kézikönyv idevágó részét, hátha ott megleljük a választ.
3. Olvassuk el a Gy.I.K-ot (FAQ), hátha ott megleljük a választ.
4. Próbáljuk megtalálni a választ a weben keresgélve!
5. Kérdezzük meg egy tapaszalt ismerősünket, hátha ő tudja a választ.
6. Próbáljuk megtalálni a választ a forráskódban!

Kérdésfeltevéskor írjuk le, hogy a fenti dolgokon már túl vagyunk! Így mindenki számára világos lesz, hogy nem lustaságból kérdezünk, senki segítőkészségével nem akarunk visszaélni. Még jobb, ha leírjuk, hogy mit tudtunk meg mindezekből. Bárki szívesebben válaszol olyan embernek, aki bizonyítja, hogy képes lesz tanulni a válaszból.

Érdemes a Google keresőbe beírni a kapott hibaüzenetet. Ez elvezethet a probléma megoldásáról szóló dokumentációhoz, vagy rálelhetünk olyan levlista threadre, amely a nekünk kellő választ tartalmazza.

Készítsük elő a kérdésünket, gondoljuk az egészet jól át! Elkapkodott kérdésre elkapkodott választ jár. Vagy semmilyen. Minél inkább látszik, hogy gondolkodtunk a kérdés előtt, és dolgoztunk a problémán, annál valószínűbben kapunk mástól is segítséget.

Óvakodjunk a helytelen kérdésektől! Ha a kérdésünk hibás feltételezéseken alapul, Hacker Henry szinte biztosan ennek megfelelő – használhatatlan – választ fog adni, miközben az egészről az a véleménye: „ostoba kérdés...”. Hackerünknek az lesz a véleménye, hogy a kérdező kapja csak azt a választ, amiről a kérdése szól, ahelyett hogy a tényleges problémában lenne előrelépés. Ez jó lecke a kérdezőnek.

Sose higgyük, hogy jár a válasz! Semmi sem jár, amiért nem fizetünk. A választ ki lehet érdemelni. Ki lehet érdemelni lényegre törő kérdéssel, érdekes, gondolkodásra serkentő kérdéssel, olyannal, ami hozzáárul a közösség tapasztalatvagyonához, nem pedig csak mások tudását szipolyozza.

Másrészt pedig nagyon jó kezdés, ha a kérdező kinyilvánítja, hajlandó részt venni a problémamegoldás folyamatában. „Merre induljak el?, Mi hiányzik a példából?, Melyik weboldalon kéne kutakodnom? Az ilyen jellegű kérdésekre sokkal valószínűbben érkezik válasz, mint a Küldjétek el a teljes és pontos procedúrát!” típusúakra. Előbbieknél a kérdező tisztázza, hogy hajlandó befejezni a folyamatot, ha megkapja a kezdő lökést.

Mikor kérdezzünk?

Használjuk a megfelelő fórumot!

Nagyon oda kell figyelni arra, hogy hol tesszük fel a kérdésünket. A kérdező szinte biztosan válasz nélkül marad, vagy bekerül a vesztesek skatulyájába, ha a kérdés:

• olyan helyen kerül elő, ahol off-topicnak számít
• nagyon egyszerű és a fórum közönsége vérprofi, vagy fordítva
• egyszerre sok hírcsoportban jelenik meg (cross-posting)
• személyes e-mail formájában kerül elküldésre olyasvalakinek, aki sem a kérdező közeli ismerőse, sem pedig a probléma személyes felelőse

A hackerek féltik a kommunikációs csatornákat az oda nem tartozó információk áradatától. Ennek érdekében a nem megfelelő helyre küldött kérdéseket azonnal lesöprik az asztalról. Egy kérdező sem szeretné, ha a kérdése ilyen sorsra jutna.

Kérdésküldés ismeretlen embernek vagy ismeretlen fórumra – legalábbis – kockázatos dolog. Pl. senki se várja, hogy egy jó, informatív weboldal szerzője mindenképpen a mi ingyen szakértőnk akar lenni. Ne bizakodjunk túlzottan kérdésünk pozitív fogadtatásában. Ha nem vagyunk biztosak a dolgunkban, küldjük a kérdést máshova, vagy akár hagyjuk a fenébe az egészet!

Hírcsoport vagy levlista esetén ne bízzunk túlzottan az elnevezésben. Ellenőrizzük a GyIK-ban vagy a lista weboldalán, hogy kérdésünk nem off-topic-e. Írás előtt olvassunk bele a forgalomba, így rálátunk az ottani szokásokra.

Tudjuk, hova tartozik a kérdésünk! Tipikus hiba, hogy olyan fórumon kérdeznek unix-, vagy windows programozási interface témakörben, ahol egyébként valamilyen, mindkét platformon futó nyelv, programozói könyvtár vagy eszköz a téma. Aki nem érti, miért hiba ez, az jobb, ha nem kérdez semmit, és elgondolkodik ezen.

Általánosságban megállapíthatjuk, hogy egy jó helyre feltett publikus kérdés hasznosabb válasz(ok)at eredményez, mint egy azonos tartalmú privát kérdés. Több okból is: Egyrészt nagyobb a potenciális válaszadók halmaza. Másrészt nagyobb a hallgatóság; hackerek szívesebben válaszolnak akkor a kérdésekre, ha a válasz több ember okulására is szolgál, mintha csak kevésére.

Érthető, hogy a hozzáértő hackerek, illetve népszerű szoftverek szerzői bőven az elviselhetőség határain túl kapnak olyan kérdéseket, melyek nem is nekik szólnának. Szélsőséges esetben lehet, hogy pont a mi hibás kérdésünk az utolsó csepp a pohárban – előfordul, hogy népszerű projekteken dolgozók visszavonulnak a támogatási tevékenységtől az elviselhetetlen levélforgalom miatt.

Használjuk a projekt levlistáját, amikor csak lehet!

Ha a projekt üzemeltet fejlesztői levelezési listát, használjuk azt! Ne zaklassuk külön-külön a fejlesztőket, még ha úgy is hisszük, hogy ismerjük a válaszra legalkalmasabbak kilétét. Keressük meg a projekt levlistájának címét – akár a dokumentációban, akár a projekt weboldalán –, és használjuk azt! Ennek számtalan előnye van:

• Ami elég érdekes kérdés ahhoz, hogy feltegyük, hasznos lehet az egész csoportnak. Ezzel szemben, ha a saját ostoba kérdésünket szégyelljük a levlistától, senkit sem bosszanthatunk vele magánban.

• A levlista használata megosztja a fejlesztők terheltségét. Egy adott fejlesztő – különösen, ha ő a projekt vezetője – túl elfoglalt a válaszadáshoz.

• A legtöbb levlistát archiválják, az archívumot meg leindexelik a keresőgépek; ha ott kérdezünk, egy későbbi érdeklődő rátalálhat.

• Ha bizonyos kérdések gyakran megjelennek a levlistán, a fejlesztők okulhatnak belőle. Vagy kiegészítik a dokumentációt, vagy átírják a programot, hogy az kevésbé legyen zavaros. Ha ugyanezek a kérdések privátban mennek, senki sem látja át őket.

Ha nem találunk projektlevlistát, csak a projektfelelős címét, használjuk azt. De még ekkor sem zárható ki, hogy van projektlevlista. Ilyen esetben jelezzük a levélben, hogy kerestük, de nem találtuk a levlistát. Szintén említsük meg, hogy semmi kifogásunk az ellen, ha a levelünket mások is látják. (Sokan hiszik, hogy a privát e-mail azért privát, hogy azt ne lássa más, még ha semmi titok nincs is benne. Ha előre engedélyezzük a továbbküldést, a címzettre bízzuk a levél további kezelését.)

Válaszkönnyítés

Ha azzal fejezzük be a levelet, hogy „Válaszokat a köv. címre kérek:...”, azzal egyáltalán nem növeljük válaszkapási esélyünket. Aki arra sem képes, hogy pár másodperc alatt rendesen beállítsa a Reply To mezőt a levelezőprogramjában, az pár másodperc együttműködést se várjon el a problémájával kapcsolatban. Ha a levelezőprogram nem engedi ezt a beállítást, le kell cserélni. Ha az oprendszerünk nem támogatja az ilyen levelezőprogramok futását, azt is le kell cserélni.

Írjunk világosan, nyelvtanilag helyesen, jó helyesírással!

Úgy vettük észre, hogy a hanyagul, felületesen író emberek ugyanilyen felületesen és hanyagul dolgoznak, gondolkodnak, kódolnak. (Legalábbis elég nagy százalékban.) Felületesen gondolkodó emberekre nem érdemes időt pazarolni.

Nagyon fontos a kérdés tiszta és helyes megfogalmazása. Ha valaki ezzel nem törődik, annak a kérdésével meg mi nem törődünk. Fektessünk különös hangsúlyt nyelvünk tökéletesítésére! Ez nem azt jelenti, hogy merevnek vagy szertartásosnak kell lenni – igazából a hacker kultúra kedveli a laza, humoros, kötetlen nyelvezetet, ha azt valaki helyesen használja. De mindenképpen helyesen! A helyes nyelvezet megmutatja, hogy a kérdező képes gondolkodni és odafigyelni dolgokra.

A helyesírás, a központozás, a kis- és nagybetűk mind legyenek helyesek! Ne keverjük össze az „egyelőrét az egyenlőrével, az ly-t a j-vel, tudjunk helyesen toldalékolni! Kerüljük a CSUPA NAGYBETŰVEL ÍRÁST – durva dolog, olyan, mintha kiabálnánk. (A csupa kisbetűs írás már kevésbé zavaró – azt szimplán csak nehéz olvasni. Alan Cox megteheti, de amit szabad Jupiternek...”)

Általában: aki úgy ír, mint egy félművelt tahó, annak kicsi az esélye a válaszra. Ha f4$z4gy3r3k stílusban írunk, jutalmunk síri csend lesz, vagy esetleg gúny és megvetés.

Ha nem a saját anyanyelvünkön kérdezünk, természetesen mindenki elnézőbb egy kissé a helyesírási és nyelvtani hibákkal kapcsolatban. De a lustaság nem fogható erre – és a hackerek észreveszik a különbséget! Hacsak nem ismerjük a válaszadó nyelvét, kérdezzünk angolul. A legtöbb hacker túl elfoglalt az érthetetlen nyelveken készült kérdésekhez, valamint az interneten az angol a használt munkanyelv. Ha angolul írunk, sokkal kevésbé valószínű, hogy olvasatlanul kihajítják a levelet.

A kérdések legyenek könnyen érthetőek!

Ha direkt nehezítjük a kérdés olvasását, kevesen fognak foglalkozni vele. Úgyhogy:

• Leveleink sima szöveges (plain text) formátumúak legyenek, ne írjunk HTML-t! (Semmiből sem áll kikapcsolni a HTML-t.)
• MIME levélmellékletekkel általában nincs gond, ha az ténylegesen fontos adat (forráskód, patch), nem pedig a rosszul beállított levelező mellékterméke (mondjuk a levéltörzs, más formátumban).
• Ne írjunk olyan levelet, ahol teljes bekezdések kerülnek egy sorba! Így nehéz válaszolni. Általában a leveleket 80 karakter széles képernyőn/ablakban olvassák, állítsuk a sortörést 80-nál kevesebbre.
• Mindezektől függetlenül ne tördeljünk át adatokat (logokat, transcripteket)! Az adatoknak úgy kell eljutni a lehetséges válaszadókhoz, ahogy mi is láttuk.
• Kerüljük a MIME Quoted-Printable kódolást, ha angol nyelvű fórumra küldjük az üzenetet. Ez a kódolás hasznos lehet ASCII által nem támogatott nyelveknél, de egy csomó levelezőprogram nem támogatja. A mindenfelé felbukkanó =20-aktol a szöveg ronda és idegesítő lesz.
• Ne várjuk el a hackerektől, hogy zárt formátumú doksit olvassanak (pl. Microsoft Word). A legtöbben erre ugyanúgy reagálnak, mint a házuk előtt a járdán gőzölgő friss pitbulltrágyára.
• Ha windowsos gépről küldünk levelet, kapcsoljuk ki a Microsoft idióta „okos idézőjeleit”! (Ezzel egy csomó felesleges karaktert spórolhatunk meg.)

Grafikus levelezőkliensek (Netscape Messenger, MS Outlook és barátaik) gyakran áthágják a fenti szabályokat, ha nem nyúlunk az alapbeállításokhoz. Ezeknél a programoknál gyakran a menüből ellenőrizhetjük az üzenetünk forrását. Használjuk! Szűrjük ki a nem kívánt „zaccot”!

Használjunk értelmes, odaillő tárgymegjelölést!

Levlistákon, hírcsoportokban a tárgy mező maximum 50 karaktere szolgál arra, hogy a hozzáértők figyelmét felkeltse. Ne pocsékoljuk marhaságokra! A „Segítség! vagy Segítsetek!, esetleg HELP!!!” tárgyú üzeneteket a legtöbben azonnal törlik. Ne is próbáljunk a lehetséges válaszadókra hatni könyörgéssel! Sokkal inkább használjuk ki a lehetőséget, hogy tömören megfogalmazhatjuk a problémát!

Jó tárgymegjelölési konvenció (számos terméktámogató szervezetnél használják) a „tárgy – panasz formátum. A tárgy-rész leírja, hogy mivel van gond, a panasz”-rész pedig bemutatja az eltérést az elvárt működéstől.

Ostoba:

SEGÍTSETEK! A kép rossz a laptopomon!

Okos:

XFree86 4.1 torzult egérkurzor, Fooware MV1005 vid. chipset

Még okosabb:

XFree86 4.1 egérkurzor, Fooware MV1005 vid. chipset – torz

A „tárgy – panasz” formátumú leírás folyamán rendeződnek gondolataink, részletesen átgondoljuk a problémát. Mi az, ami érintett? Csak az egérkurzor, vagy más grafikus dolgok is? XFree86 specifikus? XFree86 4.1? Közrejátszik a Fooware video chipset? Számít, hogy MMV1005-ös modell? Aki ezt olvassa, egyszerre látja azt, amivel gond van és a problémát magát.

Ha válaszlevélben kérdezünk, érdemes átírni a tárgyat. A „Re: teszt vagy Re: új hiba” jellegű címek nem irányítják magukra a figyelmet. Ugyanígy figyeljünk arra is, hogy csak a legfontosabbakat idézzük, de idézzünk eleget, hogy a frissen bekapcsolódók is értsék, miről van szó.

Új üzenet írásakor nem jó, ha valamelyik régi levélen "reply"-t nyomunk. Néhány levelezőkliens threadek szerint tud rendezni, így a levelünk eltűnhet a "megválaszolt" threadben. A tárgy átírása kevés. A Mutt és egy pár másik levelezőprogram a levél fejléce alapján rendezi a threadeket, nem a tárgy alapján. Jobb, ha új levelet írunk.

Pontos és informatív problémaleírás

• Figyelmesen és érthetően írjuk le a probléma vagy hiba tüneteit!
• Mutassuk be a futtatókörnyezetet (gép, operációs rendszer, alkalmazás stb.)!
• Írjuk le, mikkel próbálkoztunk a kérdés elküldése előtt!
• Írjuk le, milyen diagnosztikai lépéseket tettünk a probléma pontosítása érdekében!
• Írjuk le, milyen változások történtek számítógépünk hardverében/szoftverében, ha ide tartozik.

Próbáljuk már előre megválaszolni a hackerek esetleges kérdéseit!

Mindenkinek javaslom Simon Tatham remek esszéjét: Hogyan jelentsük a hibákat hatékonyan.

A mennyiség nem pontosság

A kérdés legyen pontos és informatív! Az kevés, ha televágjuk a levelünket kóddal vagy adatokkal. Ha valami bonyolult tesztesetben száll el a program, próbáljuk röviden leírni.

Ez három okból hasznos: Egyrészt látszik, hogy komolyan foglalkoztunk a problémával és a kérdés tömör megfogalmazásával, így valószínűbben kapunk választ. Másrészt a kérdés egyszerűsítése miatt valószínűbb, hogy hasznos választ kapunk. Végül pedig a hibajelentés folyamán készíthetünk javítást vagy leírhatjuk, hogy kerülhető el.

A probléma tüneteit írjuk le, ne a találgatásokat!

Nincs túl sok értelme elmesélni a hackereknek, szerintünk mi okozza a hibát. (Ha lenne értelme a találgatásnak, nem kérdezgetnénk a hackereket, nem?) Úgyhogy semmi elméletgyártás, írjuk csak le szimplán a tüneteket, hadd elemezzék!

Ostoba:

Állandóan SIG11 hibát kapok kernelfordításkor. Szerintem az alaplapom kontakthibás. Hogy lehet legjobban ellenőrizni?

Okos:

Otthon összeraktam egy K6/233-at, FIC-PA2007 alaplappal (VIA Apollo VP2 chipset), 256MB Corsair PC133 SDRAM-mal. Bekapcsolás után kb. 20 perccel SIG11 hibák jönnek ha kernelt fordítok, de az első 20 percben soha. Az gép újraindítása nem indítja újra az órát, de az éjszakai kikapcsolás igen. A RAM-ok kicserélése nem segített. Részlet a fordítási naplóból:...

A tüneteket szedjük időrendbe!

A legtöbbször a hiba előtti események vezetnek nyomra. Szóval legjobb, ha szépen, pontosan leírjuk, mit tettünk mi, és mit csinált a gép, egészen a hibáig. Ha parancssoros a rendszerünk, idézzük be a napló kb. 20 odavágó sorát – nagyon hasznos.

Ha a hibázó program rendelkezik diagnosztikai támogatással (pl. -v kapcsoló, verbose, részletes), érdemes elgondolkodni rajta, mennyivel lesz több debug-információnk a használatával.

Ha a naplónk túl hosszú lett (4 bekezdés, vagy több) tömören foglaljuk össze az egészet, majd menjünk végig időrendben! Ilyen esetben a hackerek tudni fogják, mik az érdekes részek.

Ne kérjünk privát választ!

A hackerek hite szerint a problémamegoldás nyilvános, átlátható kell, hogy legyen, így hozzáértőbbek bármely – hiányos vagy helytelen – lépést korrigálhatják. Emellett a hozzáértésről és szaktudásról árulkodó jó válasz elismerést vált ki a társakból.

Aki privát választ kér, mindkét elvet sérti. Nem helyes. Hagyjuk meg a válaszadónak, hogy magán- vagy nyilvános levelet küld-e válaszként. Ha privát választ küld, gyakran azért teszi, mert a kérdés formailag hibás vagy túl egyszerű ahhoz, hogy mást is érdekelhessen.

Egy kivétel azonban van a fenti szabály alól. Előfordulhat, hogy rengeteg, nagyjából azonos válaszra számítunk. Ebben az esetben a „Küldjétek nekem a válaszokat magánba; én majd összegzem őket” varázsszavakat érdemes használni. Nagyon udvarias dolog, hogy így mentesítjük a levlistát vagy a hírcsoportot a tartalmilag egyező üzenetek áradatától, de nem szabad elfelejteni az összegzéssel kapcsolatos ígéretünket.

Lényegre törően tegyük fel a kérdést!

A nyíltvégű kérdések egyben feneketlen zsákok is, bármennyi időt elnyelnek. A kérdéseinkre leginkább válaszolni tudó emberek gyakran a legelfoglaltabbak is egyben. Az ilyen emberek takarékosan bánnak az idővel, allergiásak az időnyelő feneketlen zsákokra, így a nyíltvégű kérdésekre is.

Sokkal valószínűbben kapunk választ, ha leírjuk, hogy milyen választ szeretnénk (kezdő lökés, kódrészlet, patch-ellenőrzés vagy bármi más). Így segíthetünk a válaszadóknak fókuszálni az erőfeszítéseket, valamint felülről behatároljuk a segítők ránk fordítandó energia- és időmennyiségét. És ez így jó!

Hogy megértsük a szakértők világát, képzeljük el, hogy a szakértelem olyan erőforrás, ami bőségesen rendelkezésünkre áll, míg a válaszhoz szükséges idő szűkös. Minél kisebb időigényű a kérdésünk, annál valószínűbben találunk elfoglalt, de nagyon hozzáértő válaszadót.

Jó dolog jól megfogalmazni a kérdést, hogy a szakértő könnyebben válaszolhasson, de ez nem egyenlő a kérdés leegyszerűsítésével. Tehát a „Hol találok jó leírást X-ről? sokkal okosabb kérdés, mint az Elmagyarázná valaki X-et?”. Ha a kódunk nem működik, inkább kérjünk meg valakit, hogy magyarázza el, mi a hiba, minthogy arra, javítsa ki.

Ne küldjünk házi feladat kérdéseket!

A hackerek azonnal kiszúrják, ha valaki házi feladattal nyaggatja őket. A legtöbb feladatot ők is megcsinálták már. A házi feladat azért van, hogy tanuljunk belőle. Az rendben van, ha ötleteket kérünk, de teljes megoldást kérni TILOS!

Hagyjuk ki a céltalan kérdéseket!

„Tud valaki segíteni? Van erre válasz?” Álljunk ellen a kísértésnek, hogy a kérésünket ilyen, szemantikailag értékelhetetlen kérdő mondattal zárjuk! Először is, már legalább félig leírtuk a problémát, az ilyen toldalékkérdés legjobb esetben is felesleges. Másodszor: mivel felesleges, bosszantó is. Aki ilyet kérdez, ne lepődjön meg a logikailag kifogástalan „Igen, tudunk segíteni. vagy Nem, a helyzet kilátástalan” válaszokon.

Általánosságban megállapíthatjuk, hogy az eldöntendő kérdések kerülendőek, kivéve, ha határozott igen vagy nem választ akarunk.

Ne használjuk a „SÜRGŐS” jelzőt, még ha a kérdésünk az is

Ez a kérdező dolga, nem a hackereké. A sürgősségre hivatkozás gyakran pont fordítva sül el: a legtöbb hacker simán letörli az ilyen üzeneteket, mint az azonnali és különleges elbánást kicsalni próbáló durva önzés mementóit.

Egy kis udvariasság nem árt, sőt használ

Legyünk udvariasak! Használjuk a „Kérem, Legyetek szívesek, Előre is köszönöm” formulákat! Legyen nyilvánvaló, hogy a kérdező hálás a neki ingyen segítőknek!

Igazából ez korántsem olyan fontos, mint a nyelvtanilag helyes szöveg, a tiszta, precíz fogalmazás, a céges formátumok használatának elkerülése. Nem is helyettesíti ezeket. A hackerek szívesebben olvasnak goromba, de műszakilag tökéletes hibajelentéseket, mint udvarias sötétben tapogatózást. (Emlékezzünk: a hackerek értékelik az olyan kérdéseket, amikből tanulhatnak.)

Mindazonáltal, ha megvan az összes technikai adat, egy kis udvariasság csak növeli a válasz esélyét.

(Itt kell megjegyeznem, hogy számos öreg hacker jelezte, nem ért egyet az „Előre is köszönöm” formula használatával. Szerintük utólag kell megköszönni dolgokat. Én azt javaslom, tegyük mindkettőt.)

Foglaljuk össze a megoldást!

A probléma megoldása után küldjünk összefoglalót a segítőknek, és köszönjük meg újra a segítséget. Ha többeket is érdekel a megoldás, akkor küldjük az összefoglalót a levlistára vagy a hírcsoportra!

Az összefoglaló ne legyen mély, vagy bonyolult. Sziasztok! A hálózat drótja volt rossz. Köszi még egyszer, Béla jobb a semminél. Igazából egy tömör és velős összefoglaló jobb, mint egy bő lére eresztett értekezés, hacsak tényleg nincs szükség a technikai mélységek bejárására. Írjuk le, hogy mi volt a megoldás, de nem kell az egész folyamatot megismételni!

Bonyolult problémák esetén jó lehet a problémamegoldás lépéseit leírni. Írjuk körbe a végső problémát, valamint a legközelebb elkerülendő zsákutcákat! Nevezzük meg a segítőinket, barátságok szövődhetnek így.

Ezek az összefoglalók, amellett, hogy nagyon udvariasak és informatívak, hasznosak lehetnek a hasonló problémákkal szenvedők számára is, amikor a levlista/hírcsoport/fórum archívumában keresgélnek.

Végül, de nem utolsósorban az ilyen összefoglalók tudatják mindenkivel, hogy a probléma megoldódott, mindenki megelégedésére. Ha a kérdező nem is hacker vagy műszaki érdeklődésű, elhiheti, hogy ez fontos a hackereknek. Az olyan problémaleírások, amelyek csak megoldatlanság ködébe vezetnek izgatják a hackereket, akik viszketegen meg akarják oldani azokat. Az problémát lezáró összefoglaló hűsítő balzsamként hat az izgatott hackerekre, ez a balzsam pedig jó karma a későbbiekben.

Gondolkozzunk el azon, hogy hogyan óvhatók meg mások hasonló problémáktól! Érdemes-e dokumentációt vagy GyIK-cikket írni? Ha igen, küldjük el a felelősnek.

Ez a magatartás sokkal fontosabb a hacker-társadalomban, mint a hagyományos udvariasság. Így juthatunk megbecsüléshez mások segítése által – ez nagy kincs.

Hogyan értelmezzük a válaszokat

RTFM és STFW: ezt elszúrtuk

Van egy régi és szent hagyomány: ha „RTFM” választ kapunk, a válaszadó úgy hiszi, ideje lenne dokumentációt olvasnunk. (RTFM – Read The Fucking Manual, Olvasd már el a kibaszott doksit!) A legtöbbször igaza van. Olvassuk el!

Az RTFM-hez hasonló, de fiatalabb válasz az „STFW. Ha STFW” választ kapunk, a válaszadó úgy hiszi, a weben kéne keresgélnünk. (STFW – Search The Fucking Web) A legtöbbször igaza van. Keressünk!

Általában a fenti válaszokat küldő éppen a hivatkozott kézikönyvet vagy weboldalt nézegeti. Ezek a válaszok arra utalnak, hogy a) a nekünk kellő információk könnyen megtalálhatóak, b) sokat tanulhatunk, ha átnyálazzuk.

Az ilyen válaszokat ne vegyük személyes támadásnak! A hacker-társadalomban az, hogy nem ignorálja a kérdésünket, egyfajta – igaz, durva – tiszteletet fejez ki. Inkább legyünk hálásak s tekintsük atyai pofonnak!

Ha nem értjük...

Ha nem értjük a választ, ne írjunk vissza automatikusan, pontosítást kérve! Használjuk a kérdésfeltevés előtti erőforrásokat (doksi, GyIK, web, hozzáértő ismerősök) a válasz értelmezéséhez! Ezután, ha még mindig nem tiszta valami, mondjuk el, mit tudtunk meg!

Pl. ilyen válasz érkezik: „Úgy tűnik, a zentry eldugult. Ki kell tisztítani.”

Ilyenkor ez rossz kérdés: „Mi az a zentry?”

Ez a jó kérdés: „Átolvastam a man-oldalakat, zentry-t csak a -z és a -p kapcsolónál említi. Zentry-tisztításról egyik helyen sincs szó. Ezek kellenek, vagy valamit félrenéztem?”

Gorombaság kezelése

A hackerek világában ami gorombának tűnik, általában nem támadó szándékú. Inkább annak a közvetlen, hagyjuk-a-sok-szar-sallangot kommunikációs stílusnak az eredménye, ami természetes olyanok között, akik inkább a problémák megoldásával törődnek, mint a kétértelmű fogalmazással.

Ha durva választ kapunk, próbáljuk nyugodtan reagálni. Ha valaki túl durva, a lista vagy hírcsoport valamely rangidős tagja figyelmeztetni fogja ezért. Ha ez mégsem történik meg, és ezen feldühödünk, valószínűleg a válaszadó cselekedett a hacker-társadalom normái szerint, és mindenki minket hibáztat miatta. Ez pedig megnehezíti a későbbi válaszkapást.

Másrészt viszont gyakran találkozhatunk durvasággal, ami ellen felesleges harcolni. Az érem másik oldala viszont, hogy a társas szabályokat durván megsértők megbüntetése elfogadott, ha éles szavaink szikéjével boncolgatjuk helytelen viselkedésüket. Ezt azonban csak alapos indokkal tegyük! Az udvariatlanság ártatlan kijavítása és egy értelmetlen szitokháború (flamewar) kirobbantása között annyira keskeny a mezsgye, hogy még az öreg hackerek is nemritkán átlépik. Kezdőként vagy kívülállóként még nagyobb a veszély. Ha nem szórakozásból, hanem információkért jöttünk, óvatosan nyúljunk a billentyűkhöz.

(Páran állítják, hogy számos hackernek – Asperger-kórjuk, vagy enyhébb fokú autizmusuk miatt – hiányoznak a `normális' társas kapcsolatok lebonyolításáért felelős agytekervényeik. Lehet, hogy így van, lehet, hogy nincs így. Aki nem hacker, annak talán könnyebb lesz a hibás hackeragyra fogni a különcséget. Csak nyugodtan tartsa mindenki annak a hackereket, aminek csak akarja. A hackerek kedvelik a saját állapotukat, és alapban némi egészséges kétkedéssel fogadják az orvosi címkéket.

A következő fejezetben eltérő témát taglalunk; azt a fajta durvaságot, amit a kérdező akkor tapasztal, amikor ő hibázik.

Hogyan válaszoljunk nem vesztesként

Előfordulhat egy párszor, hogy bénázunk a hacker társadalom fórumain – így, ahogy e cikkben részletezzük, vagy ehhez hasonlóan. És meg is fogjuk kapni, hogy hibáztunk, részletesen, színes jelzőkkel. Nyilvánosan.

Ilyenkor a legrosszabb, ha siránkozni kezdünk, panaszkodunk, hogy bántanak, elégtételt követelünk, sikoltozunk fuldoklásig, perrel fenyegetőzünk, cégeknek panaszkodunk, feltámasztva hagyjuk a WC-deszkát stb. Ehelyett:

Hagyjuk a francba! Ez a leghelyesebb; egészséges és helyénvaló dolog.

A társadalmi szabályok nem önformálóak: emberek formálják azokat, akik alkalmazzák, mindenki számára láthatóan, nyilvánosan. Ne nyavalyogjunk hát, hogy az ilyen kritikai megjegyzések privátba jöhettek volna! Ez nem így működik. Nem is túl hasznos kitartani amellett, hogy megtámadtak, ha valaki rávilágít arra, hogy hibás volt a kérésünk, vagy valamit rossz szemszögből nézünk. Ez a vesztesekre jellemző.

Voltak olyan hacker-fórumok, ahol – valami félreértett hiperudvariasságtól vezérelve – a tagok nem jelezhették, ha hibát találtak egymás levelében, mondván: „aki nem akar segíteni a júzernek, az ne is írjon semmit!” Emiatt lassan a hozzáértő tagok elhagyták a fórumot, ami értelmetlen gügyögések színhelyeként használhatatlanná vált.

Végső soron vagy „kedves” vagy hasznos. Választhatunk.

Emlékezzünk: ha egy hacker azt mondja, hibáztunk – mindegy, milyen udvariatlanul – és ezzel óva int az újbóli elkövetéstől, ezt egyrészt a mi érdekünkben, másrészt a hacker-társadalom érdekében teszi. Sokkal egyszerűbb lenne kiszűrnie minket egy egész életre. Ha ezért nem is vagyunk hálásak, legalább fogadjuk méltóságteljesen, ne nyafogjunk, és ne számítsunk porcelánbabáknak kijáró gyengéd elbánásra csak azért, mert kezdőként drámaian extraérzékeny a lelkivilágunk.

Ilyeneket ne kérdezzünk!

Íme egy pár klasszikus „ostoba kérdés”, és hogy mire gondolnak a hackerek, miközben nem válaszolnak rájuk:

Q: Hol találom X programot vagy erőforrást?

Q: Hogyan lehet X-szel Y-t csinálni?

Q: Hogy állítsam be a shell-promptomat?

Q: Át lehet konvertálni az AcmeCorp doksimat TeX fájlba a Bass-o-matic fájlkonverterrel?

Q: Van itt egy {program, konfiguráció, SQL parancs}, ami nem működik

Q: Gond van a Windows-gépemmel. Tudtok segíteni?

Q: A programom nem megy. Úgy tűnik, az X rendszerszolgáltatás rossz.

Q: Gondom van a Linux vagy az X telepítésével. Tudtok segíteni?

Q: Hogyan szerezhetek rendszergazdai jogosultságokat/hogy szerezhetek IRC operátori jogokat/hogy olvashatom el alaki más emailjeit?

Q:	Hol találom X programot vagy erőforrást?
A:	Ott, ahol én, kis butaarcú! – Webkereső! Úr isten, nem hiszem el, hogy van ember, aki nem ismeri a Google-t.
Q:	Hogyan lehet X-szel Y-t csinálni?
A:	Ha valaki Y-t akar csinálni, akkor mondja azt, helytelen módszerekre való utalgatás nélkül! Az ilyen kérdések olyan kérdezőre utalnak, aki nemcsak hogy nem ért X-hez, de zavarosan érti csak az Y problémát is, és az agyát a saját problémája tölti ki. Az ilyen embert jobb békénhagyni, amíg meg nem fogalmazza, hogy mit akar.
Q:	Hogy állítsam be a shell-promptomat?
A:	Aki elég értelmes feltenni ezt a kérdést, az elég értelmes, hogy RTFM jelleggel utánaolvasson.
Q:	Át lehet konvertálni az AcmeCorp doksimat TeX fájlba a Bass-o-matic fájlkonverterrel?
A:	Próbáld ki! Ha megvolt, (a) tudod a választ, (b) nem pazarlod az időm.
Q:	Van itt egy {program, konfiguráció, SQL parancs}, ami nem működik.
A:	Ez több, mint egy kérdés, nekem meg semmi kedvem kibarkochbázni az igazit – sokkal jobban is el tudom tölteni az időm. Ilyen esetekben én ilyeneket válaszolok: Még valamit esetleg? Pech. Remélem, hamarosan sikerül kijavítani. És akkor mi van?
Q:	Gond van a Windows-gépemmel. Tudtok segíteni?
A:	Persze. Töröld le a Microsoft-szart, és tegyél nyílt forrású oprendszert a gépedre, pl. Linuxot vagy BSD-t.
Q:	A programom nem megy. Úgy tűnik, az X rendszerszolgáltatás rossz.
A:	Lehet, hogy te voltál az első, aki észrevette, hogy valamely rendszerhívás vagy programozói könyvtár, amit százak és ezrek nyúznak napi szinten, hibás, de sokkal valószínűbb, hogy fogalmad sincs, hogy miről beszélsz. A vádakat bizonyítani is kell, úgyhogy ha ilyen váddal állsz elő, világosan és kimerítően dokumentálnod kell a tesztesetet.
Q:	Gondom van a Linux vagy az X telepítésével. Tudtok segíteni?
A:	Nem. Ahhoz hozzáférés kell a géphez. Inkább a helyi Linux-klubban érdeklődj! Linux user groupok listája itt.)
Q:	Hogyan szerezhetek rendszergazdai jogosultságokat/IRC operátori jogokat/hogy olvashatom el valaki más e-mailjeit?
A:	Alantas figura, aki ilyet akar tenni, és hihetetlenül ostoba, hogy pont hackerektől kér segítséget.

Jó és rossz kérdések

Végül álljon itt néhány példa! A kérdéspárok azonos problémára utalnak, először ostobán, majd helyesen feltéve.

Ostoba:

Hol találok anyagot Foonly Flurbamatic témában?

Ez „STFW”-ért kiált.

Okos:

Google-lal rákerestem arra, hogy „Foonly Flurbamatic 2600”, de nem találtam semmi használhatót. Tudja valaki, hol találok programozói leírást az eszközről?

Így látszik, hogy az STFW megvolt, tényleg nehezen található információ.

Ostoba:

Nem tudom lefordítani a foo forrását. Miért nem megy?

A kérdező azt feltételezi, hogy valaki más hibázott. Arrogáns.

Okos:

Nem tudom lefordítani a foo forrását Nulix v6.2 alatt. Elolvastam a GyIK-ot, de nincs benne semmi Nulix-hibákról. Itt a fordítási napló; én szúrtam el valamit?

Specifikálja a környezetet, elolvasta a GyIK-ot, megmutatja, hol a hiba, végül nem hiszi, hogy a problémát másvalaki okozta. Figyelemreméltó lehet.

Ostoba:

Gond van az alaplapommal. Tud valaki segíteni?

Hacker Bárky Henry erre olyasmit válaszolna, hogy „Hát persze. Meg is böfiztessünk? Át is pelenkázzunk?” majd határozottan megnyomná a DEL-t.

Okos:

Próbálkoztam X, Y és Z-vel az S2464 alaplapon. Amikor nem ment, jött A, B és C. Észrevettem valami furcsaságot C-nél. A zseltox rendesen szubitál, de nem a várt eredménnyel. Mik okozhatják a szubitálást Athlon MP alaplapokon? Van valami ötlet további tesztekre, hogy a hibát sarokba szorítsam?

Ez a kérdező méltó a válaszra. Tanúbizonyságot tett problémamegoldó képességéről, nem csak a sült galambot várja.

Az utolsó kérdésben vegyük észre az árnyalatnyi, ám annál fontosabb különbséget: „Válaszoljatok! ill. Segítsetek kitalálni, milyen további vizsgálatokkal juthatok közelebb a megoldáshoz!”

Igazából ez utóbbi kérdés egy 2001. augusztusi valóságos történeten alapul, linux-kernel levlistán. Jómagam (Eric) tettem fel a kérdést, mert rejtélyes zárlatokat tapasztaltam a Tyan S2462 alaplapomon. A listatagok megadták a létfontosságú információkat.

Ha úgy kérdezünk, mint én tettem, támpontot adunk a segítőinknek. Egyszerűen be tud szállni bárki a problémamegoldásba, és az elég érdekesen is van tálalva, hogy meg is tegyék. Megmutattam, hogy tisztelem a tudásukat, és egyenrangú félként együttműködésre hívtam őket. Az is látszott, tiszteletben tartom az idejüket, mert leírtam az általam megjárt zsákutcákat.

Aztán, amikor megköszöntem mindenkinek a segítséget, és elmondtam, hogy ment a folyamat, egy listatag jelezte, hogy tudta, hogy működni fog. Nem azért, mert vagyok „valaki” a listán, hanem mert helyes formában kérdeztem.

A hackerek elég kegyetlen kasztrendszerben élnek; biztos vagyok benne, hogy igaza volt a srácnak, és ha potyalesősködöm, leszidnak, vagy semmibe vesznek, bárki is vagyok. Az ő sugallatára írtam le az egész esetet, hogy mások is okulhassanak belőle – végül ez vezetett ehhez az útmutatóhoz.

Ha nem kapunk választ

Ha nem kapunk választ, ne higgyük, hogy a hackerek nem akarnak segíteni! Lehet, hogy a kérdezett csoport tagjai nem tudnak válaszolni. Ha nincs válasz, még nem jelent semmibevételt, bár kívülről kétségkívül nehéz megérezni a különbséget.

Általában a kérdés egyszerű újraküldése rossz ötlet. Mindenki értelmetlen zaklatásnak veszi.

Más forrásokból is juthatunk segítséghez, olyanokból, amelyek jobban alkalmazkodtak a kezdők igényeihez.

Számtalan on-line és helyi felhasználói csoport van, akik lelkesednek az adott szoftverért, mégha maguk életükben egy sor kódot sem írtak. Ezek a klubok pont azért jöttek létre, hogy a tagok egymást és a kezdőket segítsék.

Csomó vállalat is megkereshető segítség ügyben; nagyok is, kicsik is (a legismertebbek a Red Hat és a Linuxcare, de rajtuk kívül van még sok). Ne rémüljünk meg az ötlettől, hogy a segítségért fizetni kell! Ha a kocsink tönkremegy, szervizbe visszük, ahol fizetünk a javításért. Még ha a szoftver nem is került semmibe, ne higgyük, hogy a támogatás is ingyen lesz örökké!

Népszerű programoknál, mint pl. a Linux, legalább tízezer felhasználó jut minden egyes fejlesztőre. Lehetetlen, hogy egy fejlesztő ki tudjon elégíteni 10000 támogatásra éhes felhasználót. Még ha fizetni is kell a támogatásért, még mindig olcsóbban jövünk ki, mintha a szoftver is pénzbe került volna. Ráadásul a zárt szoftverek támogatása még drágább és kevésbé szakszerű is lehet.

Hogyan válaszoljunk segítőkészen

Nyugalom. A problémaorientált stressz durvává vagy ostobává teheti az embert, mégha nem is az.

Ha nem tudjuk biztosan, ne mondjuk! A hibás, de hitelesnek hangzó válasz rosszabb a semminél. Ne küldjük az embereket az erdőbe, csak hogy szakértőnek látsszunk! Legyünk szerények és őszinték; járjunk elöl jó példával a kérdező és a többiek előtt!

Ha segíteni nem tudunk, legalább ne ártsunk! Ne viccelődjünk olyannal, ami hazavághatja a kérdező rendszerét – szerencsétlen még útmutatásnak veszi a tréfát, és megcsinálja.

Puhatolódzó kérdésekkel derítsünk fel további részleteket! Ha jól csináljuk, a kérdező tanulhat belőle, sőt, akár mi is. Próbáljuk a rossz kérdéseket kijavítani! Ne feledjük, mindenki volt kezdő!

Bár az RTFM jó válasz lusta disznók kérdéseire, gyakran jobb, ha utalunk az elolvasandó doksira vagy a Google-be ütendő kulcsszóra.

Ha egyáltalán válaszolunk, jól válaszoljunk Kerüljük az ötletes kerülőutak ajánlgatását, ha látjuk, hogy a kérdező rossz eszközt használ! Ajánljunk inkább megfelelő eszközt! Alakítsuk át a kérdést!

Tanuljon a közösség a kérdésből! Ha jó kérdést látunk, gondolkodjunk el azon, hogyan lehet a dokumentációt vagy a GyIK-ot úgy átírni, hogy más már ne tegye fel ugyanezt a kérdést. Aztán küldjük el a kiegészítést a felelősnek.

Ha kutakodtunk a válasz érdekében mutassuk meg, hogyan! Jobb, mintha úgy írunk, mintha a választ a kisujjunkból szoptuk volna ki. Ha megválaszolunk egy kérdést, az olyan, mintha az éhezőt egyszer jóllakatnánk. Ha példákkal támogatva tanítjuk a keresést, olyan, mintha életük végéig termelhetnek maguknak ételt.

Kapcsolódó anyagok

Akinek információra van szüksége a számítógépek alapjairól (PC, Unix, internet), töltse le a The Unix and Internet Fundamentals HOWTO-t.

Aki szoftvert vagy javítófoltokat ad ki, kövesse a Software Release Practice HOWTO útmutatásait!

Köszönetnyilvánítás

Evelyn Mitchell jónéhány ostoba kérdéssel járult hozzá jelen íráshoz. Ő ihlette a „Hogyan adjunk jó választ” fejezetet.

Készítette

Eric Steven Raymond

Thyrsus Enterprises

<esr@thyrsus.com>

Rick Moen

<rick@linuxmafia.com.com>

Copyright © 2001 Eric S. Raymond

Read the original version here

A fordító megjegyzései

A fordítás a revision 2.0 (2002. aug.) alapján készült. Tudom, hogy azóta volt némi változtatás, ha komolyabbak is lesznek, lekövetem őket.

Fordította: Berta Krisztián