Skype: blackpanther.hu info@blackpanther.hu

Hogy kérdezzünk okosan?!

Hogy kérdezzünk okosan?!

Hogy kérdezzünk okosan?!

Szerző: Adminisztrátor

Itt vagy most:

Eric Steven Raymond
Thyrsus Enterprises <esr@thyrsus.com>
Rick Moen <rick@linuxmafia.com.com>

Hogyan kérdezzünk okosan, avagy Linux-kezdőbiblia 2001-ből!

Copyright © 2001 Eric S. Raymond

Az erdeti verzió itt olvasható

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 ill. 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:

Első feladatunk

  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ényegretörõ kérdéssel, érdekes, gondolkodásra serkentõ kérdéssel, olyannal, ami hozzáárul a közösség tapasztalat-vagyoná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 leslistá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 projektelvlistá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 egyenlegé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ényegretö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égegyszer, 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, monjduk 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óé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ébbfokú 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 nyavajogjunk 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 rendszer-szolgá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.

Hozzászólások lezárva

És van külön márkaoldalunk is a Facebook-on, hírekkel, értesítésekkel

Megnézem

Error: Please enter a valid email address

Error: Invalid email

Error: Please enter your first name

Error: Please enter your last name

Error: Please enter a username

Error: Please enter a password

Error: Please confirm your password

Error: Password and password confirmation do not match