Cum se pun intrebari in mod inteligent?

Mariushca · Admin Data inscrierii: 09/Iul/2007 Mesaje: 264

Introducere
În societatea hackerilor, tipul de rãspuns pe care îl veþi primi la întrebãri tehnice depinde atât de formularea acestora cât ºi de dificultatea elaborãrii unui rãspuns. Acest ghid îºi recomandă sã vã ajute sã formulaþi întrebãrile în aºa fel încât sã primiþi un rãspuns satisfãcãtor.

Acum când utilizarea open-source s-a rãspândit pe scarã largã, puteþi obþine deseori rãspunsuri ºi de la alþi utilizatori mai experimentaþi, nu doar de la hackeri. Ãsta e un lucru bun; utilizatorii tind sã fie mai îngãduitori cu greºelile începãtorilor. Totuºi, tratându-i ºi pe aceºtia ca pe hackeri cum e prescris aici, e modul cel mai uºor de a obþine rãspunsuri de la ei.

Primul lucru pe care trebuie sã-l înþelegeþi este cã hackerilor le plac problemele dificile ºi întrebãrile care le solicitã inteligenþa. Dacã nu era aºa, nu ne aflam aici. Dacã ne daþi o întrebare interesantã o sã vã fim recunoscãtori; întrebãrile bune sunt un stimul ºi un cadou. Întrebãrile bune ne ajutã sã ne clarificãm cunoºtinþele ºi adesea ridicã probleme pe care nu le-am fi observat, sau la care nu ne-am fi gândit. Printre hackeri, „Bunã intrebare!“ e un compliment.

În ciuda acestor lucruri, hackerii au reputaþia cã trateazã întrebãrile simple cu ostilitate ºi aroganþã. Uneori aratã ca ºi cum suntem automat nepoliticoºi cu începãtorii si neºtiutorii. Nu e deloc adevãrat.

Articol luat de pe www.wiki.lug.ro !
Suntem de fapt ostili faþã de acele persoane care parcã nu vor sã gândeascã ºi nu-ºi fac temele cândva sã punã întrebãri. Astfel de persoane nu sunt decât pierdere de vreme, iau fãrã sã dea nimic înapoi, ne fac sã pierdem timpul pe care l-am putea folosi pentru a rãspunde la o intrebare mai interesantã sau unei persoane care meritã într-adevãr. Îi numim pe aceºtia „losers“ (din motive istorice, uneori este scris „lusers“).

Ne dãm seama cã sunt mulþi oameni care vor doar sa foloseascã programele noastre ºi nu sunt interesaþi de detaliile tehnice. Pentru majoritatea oamenilor un computer este o unealtã, un mijloc pentru atingerea unui scop; au lucruri mai bune de fãcut în viaþã. Realizãm asta ºi nu ne aºteptãm ca toatã omenirea sã fie interesatã de chestiunile tehnice care ne fascineazã pe noi. Totuºi, stilul nostru de a rãspunde la întrebãri este adaptat celor care au acest interes si sunt dispuºi sã participe activ la rezolvarea problemelor. Lucrul ãsta nu o sã se schimbe, ºi nici nu ar trebui; dacã s-ar întâmpla, am fi mai puþin eficienþi în treburile la care ne pricepem.

Suntem (în cea mai mare parte) voluntari. Ne luãm din timpul nostru pentru a rãspunde la întrebãri ºi uneori suntem depãºiþi de cantitatea lor, aºa cã le filtrãm fãrã milã. În particular, ignorãm întrebãrile de la persoane care se prezintã ca losers pentru a ne putea folosi timpul mai eficient, cu ceilalþi.

Dacã aceastã atitudine vi se pare enervantã, elitistã sau arogantã, verificaþi-vã ipotezele. Nu vã cerem sã faceþi plecãciuni în faþa noastrã. Dimpotrivã, cei mai mulþi dintre noi ar prefera sã vã trateze ca egali; sunteþi binevenit în comunitatea noastrã, dacã depuneþi efortul necesar ca acest lucru sã fie posibil. Pur ºi simplu, nu este deloc economic sã încercãm sã ajutãm oameni care nu vor sã se ajute singuri. E OK sã fii neºtiutor, NU E OK sã faci pe prostul.

În concluzie, deºi nu este necesar sã fiþi un expert pentru a ne capta atenþia, este necesar sã demonstraþi o atitudine care în timp duce la competenþã: atenþie, reflecþie, spirit de observaþie ºi dorinþa de a participa activ la rezolvarea problemelor. Dacã nu vã convine aceastã discriminare, vã sugerãm sã apelaþi la servicii comerciale de asistenþã tehnicã, în loc sã ne cereþi sã vã facem noi treaba gratuit.

Dacã decideþi sã ne cereþi nouã ajutorul, nu vreþi sã fiþi un loser. Nu vreþi nici mãcar sã pãreþi cã sunteþi unul. Cel mai bun mod de a obþine rapid un rãspuns folositor este sã întrebaþi ca o persoanã inteligentã, care are încredere în sine ºi unele cunoºtinþe, care se întâmplã sã aibã trebuință de ajutor cu o problemã punctualã.

[editeazã]Înainte de a întreba
Înainte de a trimite o întrebare tehnicã pe email, într-un newsgroup sau forum, faceþi urmãtoarele:

Încercaþi sã gãsiþi un rãspuns cãutând pe Web.
Încercaþi sã gãsiþi un rãspuns în manual.
Încercaþi sã gãsiþi un rãspuns într-un FAQ.
Încercaþi sã gãsiþi un rãspuns prin analizã ºi experiment.
Încercaþi sã gãsiþi un rãspuns la un prieten mai experimentat.
Dacã sunteþi programator, încercaþi sã gãsiþi rãspunsul citind codul sursã.
Când formulaþi întrebarea, arãtaþi cã aþi fãcut întâi cele de mai sus; astfel demonstraþi cã nu sunteþi un puturos care ne face sã ne pierdem timpul. ªi mai bine, arãtaþi ce aþi descoperit fãcând cele de mai sus. Ne place sã rãspundem celor care demonstreazã cã pot învãþa ceva din rãspunsurile noastre.

Când cãutaþi pe Google, introduceþi textul mesajului de eroare pe care-l primiþi (cãutaþi ºi în Google Groups, nu doar pe web). E foarte posibil sã ajungeþi direct la documentaþia referitoare la problemã, sau la un thread pe un mailing list care conþine rãspunsul. Chiar dacã nu gãsiþi nimic relevant, ajutã sã puteþi spune „Am cãutat pe google dupã cuvintele urmãtoare dar nu am gãsit nimic folositor“ la începutul mesajului prin care cereþi ajutor.

Pregãtiþi-vã bine întrebarea, gândiþi-o pânã la capãt. Întrebãrile care sunã incomplet vor primi un rãspuns pe mãsurã, sau deloc. Cu cât este mai clar cã aþi încercat sã vã rezolvaþi singur problema, cu atât e mai probabil sã primiþi ajutor.

Aveþi grijã sã nu puneþi o întrebare greºitã. Dacã întrebarea porneºte de la ipoteze greºite, e foarte probabil ca cineva sã vã rãspundã literal, în speranþa cã veþi învãþa ceva primind riguros ce-aþi cerut în loc de ceea ce aveaþi nevoie.

Niciodatã sa nu consideraþi cã aveþi dreptul la un rãspuns. Nu-l aveþi; în definitiv, nu plãtiþi pentru acest serviciu. Veþi câºtiga un rãspuns, punând o întrebare cu substanþã, interesantã, care ne dã de gândit, o întrebare care contribuie implicit la experienþa comunitãþii mai degrabã decât o cerere pasivã de informaþii de la ceilalþi.

Arãtaþi cã sunteþi dispus sã contribuiþi la elaborarea unei soluþii. „Poate sã mã îndrume cineva?“, „Ce lipseºte din exemplul meu?“ ºi „Pe ce site ar mai necesită sã mã uit?“ au ºanse mult mai mari sã primeascã un rãspuns, decât „Vã rog sã-mi spuneþi fidel cum sã fac!“ pentru cã aratã cã aveþi doar necesitate de o micã îndrumare în direcþia bunã.

[editeazã]Când întrebaþi
[editeazã]Atenþie unde întrebaþi
Folosiþi-vã discernãmântul în alegerea locului unde puneþi întrebarea. E deosebit de probabil sã fiþi ignorat sau catalogat ca loser, dacã:

postaþi întrebarea pe un forum unde este offtopic
postaþi o întrebare elementarã pe un forum unde se aºteaptã probleme tehnice complexe, sau invers
postaþi pe mai numeroase grupuri simultan
trimiteþi un mesaj direct cãtre cineva care nu vã e cunoscut personal sau nu e direct responsabil pentru rezolvarea problemei
Hackerii ignorã întrebãrile puse în locurile greºite pentru a-ºi proteja canalele de comunicaþie de zgomot inutil. Nu doriþi sã fiþi în aceastã situaþie.

Primul pas, deci, este gãsirea forumului potrivit. Iarãºi, Google sau alte motoare de cãutare vã sunt prieteni. Folosiþi-le pentru a gãsi pagina de web a proiectului dedicat hardware-ului sau software-ului care vã face probleme. De obicei o sã conþinã link-uri cãtre o lista de FAQ (Frequently Asked Questions), lista de email a proiectului ºi arhiva acesteia. Listele de email sunt ultimul loc unde veþi cere ajutor, dacã prin eforturi proprii (inclusiv citirea acelor FAQ) nu gãsiþi o soluþie. Pagina de web a proiectului mai poate descrie o procedurã de raportare a bug-urilor. Dacã existã, citiþi-o cu atenþie.

Lansarea unui mesaj cãtre o persoanã sau forum cu care nu sunteþi familiar e cel puþin riscantã. De exemplu, nu presupuneþi cã autorul unei pagini de web informative doreºte sã vã fie consultant gratuit. Nu faceþi presupuneri optimiste cã întrebarea va fi binevenitã; dacã nu sunteþi sigur, întrebaþi în altã parte sau deloc.

Când alegeþi un forum, newsgroup sau listã de email, nu vã luaþi doar dupã numele lor; cãutaþi un FAQ sau regulile grupului pentru a verifica dacã întrebarea dvs. este pe subiect (on-topic). Citiþi o parte din mesajele anterioare înainte de a posta ca sã aveþi o idee despre cum se desfãºoarã discuþiile. De fapt, e o idee bunã sã cãutaþi in arhivele grupului dupã câteva cuvinte cheie ale problemei, înainte de a posta. Puteþi gãsi chiar rãspunsul, sau vã poate ajuta sã formulaþi mai bine întrebarea.

Nu trimiteþi simultan mesaje cãtre toate canalele disponibile, e similar cu strigatul ºi iritã. Luaþi-le pe rând.

Înþelegeþi întâi subiectul! O greºealã clasicã este sã întrebaþi despre interfaþa de programare Unix sau Windows într-un forum dedicat unui limbaj, unei biblioteci sau unelte portabile pe cele două sisteme. Dacã nu vã este clar de ce asta e o problemã, mai bine vã abþineþi pânã vã lãmuriþi.

În general, întrebãrile postate pe un forum public bine ales au ºanse mai bune sã-ºi gãseascã un rãspuns decât aceleaºi întrebãri pe un forum privat, din mai multe motive: în primul rând, masa mai mare de oameni care pot rãspunde. Apoi, mãrimea audienþei; hackerii rãspund mai degrabã unei întrebãri care ajutã mai multã lume, decât celor care sunt de folos doar câtorva persoane.

De înþeles, hackerii talentaþi sau autorii de programe foarte celebre primesc oricum mai multe mesaje greºit adresate decât norma. Puteþi fi picãtura care umple paharul. De mai multe ori, coautori în proiecte cunoscute ºi-au încetat participarea, datoritã numãrului prea mare de mesaje inutile venite pe adresa de mail personalã.

[editeazã]Forumurile Web si canalele IRC orientate cãtre începãtori
Grupul de utilizatori local sau distribuþia dvs. de Linux pot îndruma cãtre forumuri Web sau canale IRC unde începãtorii pot primi ajutor. Astea sunt un bun punct de plecare, mai ales dacã vi se pare cã vã loviþi de o problemã relativ simplã sau comunã. Existenþa unui canal IRC e o invitaþie deschisã sã puneþi întrebãri si puteþi primi adesea rãspunsul imediat.

De fapt, dacã programul care vã creeaza probleme face parte din distribuþie (cum se întâmplã de obicei), e chiar mai bine sã întrebaþi pe liste/forumuri ale distribuþiei respective înainte sã încercaþi pe cele ale proiectului. Hackerii lor s-ar putea sã vã spunã doar „folosiþi versiunea noastrã“.

Înainte de a posta pe un forum Web, verificaþi dacã are o funcþie de cãutare. Dacã da, încercaþi câteva cãutãri referitoare la problema dvs; poate ajutã. Chiar dacã aþi întrebuințat un motor de cãutare pe Web înainte (cum ar fi trebuit), cãutaþi ºi pe forum; e posibil ca nu tot forumul sã fi fost indexat.

Din ce în ce mai frecvent, proiectele oferã asistenþã utilizatorilor pe forumuri Web sau canale IRC, pãstrând listele de email pentru discuþii legate de dezvoltare. Uitaþi-vã întâi dupã primele îndată ce aveþi nevoie de ajutor în legãturã cu un proiect anume.

[editeazã]Pasul doi: listele de email ale proiectului
Când un proiect are o listã de email, scrieþi pe aceasta, nu direct cãtre programatorii implicaþi, chiar dacã vi se pare cã ºtiþi întocmai cine vã poate da cel mai bun rãspuns. Uitaþi-vã în documentaþia proiectului ºi în pagina de Web dupã adresa unei liste de email. Iatã câteva motive:

Orice întrebare suficient de bunã pentru unul dintre programatori va fi interesantã pentru întregul grup. Pe de altã parte, faptul cã întrebarea e prea stupidã pentru listã nu e o scuzã pentru a-i agasa pe programatori personal.
Întrebând pe listã permiteþi o mai bunã împãrþire a muncii între programatori. Un programator individual (în excepțional dacã e vorba despre leader-ul proiectului) poate fi prea ocupat pentru a vã rãspunde.
Majoritatea listelor de email sunt arhivate ºi indexate de motoarele de cãutare. Altcineva va putea gãsi întrebarea dvs. ºi rãspunsurile pe web, în loc sã întrebe din nou pe listã.
Dacã o anumitã întrebare se tot repetã, e o indicaþie cã documentaþia sau chiar software-ul respectiv se pot îmbunãtãþi pentru a fi mai puþin ambigue. Dacã întrebãrile respective s-ar pune în particular, nimeni nu ar avea o vedere de ansamblu asupra întrebãrilor mai frecvente.
Dacã un proiect are atât o listã (sau forum) pentru utilizatori cât ºi una pentru programatori (hackeri) ºi nu lucraþi efectiv cu codul sursã al programului, întrebaþi pe lista pentru utilizatori. Nu presupuneþi cã sunteþi binevenit pe lista de dezvoltare, unde probabil cã întrebarea va fi tratatã ca zgomot.

Bineînþeles, dacã sunteþi sigur cã întrebarea nu e trivialã ºi nu primiþi rãspuns pe lista pentru utilizatori timp de mai multe zile, încercaþi ºi cealaltã listã. Ar fi indicat sã monitorizaþi o perioadã lista, pentru a fi familiar cu obiceiurile grupului (o idee bunã pentru absolut orice listã privatã).

Dacã nu gãsiþi o listã de email pentru un proiect ºi aveþi doar adresa autorului (maintainer), scrieþi-i acestuia. Chiar ºi aºa, nu presupuneþi cã nu existã o listã. Menþionaþi în mesajul dvs. cã nu aþi gãsit-o. De asemenea, menþionaþi cã nu aveþi nimic împotrivã sã vã fie retrimis mesajul cãtre alte persoane. (Mulþi considerã cã mesajele private, chiar dacã nu conþin nimic secret, trebuie sã rãmânã private. Dându-vã acordul pentru retransmiterea mesajului dvs. îi permiteþi sã aleagã el modul de tratare a cererii).

[editeazã]Folosiþi linii de subiect relevante
Pe listele de email, newsgroups sau forumurile Web, linia de subiect vã dã ocazia sã captaþi atenþia experþilor, în circa 50 caractere. Nu o irosiþi cu sintagme de genul „ajutor“ (ca sã nu mai vorbim de „AJUTOR!!!!“; mesajele cu un astfel de subiect vor fi ignorate din reflex). Nu încercaþi sã ne impresionaþi cu dificultãþile dvs; folosiþi acel spaþiu pentru o descriere concisã a problemei.

O convenþie utilã pentru linia de subiect, folositã de multe organizaþii de asistenþã tehnicã, este forma „obiect - deviaþie“. „Obiect“ desemneazã acel lucru care are o problema, iar „deviaþie“ descrie abaterea de la comportamentul aºteptat.

Stupid
AJUTOR! Placa video nu funcþioneazã cum trebuie!!
Inteligent
XFree86 4.1 forma cursorului incorectã, chipset Fooware MV1005
ªi mai inteligent
XFree86 4.1 cursorul mouse-ului, chipset Fooware MV1005 - desenat incorect

Redactarea unui subiect de forma „obiect - deviaþie“ vã va forþa sã gândiþi problema în detaliu. Ce anume este afectat? Doar cursorul mouse-ului, sau ºi restul graficii? Se întâmplã doar cu XFree86? Doar cu versiunea 4.1? Se întâmplã doar cu chipset-ul Fooware? Doar cu modelul MV1005? Un hacker care vede un astfel de subiect poate înþelege imediat cu ce anume aveþi probleme ºi care sunt acelea.

Imaginaþi-vã cã vã uitaþi la index-ul arhivei de întrebãri, care vã aratã doar liniile de subiect. Faceþi în aºa fel încât subiectul sã reflecte întrebarea suficient de bine încât urmãtoarea persoanã care va cãuta în arhivã rãspunsul la o întrebare similarã cu a dvs. sã o gãseascã uºor ºi sã nu întrebe din nou acelaºi lucru.

Dacã puneþi o întrebare într-un rãspuns (reply la un email anterior), schimbaþi linia de subiect pentru a se vedea cã puneþi o întrebare. Un subiect ca "Re: test" sau "Re: new bug" e puþin probabil sã atragã atenþia. De asemenea, ºtergeþi din mesaj textul vechi, pãstrând un minim necesar pentru a-l face coerent pentru cititori noi.

Nu folosiþi funcþia "reply" pe un mesaj de pe listã pentru a porni un thread nou, fãrã legãturã, sau vã limitaþi audienþa. Unii clienþi de mail, ca mutt, permit utilizatorului sã sorteze mesajele dupã thread ºi sã împacheteze (fold) toate mesajele dintr-un thread într-o singurã linie de subiect. Cei care fac asta, pur ºi necomplicat nu vor vedea mesajul dvs.

Schimbarea liniei de subiect nu este suficientã. Mutt, probabil ºi alte programe, se uitã la alte informaþii din header-ul mesajelor pentru a determina thread-ul din care fac parte, nu la linia de subiect. Scrieþi un mesaj nou.

Pe forumurile Web regulile sunt puþin diferite, deoarece mesajele sunt de obicei legate de un thread ºi nu sunt vizibile decât în contextul acelui thread. Schimbarea subiectului pentru a pune o întrebare nu este esenþialã (nu toate forumurile îngăduie linii diverse de subiect la fiecare mesaj, ºi oricum nu le citeºte nimeni). Dar a pune o întrebare într-un thread existent e o practicã dubioasã, pentru cã întrebarea nu va fi vãzutã decât de cei care urmãresc acel thread. Deci, dacã nu sunteþi extraordinar de sigur cã vreþi un rãspuns doar de la cei activi în thread, porniþi unul nou.

[editeazã]Nu îngreunaþi rãspunsul
Dacã încheiaþi mesajul cu „Vã rog sã rãspundeþi pe adresa...“, e cumplit de puþin probabil sã vã rãspundã cineva. Dacã nu puteþi fi deranjat pentru câteva secunde sã setaþi câmpul Reply-To din header, nici noi nu putem fi deranjaþi pentru a ne gândi la problema dvs. Dacã programul de mail nu vã permite acest lucru, folosiþi unul mai bun. Dacã sistemul dvs. de operare nu are un program care sã permitã acest lucru, folosiþi un sistem de operare mai bun.

Pe forumurile Web e nepoliticos sã solicitaþi un rãspuns direct pe email în afara cazului în care informaþia pe care o solicitaþi e confidenþialã (ºi consideraþi dintr-un motiv oarecare cã cineva e dispus sã v-o transmitã doar dvs, nu ºi celorlalþi de pe forum). Dacã doriþi sã primiþi un rãspuns pe email configuraþi forumul sã îl trimitã astfel; aceastã facilitate este foarte rãspânditã, o puteþi gãsi sub numele „watch this thread“, „send email on answers“ etc).

[editeazã]Folosiþi un limbaj clar, corect gramatical ºi ortografic
Experienþa ne aratã cã cei dezordonaþi sau neatenþi la scriere, sunt la fel ºi în gândire sau programare (suficient de frecvent încât aceasta sã fie regula, nu excepþia). Rãspunsul la întrebãrile neatenþilor ºi dezordonaþilor nu ne aduce vreo satisfacþie; mai bine facem altceva.

Aºadar, e important sã vã exprimaþi ideile clar ºi corect. Dacã nu sunteþi dispuºi sã faceþi efortul acesta, nici noi nu suntem dispuºi sã vã acordãm atenþie. Cizelaþi-vã limbajul. Nu trebuie sã fie rigid sau sã sune oficial, hackerii apreciazã un limbaj informal, slang-ul ºi umorul, atunci când sunt folosite cu precizie. Dar trebuie sã fie precise, pentru a arãta cã gândiþi ºi sunteþi atent.

Ortografia, punctuaþia, trebuie sã fie corecte. Nu încurcaþi (în englezã) „its“ cu „it's“, „loose“ cu „lose“ sau „discrete“ cu „discreet“. NU FOLOSIÞI DOAR LITERE MARI, se considerã cã þipaþi (scrisul doar cu litere mici e doar ceva mai puþin enervant, pentru cã este dificil de urmãrit. Alan Cox este scuzat, dvs. nu).

În general, dacã scrieþi ca un semi-analfabet, e foarte probabil sã fiþi ignorat. Limbajul l33t skript kiddie h4x0r este reþeta sigurã ce garanteazã cã nu veþi primi nimic în afarã de tãcere (sau, în cel mai bun caz, dispreþ ºi sarcasm).

Dacã folosiþi altã limbã decât cea maternã, veþi fi tratat cu oarece îngãduinþã pentru erorile gramaticale sau ortografice, dar nu mai mult. Lenea tot nu va fi toleratã (ºi da, de obicei diferenþa e sesizabilã). De asemenea, dacã nu ºtiþi ce limbi vorbesc ceilalþi, folosiþi engleza. Întrebãrile în limbi strãine majoritãþii vor fi bineînþeles ignorate, iar engleza este limba universalã pe Internet. Scriind în englezã scad ºansele ca întrebarea dvs. sã fie ignoratã.

[editeazã]Folosiþi un compus uºor de citit
Dacã faceþi întrebarea greu de citit în mod artificial, ea va fi mai degrabã ignoratã în favoarea altora. Aºadar:

trimiteþi email text, nu HTML
ataºamentele sunt de obicei OK, dar numai când au un conþinut relevant (ca de exemplu fiºiere sursã sau patch), ºi nu adãugate automat de clientul dvs de mail (cum ar fi o copie a mesajului dvs în alt format)
nu trimiteþi mesaje în care paragrafe întregi sunt scrise pe o singurã linie (e greu de rãspuns doar la o porþiune din mesaj). Presupuneþi cã cititorii folosesc un ecran text de 80 caractere lãþime ºi spargeþi rândurile în consecinþã, la ceva mai puþin de 80 caractere.
în schimb, nu spargeþi la o coloanã fixatã rândurile ce conþin date (loguri, istoric de comenzi). Datele trebuie incluse exact în forma în care au fost generate, pentru ca cititorii sã vadã acelaºi lucru pe care l-aþi vãzut si dvs.
nu folosiþi codarea MIME Quoted-Printable pe un forum de limbã englezã. Aceastã codare poate e necesarã când folosiþi o limbã pentru care kitul ASCII nu e suficient, dar nu este suportatã de toþi agenþii de mail. Când nu este interpretatã corect, apar acele semne urâte (=20) prin text.
nu vã aºteptaþi niciodatã sã putem citi formate de document proprietare ca Microsoft Word sau Excel. Majoritatea reacþionãm la aºa ceva cam cum ar reacþiona oricine la vederea unei balegi la intrarea în casã. Chiar când putem, tehnic vorbind, sã le citim, urâm chestia asta.
dacã trimiteþi email din Windows, opriþi facilitatea stupidã a Microsoft numitã „Smart Quotes“ pentru a evita apariþia de caractere în plus în mesaj
pe forumurile Web, nu abuzaþi de smiley-uri si facilitãþile HTML (când existã). Unul-douã smiley-uri sunt OK, dar colorarea cât mai variatã a textului e neserioasã. Abuzul de smiley-uri, culori ºi fonturi vã recomandã ca pe o adolescentã jucãuºã, o idee nu nespus de bunã, în afarã de cazul în care sunteþi mai atras de sex decât de un rãspuns.
Dacã folosiþi un client de mail cu interfaþã în mod grafic (Netscape Messenger, MS Outlook sau altele asemenea) aveþi grijã: puteþi încãlca aceste reguli folosind setãrile implicite. Majoritatea au o comandã „View Source“ în meniu. Folosiþi-o pe mesajele deja trimise pentru a verifica dacã trimiteþi doar text sau ºi alte lucruri inutile.

[editeazã]Fiþi precis în descrierea problemei
descrieþi clar simptomele problemei sau bug-ului
descrieþi mediul în care apar (arhitecturã, sistem de operare, aplicaþie, etc). Precizaþi versiunea distribuþiei folosite (ex: „Fedora Core 2“, „Slackware 9.1“, etc).
descrieþi investigaþiile pe care le-aþi fãcut asupra problemei
descrieþi etapele pe care le-aþi parcurs pentru a diagnostica problema
descrieþi schimbãrile recente în configuraþia calculatorului (hardware ºi software) care ar putea fi relevante
încercaþi sã anticipaþi întrebãrile ajutãtoare pe care hackerii vi le-ar putea pune ºi pe cât posibil furnizaþi acele informaþii în avans. Simon Tatham a scris un eseu intitulat How to Report Bugs Effectively pe care vi-l recomand cu cãldurã.
[editeazã]Multe informaþii nu înseamnã precizie
A fi precis nu înseamnã sã puneþi cantitãþi uriaºe de cod sursã sau date într-o cerere de ajutor. Dacã aveþi un test complicat la care aplicaþia nu se comportã corect, încercaþi sã-l reduceþi la minimul necesar care declanºeazã problema.

Lucrul ãsta e folositor din cel puþin trei motive. Unu: va fi evident cã aþi depus eforturi pentru simplificarea întrebãrii, ceea ce vã sporeºte ºansele de a primi un rãspuns. Doi: simplificarea întrebãrii face mai probabilã primirea unui rãspuns folositor. Trei: rafinând formularea problemei e posibil sã gãsiþi solitar o rezolvare sau metodã de evitare a problemei.

[editeazã]Nu pretindeþi cã aþi descoperit un bug
Când aveþi o problemã cu un program, nu pretindeþi cã aþi gãsit un bug decât dacã sunteþi foarte, foarte sigur. Sfat: dacã nu puteþi furniza cod sursã care reparã problema sau un test care sã demonstreze regresia faþã de o versiune anterioarã, probabil nu puteþi fi suficient de sigur. Acest lucru este valabil ºi pentru paginile de web sau documentaþie. Dacã gãsiþi un bug în documentaþie, ar trebui sã prezentaþi un text corect ºi locul în care trebuie aºezat în documentaþie.

Þineþi cont cã sunt mulþi alþi utilizatori care nu au problema dvs. Altfel, aþi fi aflat despre ea citind documentaþia ºi cãutând pe web (aþi fãcut asta, nu?). E destul de posibil sã faceþi dvs. ceva greºit, nu programul.

Cei care au scris programul lucreazã din greu pentru a-l face sã funcþioneze cât mai bine. Dacã pretindeþi cã aþi gãsit un bug, sugeraþi cã ei au fãcut ceva greºit, ºi e posibil sã-i jigniþi chiar dacã aveþi dreptate. Nu e deloc diplomatic sã includeþi cuvântul „bug“ în linia de subiect a mesajului.

Când puneþi întrebarea, e bine sã o formulaþi plecând de la presupunerea ca dvs sunteþi cel care face ceva greºit, chiar dacã în particular sunteþi teribil de sigur cã aþi gãsit un bug. Dacã într-adevãr e un bug, veþi afla despre asta într-un rãspuns. E preferabil sã se scuze autorii dacã bug-ul e real, decât sã fiþi pus în aceeaºi situaþie în caz cã v-aþi înºelat.

[editeazã]Milogeala nu impresioneazã ºi nu înlocuieºte efortul propriu
Unii oameni care au înþeles cã nu trebuie sã fie aroganþi sau nepoliticoºi când cer ajutor cad în extrema cealaltã: „ªtiu cã sunt un biet începãtor neajutorat, dar...“. Atitudinea asta e enervantã mai ales atunci când este însoþitã de o descriere prea vagã a problemei.

Nu pierdeþi timpul (dvs. ºi al nostru) cu astfel de maimuþãreli. Prezentaþi contextul ºi întrebarea cât de clar puteþi. Vã pune într-o luminã mai bunã decât cea descrisã mai sus.

Uneori forumurile Web au secþiuni dedicate începãtorilor. Dacã vi se pare cã aveþi o întrebare de începãtor, acolo îi e locul, dar nu exageraþi cu milogeala nici acolo.

[editeazã]Descrieþi simptomele problemei, nu presupunerile dvs
Nu e deloc folositor sã le spuneþi hackerilor ce credeþi cã poate cauza probleme (dacã aþi fi atât de bun la diagnozã, aþi mai cere ajutorul altora?). Descrieþi exact simptomele observate, nu interpretãri ºi teorii proprii. Lãsaþi-i pe ei sã facã interpretãrile. Dacã o presupunere a dvs. vi se pare foarte relevantã, introduceþi-o ca atare („Eu cred cã...“) ºi arãtaþi de ce e insuficientã pentru rezolvarea problemei.

Stupid
Primesc frecvent SIG11 la compilarea kernel-ului, bãnuiesc cã un traseu e crãpat pe placa de bazã. Cum verific aºa ceva?
Inteligent
Pe un K6/233 cu placa de bazã FIC-PA2007 (chipset VIA Apollo VP2) cu 256MB Corsair PC133, primesc din ce în ce mai des SIG11 la circa 20 momente de la pornire, când compilez un kernel (niciodatã în primele 20 minute). Dupã un reboot problema reapare imediat, dar dupã ce-l las stins peste seară nu. Am schimbat RAM-ul, nu ajutã. Aºa aratã mesajele de eroare la compilare [...]
[editeazã]Descrieþi simptomele problemei în ordine cronologicã
Cele mai utile indicii despre natura unei probleme care apare frecvent, sunt evenimentele dinaintea manifestãrii acesteia. Ar trebui, deci, sã descrieþi ce fãceaþi în momentul în care a apãrut problema. Dacã e vorba de comenzi din linia de comandã, un log al sesiunii care sã conþinã ultimele circa 20 linii poate fi foarte util.

Dacã programul care a crãpat are opþiuni pentru diagnostic (ex: -v pentru verbose), gândiþi-vã ce informaþii furnizate pot fi utile ºi includeþi-le în log.

Dacã textul ajunge sã fie foarte lung (mai lung de circa patru paragrafe), descrieþi sumar problema la început, urmând apoi detaliile în ordine cronologicã. Hackerii care vã citesc o sã aibã o idee la ce sã se aºtepte.

[editeazã]Descrieþi obiectivul, nu paºii intermediari
Dacã încercaþi sã aflaþi cum puteþi face un lucru (spre deosebire de cazul în care raportaþi un bug), începeþi prin a vã descrie obiectivul. Doar dupã aceea descrieþi etapa intermediarã la care v-aþi blocat.

Adesea cei care au nevoie de ajutor au în minte un obiectiv greu de atins dar rãmân blocaþi într-o etapã pe care o considerã necesarã pentru realizarea acelui obiectiv. Atunci, ei solicitã ajutor pentru a depãºi etapa, dar nu îºi dau seama cã poate calea aleasã e greºitã.

Stupid
Cum fac sã selectez culorile în FooDraw, dându-le valorile hexazecimale?
Inteligent
Încerc sã schimb (în FooDraw) paleta de culori a unei imagini. Singurul mod în care cred cã s-ar putea face asta e sã schimb manual fiecare nuanță din paletã, dar nu îmi dau seama cum se introduc direct valorile hexazecimale pentru culori.
A doua întrebare este mai bunã, pentru cã permite formularea unui rãspuns în care sã se sugereze un instrument mai potrivit pentru sarcina respectivã.

[editeazã]Nu solicitaþi rãspunsuri private
Hackerii considerã cã rezolvãrile provocărilor trebuie sã fie fãcute în public, printr-un proces transparent în care primele tentative de rãspuns ar trebui sã fie corectate de cãtre cei mai experimentaþi, când aceºtia observã cã sunt incomplete sau incorecte. În acest fel ei pot fi recompensaþi prin recunoaºterea competenþelor ºi cunoºtinþelor de cãtre comunitate.

Când cereþi un rãspuns privat întrerupeþi procesul în sine ºi anulaþi potenþialele beneficii. Nu faceþi acest lucru. Este alegerea celui care rãspunde sã o facã privat, ºi acest lucru se întâmplã de obicei pentru cã întrebarea e ***** formulatã sau atât de banalã încât nu prezintã interes pentru ceilalþi.

Existã o singurã excepþie de la regulã. Dacã întrebarea e probabil sã genereze multe rãspunsuri similare, cuvintele magice sunt "trimiteþi-mi mie rãspunsurile, ºi o sã fac un rezumat pe listã ". E distins sã preveniþi încãrcarea listei de mail sau newsgroup-ului cu o mare de rãspunsuri, majoritatea identice (trebuie sã vã þineþi de cuvânt cu rezumatul).

[editeazã]Puneþi întrebãri concrete, punctuale
Întrebãrile deschise dezbaterilor tind sã fie vãzute ca pierdere de vreme. Ființele care vã pot da cele mai folositoare rãspunsuri sunt totodatã ºi cele mai ocupate (fie ºi pentru cã ei sunt cei care au cel mai mult de contribuit). Ei sunt de obicei alergici la chestiuni care pot mânca un timp nedeterminat, aºa cã nu apreciazã acest gen de întrebãri.

E mai probabil sã primiþi un rãspuns folositor dacã prezentaþi o problemã concretã (solicitaþi indicaþii, trimiteþi cod, doriþi validarea unui patch, etc). Îºi vor putea astfel concentra atenþia asupra problemei ºi vor putea pune o limitã superioarã a timpului alocat dvs.

Pentru a înþelege, gândiþi-vã la expertiza lor ca la o resursã abundentã ºi la timpul disponibil ca la o resursã rarã. Cu cât solicitaþi mai puþin timp alocat, cu atât e mai probabil sã primiþi un rãspuns de la un hacker foarte bun dar foarte ocupat.

E bine deci sã încercaþi minimizarea timpului necesar pentru a vã rãspunde, ceea ce nu e întotdeauna acelaºi lucru cu simplificarea problemei. De exemplu, „Puteþi sã-mi indicaþi o explicaþie bunã pentru X?“ e o întrebare mult mai bunã decât „Puteþi sã-mi explicaþi X, vã rog?“ Dacã aveþi un program care nu funcþioneazã, e mai bine de obicei sã întrebaþi ce este greºit în cod decât sã cereþi sã vi-l repare cineva.

[editeazã]Nu puneþi întrebãri din tema pentru acasã
Hackerii depisteazã uºor astfel de întrebãri, pentru cã pe majoritatea le-am rezolvat ºi noi. Acele probleme sunt pentru ca dvs sã le rezolvaþi, ca sã învãþaþi ceva. E OK sã cereþi mici indicaþii, dar nu soluþia completã.

Dacã suspectaþi cã o întrebare ce v-a fost adresatã face parte din aceastã categorie, dar totuºi nu aveþi un rãspuns, puteþi încerca sã întrebaþi în grupurile de utilizatori sau (în ultimã instanþã) pe listele pentru utilizatori. În timp ce hackerii vor depista natura problemei, utilizatorii mai avansaþi vã pot da mãcar unele indicaþii.

[editeazã]Reduceþi numãrul întrebãrilor irelevante
Rezistaþi tentaþiei de a încheia mesajele cu întrebãri lipsite de conþinut de genul „Poate sã mã ajute cineva?“ sau „Exista vreo soluþie?“. În primul rând, dacã aþi descris mãcar pe jumãtate coerent problema, astfel de adãugiri sunt superflue. În al doilea rând, pentru cã sunt superflue, sunt iritante ºi vi se poate rãspunde cât se poate de corect din punct de vedere logic "Da" sau "Nu te poate ajuta nimeni."

În general, este bine sã evitaþi întrebãrile cu rãspuns da/nu. yes-or-no answer

[editeazã]Urgent pentru dvs, nu ºi pentru noi
Nu solicitaþi un rãspuns rapid, chiar dacã aveþi nevoie de el, marcând mesajul ca Urgent. E problema dvs, nu a noastrã. Mimarea unei urgenþe e neproductivã: majoritatea hackerilor va ºterge pur ºi simplu mesajul, ca o încercare egoistã ºi obraznicã de a primi atenþie specialã.

Existã o micã excepþie de la regulã. Dacã menþionaþi cã folosiþi un program în circumstanþe ce-i oferã o expunere publicã mare, e posibil sã primiþi atenþie; într-o astfel de situaþie, dacã sunteþi presat de timp, ºi spuneþi asta politicos, aveþi ºansa sã primiþi un rãspuns mai rapid.

Este totuºi riscant sã faceþi presupuneri cã hackerii vor fi interesaþi doar din acest motiv, valorile lor fiind probabil diferite. Sã postaþi de pe Staþia Spaþialã Internaþionalã probabil cã se calificã, dar dacã postaþi din partea unei mari organizaþii caritabile sau politice aproximativ sigur nu. Un mesaj de genul "Urgent: ajutaþi-mã sã salvez balenele verzi!" vã va face þinta unui flame chiar din bucată hackerilor care considerã salvarea balenelor verzi un lucru important.

Dacã nu vã este clar de ce e aºa, recitiþi acest document pânã când înþelegeþi, înainte sã postaþi în vreun fel.

[editeazã]Puþinã politeþe nu stricã
Fiþi politicos. Folosiþi "Vã rog" ºi "Mulþumesc pentru atenþie". Arãtaþi cã apreciaþi faptul cã sunteþi ajutat gratis.

Sincer, politeþea nu este la fel de importantã (ºi nu este un substitut) ca scrierea corectã, clarã, precisã, evitarea formatelor proprietare, etc; am prefera sã primim mesaje mai abrupte, dar tehnice, decât unele vagi, umplute de politeþuri (þineþi cont cã ne plac problemele din care avem ceva de învãþat).

Totuºi, dacã nu sunteþi foarte tehnic, puþinã politeþe vã va ajuta sã primiþi un rãspuns.

(Trebuie menþionat cã singura obiecþie serioasã pe care am primit-o de la hackeri veterani la acest HOWTO, se referea la recomandarea noastrã anterioarã de a folosi "Mulþumesc cu anticipaþie". Unii au considerat cã sugereazã intenþia de a nu mulþumi ulterior. Recomandarea noastrã e fie sã folosiþi "Mulþumesc cu anticipaþie" ºi sã mulþumiþi ulterior celor care v-au rãspuns, sau sã folosiþi doar la final o formulã de genul "Mulþumesc pentru atenþie")

[editeazã]Reveniþi cu descrierea soluþiei
Dupã rezolvarea problemei, reveniþi cu un limitat mesaj pentru cei care v-au ajutat; spuneþi-le ce-a ieºit ºi mulþumiþi-le pentru ajutor. Dacã problema a captat suficient interes pe o listã de mail sau newsgroup, acolo ar trebui sã postaþi aceastã notiþã.

Ideal, rãspunsul ar trebui sã fie în thread-ul pornit de la întrebarea iniþialã ºi ar trebui sã fie etichetat cu ceva de genul REZOLVAT în linia de subiect. Pe listele cu trafic mare, un cititor care va vedea un thread despre "problema X" va ºti sã nu piardã timpul cu acel thread dacã vede un mesaj cu subiectul "problema X - REZOLVAT" (în afarã de cazul în care problema este interesantã pentru el) ºi îºi poate folosi timpul rezolvând alte probleme.

Notiþa finalã nu trebuie sã fie lungã; un simplu "Salut, era un cablu defect. Mulþumesc tuturor. - Bill" e mai bun decât nimic. De fapt, un sumar este mai bun decât o expunere pe larg, dacã problema nu era grozav de complexã. Spuneþi ce anume a rezolvat problema, dar nu e nevoie sã repetaþi toatã secvenþa cu diagnosticul.

Pentru problemele mai complexe, puteþi descrie pe scurt cum a decurs analiza. Prezentaþi formularea finalã a problemei. Spuneþi întâi ce a funcþionat ca soluþie ºi indicaþi potenþialele cãi care nu duc în final la nici un rezultat. Cãile greºite de rezolvare trebuie sã aparã dupã metoda corectã ºi celelalte detalii, pentru a nu transforma totul într-un roman poliþist. Numiþi persoanele care v-au ajutat; o sã vi-i apropiaþi în acest fel.

Un astfel de sumar va fi gãsit de cei care cautã în arhiva listei/newsgroup-ului ºi le va indica exact ce a funcþionat pentru dvs., putându-i ajuta eventual ºi pe ei.

În ultimul rând, mesajul dvs va da satisfacþie tuturor celor implicaþi, arãtând cã problema a fost rezolvatã. Dacã nu sunteþi o persoanã tehnicã sau hacker, credeþi-ne pe cuvânt cã sentimentul e foarte important pentru acei guru ºi specialiºti care v-au ajutat. Problemele care se lungesc ºi nu au o finalitate sunt frustrante; hackerii simt nevoia de a le vedea rezolvate. Karma câºtigatã rãspunzând acestei dorinþe o sa vã fie de mare ajutor data viitoare când aveþi nevoie sã întrebaþi ceva.

Gândiþi-vã cum îi puteþi ajuta pe alþii sã nu aibã aceeaºi problemã în viitor. Întrebaþi-vã dacã o micã menþiune în FAQ sau documentaþie ar ajuta, ºi dacã da, faceþi-o ºi trimiteþi-o celui care se ocupã de ele.

Printre hackeri, acest comportament e mult mai important decât politeþea convenþionalã. În acest fel câºtigaþi o reputaþie de bun jucãtor, un câºtig important pentru dvs.

[editeazã]Cum se interpreteazã rãspunsurile
[editeazã]RTFM ºi STFW: cum îþi dai seama cã ai sfeclit-o
E o veche tradiþie: dacã primiþi un rãspuns care conþine doar "RTFM" (Read The Fucking Manual), cel care vi l-a trimis considerã cã ar fi trebuit sã citiþi manualul. Aproape sigur are dreptate. Citiþi-l!

RTFM are o rudã mai tânãrã. Dacã rãspunsul conþine doar "STFW" (Search The Fucking Web), cel care vi l-a trimis considerã cã ar fi trebuit sã cãutaþi pe Web. Aproape sigur are dreptate. Cãutaþi! (Varianta mai puþin durã este "Google este prietenul tãu!").

Pe un forum Web, vi se poate spune sã cãutaþi în arhivele forumului. Cineva v-ar putea chiar indica un thread anterior în care s-a discutat deja problema. Nu vã bazaþi pe asta; cãutaþi înainte de a întreba.

De multe ori, cel care vã rãspunde aºa are manualul sau o paginã de web în faþã ºi poate vedea cã (a) informaþia pe care o cereþi e uºor de gãsit ºi (b) considerã cã veþi învãþa mai mult cãutând singur decât dacã vi se dã "murã-n gurã".

Nu ar trebui sã vã simþiþi jignit; dupã standardele noastre vã trateazã cu respect prin simplul fapt cã nu vã ignorã. Ar trebui sã-i fiþi recunoscãtor pentru bunãvoinþã.

[editeazã]Dacã nu înþelegeþi...
Dacã nu înþelegeþi un rãspuns, nu cereþi imediat clarificãri. Folosiþi aceleaºi unelte ca înainte de a întreba (manual, FAQ, web, etc) pentru a-l înþelege. Dacã tot e nevoie sã cereþi lãmuriri, arãtaþi ce-aþi învãþat.

De exemplu, dacã vã spun: "Se pare cã aveþi un zentry agãþat; trebuie resetat", nu veniþi cu "Ce e un zentry?" în loc de "OK, am citit manualul ºi zentry-urile sunt menþionate la opþiunile -z ºi -p. Niciuna nu se referã la resetarea lor. E una din ele, sau îmi scapã ceva?"

[editeazã]Cum sã trataþi obrãzniciile
Mult din ce poate pãrea obrãznicie, în cercurile noastre nu este intenþionat jignitor. E mai degrabã un produs al stilului direct de comunicare între persoane mai atente la rezolvarea dificultăților decât la menajarea sentimentelor.

Când simþiþi aºa ceva, încercaþi sã rãmâneþi calm. Dacã cineva depãºeºte limitele, e foarte probabil ca un veteran sã-i atragã atenþia. Dacã lucrul ãsta nu se întâmplã ºi dvs vã pierdeþi calmul cu cineva, e posibil ca acela sã se fi purtat în normele obiºnuite ºi dvs sã cãdeþi vinovat. Bineînþeles, vã vor scãdea ºansele sã primiþi informaþiile solicitate.

Pe de altã parte, ocazional o sã fiþi întâmpinat cu obrãznicii ºi comportament agresiv, neîndreptãþite. E acceptabil în acest caz sã îl muºtruluiþi sever pe ofensator. Când faceþi asta, însã, fiþi foarte, foarte sigur pe poziþia dvs. Linia între o mustrare pentru comportament ºi pornirea unui flame-war inutil e atât de subþire încât chiar hackerii o trec de multe ori; dacã sunteþi un nou venit, ºansele sunt mari ca discuþia sã degenereze. Dacã aþi venit pentru informaþii, nu distracþie, e mai bine sã nu riscaþi ºi sã lãsaþi tastatura în pace.

(Unii susþin cã mulþi hackeri suferã de o formã de autism sau Sindromul Asperger, ºi le lipsesc câteva circuite din creier care controleazã interacþiunea socialã. Poate e, poate nu e adevãrat. Dacã nu sunteþi hacker, ar ajuta sã puteþi tolera excentricitãþile noastre, chiar dacã sunteþi convins cã nu suntem normali. N-aveþi decât. Nu ne intereseazã; ne place sã fim ceea ce suntem, si suntem în general sceptici la diagnostice de acest gen).

În secþiunea urmãtoare vom vorbi despre altceva: genul de obrãznicii pe care le veþi întâlni când dvs vã comportaþi greºit.

[editeazã]Cum sã nu vã purtaþi ca un loser
ªansele sunt ca mai devreme sau mai târziu sã intraþi în conflict cu comunitatea hackerilor, chiar de mai multe ori, în maniere descrise aici sau similare. Vi se va spune exact ce-aþi greºit, probabil într-o manierã mai coloratã. În public.

Când se întâmplã aºa ceva, cel mai rãu lucru pe care-l puteþi face e sã vã plângeþi despre ceea ce vi s-a întâmplat, sã pretindeþi scuze, zbieraþi, declaraþi greva foamei, ameninþaþi cu procese, pârâþi la angajatori, etc. Iatã ce-aveþi de fãcut:

Depãºiþi momentul. E normal. E chiar sãnãtos ºi benefic.

Standardele comunitãþii nu se þin singure: sunt þinute de cei care le aplicã, vizibil, în public. Nu vã plângeþi cã nu v-au fost adresate criticile în particular: nu aºa merge. Nu e deloc folositor sã insistaþi cã aþi fost insultat când cineva spune cã nu aveþi dreptate sau cã e de altã pãrere. Sunt atitudini de loser.

Pe anumite forumuri de hackeri, dintr-o ***** înþeleasã politeþe, s-a interzis comentarea greºelilor din post-uri, cu regula "Nu spuneþi nimic, decât dacã vreþi sã ajutaþi.". Rezultatul a fost cã persoanele cu contribuþii valoroase au plecat, lãsând forumul inutilizabil ca forum tehnic.

Alegeþi: ori exagerat de prietenos (în sensul de mai sus) ori eficace.

Reþineþi: când un hacker vã spune c-aþi greºit ºi vã cere sã nu se repete (indiferent cât de abrupt), o face în beneficiul (1) dvs ºi (2) al comunitãþii. Ar fi mult mai uºor pentru el sã vã ignore ºi sã filtreze mesajele dvs. Dacã nu puteþi fi recunoscãtor, aveþi mãcar un minim de demnitate, nu vã plângeþi ºi nu aºteptaþi sã fiþi tratat ca o pãpuºã fragilã doar pentru cã sunteþi nou-venit, cu fire hipersensibilã ºi iluzii de mãrire.

Uneori veþi fi atacat personal de cineva, fãrã un motiv aparent, chiar dacã nu aþi greºit (sau aþi greºit doar în imaginaþia unora). În acest caz, dacã vã plângeþi e sigur cã o sã o încurcaþi.

De obicei, aceºtia sunt habarniºtii care se considerã experþi, sau pseudo-psihologi care vã testeazã limitele. Ceilalþi cititori ori îi ignorã, ori gãsesc alte modalitãþi de a-i trata. Comportamentul acesta le creeazã doar lor probleme ºi nu ar trebui sã vã priveascã.

Nu vã lãsaþi antrenat în flame-war-uri. Cel mai bine le ignoraþi, dupã ce verificaþi cã sunt într-adevãr flame-uri ºi nu indicaþii despre ce-aþi greºit, ºi nici sugestii subtil formulate referitoare la problema dvs (se poate întâmpla).

[editeazã]Întrebãri pe care sã nu le puneþi
Iatã câteva exemple clasice de întrebãri stupide ºi la ce se gândesc hackerii când nu le rãspund.

I: Unde gãsesc programul X ?

R: Unde l-aº gãsi ºi eu, deºteptule, pe pagina de rezultate a unei cãutãri pe Web. Nu ºtii sã foloseºti Google?

I: Cum folosesc X ca sã fac Y ?

R: Dacã vrei sã faci Y, ar trebui sã întrebi cum se face fãrã sã presupui o metodã care, poate, nu e potrivitã. Întrebãrile de forma asta adesea indicã o persoanã care nu doar cã nu ºtie nimic despre X, dar nici nu ºtie foarte bine ce vrea sã facã ºi e pierdutã în detalii. De cele mai multe ori e mai bine sã fie ignoratã pânã poate formula problema mai bine.

I: Cum îmi pot configura prompt-ul shell-ului?

R: Dacã ºtii destule încât sã întrebi asta, ºtii ºi cã rãspunsul e în manual.

I: Pot sã folosesc Bass-o-matic ca sã convertesc un document AcmeCorp în TeX ?

R: Încearcã ºi vezi. Dacã ai fi fãcut-o, a) ºtiai rãspunsul ºi b) nu-mi pierdeai timpul

I: {Programul, configuraþia, comanda SQL} nu merge

R: Asta nu e o întrebare, ºi n-am de gând sã extrag informaþii cu forceps-ul de la tine, am alte lucruri mai bune de fãcut. Când vãd aºa ceva, reacþia mea e una dintre:

mai ai ceva de adãugat?
ce nasol, sper sã se rezolve
ºi ce treaba am eu cu asta?
I: Am probleme cu staþia mea Windows. Mã puteþi ajuta?

R: Da, aruncã rahatul ãla de la Microsoft ºi instaleazã-þi Linux sau BSD.

Notã: puteþi pune întrebãri referitoare la maºini Windows dacã sunt despre un program care funcþioneazã ºi pe Windows, sau interacþioneazã cu maºini Windows (adicã Samba). Nu fiþi surprins dacã vi se rãspunde cã problema e în Windows, nu în program, pentru cã Windows e atât de ***** încât situaþia e frecventã.

I: Am un program care nu merge. Cred cã biblioteca X e defectã.

R: Deºi e sublim posibil sã fiþi primul care observã o problemã cu apelurile sistem sau bibliotecile folosite puternic de sute ºi mii de oameni, e mult mai probabil cã nu ºtii despre ce vorbeºti. Acuzaþiile serioase necesitã dovezi serioase; când faceþi o astfel de afirmaþie, trebuie sã documentaþi eroarea pe larg.

I: Am nereguli când instalez Linux sau X. Mã puteþi ajuta?

R: Nu, trebuie sã fiu lângã tine ca sã fac asta. Întreabã utilizatorii locali de Linux.

Notã: întrebãrile despre instalarea Linux sunt binevenite pe un forum sau listã despre o distribuþie anume, dacã problema este specificã acelei distribuþii; de asemenea, pe forumurile locale de utilizatori, caz în care descrieþi precis ce nu funcþioneazã. Cãutaþi cu grijã însã, folosind ºi cuvântul cheie "linux", informaþii despre hardware-ul suspect.

I: Cum pot sã sparg parola de root/cãstig drepturi de operator/citesc emailul cuiva?

R: Eºti un ticãlos cã încerci sã faci asta ºi un ***** cã ceri unui hacker sã te ajute.

[editeazã]Întrebãri bune, întrebãri greºite
În final, o sã demonstrez cum se pun întrebãrile inteligent, prin exemple; perechi de întrebãri despre aceeaºi problemã, una stupidã ºi una inteligentã.

Stupid
Unde gãsesc ceva despre Foonly Flurbamatic?
Întrebarea cere un STFW.

Inteligent
Am încercat sã gãsesc ceva pe Google despre Foonly Flurbamatic 2600, dar nu am gãsit nimic interesant. Unde aº putea gãsi documentaþie despre programarea lui?
A trecut de STFW, se pare cã are o problemã realã.

Stupid
foo nu se compileazã. De ce e buºit?
Presupune cã altcineva a greºit. Arogant.

Inteligent
foo nu se compileazã pe Nulix 6.2. În FAQ nu e menþionat nimic special despre Nulix. Iatã un log al compilãrii. Fac eu ceva greºit?
A descris contextul, a citit FAQ, aratã care e eroarea ºi nu presupune cã problema e din vina altcuiva. Poate meritã atenþie.

Stupid
Am probleme cu placa de baza. Poate sã mã ajute cineva?
"Aha. Ai nevoie ºi sã-þi schimbãm scutecele?", urmat de apãsarea tastei Del.

Inteligent
Am încercat X, Y ºi Z pe o placã de bazã S2464. Nu a mers, aºa cã am încercat A, B ºi C. Când am fãcut C s-a întâmplat, dubios, D. E clar cã ciocoflenderul se brustureºte, dar nu cum ar trebui. Care sunt cauzele uzuale de brusturire pe plãcile Athlon MP? Puteþi sã-mi mai sugeraþi alte teste pe care le pot face?
Ãsta, pe de altã parte, meritã un rãspuns. A demonstrat cã-ºi foloseºte creierul, în loc sã aºtepte sã-l loveascã o soluþie.

La ultima întrebare, observaþi ºi distincþia între "Daþi-mi o soluþie" ºi "Vã rog sã mã ajutaþi sã-mi dau seama ce nu merge".

Ultima întrebare e bazatã pe un incident real din August 2001, pe lista linux-kernel (lkml). Eu (Eric) eram cel ce punea întrebarea. Mi se tot bloca o maºinã cu placa de bazã Tyan S2462. Membrii listei mi-au furnizat informaþiile cheie de care aveam nevoie.

Punând întrebarea aºa cum am fãcut-o, le-am dat cititorilor ceva de care sã se agaþe; le-a fost uºor sã se implice. Am arãtat respect pentru colegii mei ºi i-am invitat sã mã trateze ca egal. Am arãtat respect pentru timpul lor, arãtându-le ce-am eliminat deja ca posibile cauze.

Ulterior, când am mulþumit tuturor ºi am remarcat cât de eficient am cooperat, un membru lkml a fãcut observaþia cã asta nu s-a întâmplat pentru cã eram un nume pe acea listã, ci pentru cã am formulat întrebarea corect; sunt sigur cã avea drepate.

Hackerii sunt o meritocraþie fãrã milã; sunt sigur cã avea dreptate ºi dacã aº fi fost un "burete", aº fi fost ignorat sau flambat indiferent cine eram. Sugestia lui de a scrie despre acest incident pentru a îi educa pe alþii a dus la apariþia acestui ghid.

[editeazã]Dacã nu vi se rãspunde
Dacã nu primiþi nici un rãspuns, nu o luaþi personal, în sensul cã nu vrem sã vã ajutãm. Uneori chiar nu ºtie nimeni rãspunsul. A nu primi un rãspuns nu înseamnã cã aþi fost ignorat, deºi e greu sã vedeþi asta din exterior.

În general, sã retrimiteþi aceeaºi întrebare e o idee proastã. E inutil ºi deci deranjant.

Încercaþi sã gãsiþi ajutor în altã parte, în locuri mai potrivite nevoilor începãtorilor.

Existã multe grupuri locale sau online de utilizatori care sunt entuziaºti, fãrã a fi scris vreodatã software. Aceste grupuri se formeazã pentru ca membrii sã se poatã ajuta între ei sau pentru a-i ajuta pe începãtori.

De asemenea, sunt multe companii, mai mari sau mai mici, pe care le puteþi contracta pentru asistenþã tehnicã (Red Hat ºi Linuxcare sunt printre cele mai cunoscute; sunt multe altele). Nu fiþi oripilat de ideea de a plãti pentru asistenþã! În definitiv, dacã maºinii dvs i s-ar arde garnitura de chiulasã, aþi duce-o la un mecanic ºi aþi plãti reparaþia. Chiar dacã software-ul nu v-a costat nimic, nu vã puteþi aºtepta ca support-ul sã fie întotdeauna gratuit.

Pentru software foarte rãspândit, cum e Linux-ul, sunt cel puþin 10.000 utilizatori la fiecare dezvoltator. E imposibil ca o singurã persoanã sã asigure support la peste 10.000 utilizatori. Þineþi cont cã deºi plãtiþi pentru support, tot plãtiþi mult mai puþin decât dacã ar fi trebuit sã cumpãraþi si software-ul (în plus, support-ul pentru software-ul comercial este mai scump ºi de calitate mai proastã decât support-ul pentru software open-source).

[editeazã]Cum sã rãspundeþi la întrebãri
Fiþi îngãduitor. Stress-ul cauzat de probleme îi poate face pe oameni sã parã obraznici sau proºti, chiar când nu sunt.

Comentaþi o greºealã off-line. Nu e necesarã umilirea publicã din cauza unei simple greºeli. Un începãtor cu adevãrat s-ar putea sã nu ºtie cum sã caute în arhive, sau unde este postat un FAQ.

Dacã nu sunteþi siguri de un lucru, spuneþi aºa! Un rãspuns greºit care sunã competent e mai rãu decât nici un rãspuns. Nu daþi indicaþii greºite doar pentru cã e distractiv sã pari expert. Fiþi onest ºi sincer; daþi un bun exemplu atât pentru cel care întreabã cât ºi pentru ceilalþi.

Dacã nu puteþi ajuta, nu încurcaþi. Nu faceþi glume despre proceduri care ar putea strica sistemul utilizatorului, pot fi interpretate ca indicaþii.

Puneþi întrebãri de control pentru a extrage mai multe detalii. Dacã sunteþi bun la asta, cel care a întrebat poate afla lucruri noi, ºi de ce nu, chiar dvs. Încercaþi sã transformaþi o întrebare greºitã într-una bunã.

Deºi un simplu "RTFM" este justificat când rãspundeþi unui leneº, direcþii cãtre documentaþie (chiar în forma unor cuvinte cheie de folosit pe Google) sunt ºi mai bune.

Dacã rãspundeþi, rãspundeþi cu ceva util. Nu sugeraþi soluþii greoaie când de fapt cel care întreabã foloseºte metoda sau uneltele greºite. Sugeraþi uneltele potrivite. Reformulaþi întrebarea.

Ajutaþi comunitatea sã înveþe din întrebare Când daþi de o întrebare bunã, întrebaþi-vã cum poate fi îmbunãtãþitã documentaþia ca sã nu mai fie pusã aceeaºi întrebare în viitor. Trimiteþi apoi un patch celui care întreþine documentaþia.

Dacã a trebuit sã vã documentaþi pentru a rãspunde, arãtaþi cum aþi fãcut, nu faceþi sã parã cã aþi scos rãspunsul din burtã. A rãspunde unei întrebãri e ca ºi cum i-aþi da unui om o pâine, a-i arãta cum sã caute singur e ca ºi cum i-aþi arãta cum se obþine pâinea.

[editeazã]Alte resurse
Dacã aveþi nevoie de informaþii de bazã, despre cum funcþioneazã calculatoarele, Internet-ul, Unix-ul, vedeþi The Unix and Internet Fundamentals HOWTO.

Când publicaþi software sau patch-uri pentru software, urmãriþi instrucþiunile din Software Release Practice HOWTO.

[editeazã]Mulþumiri
Evelyn Mitchell a contribuit cu exemple de întrebãri greºite ºi a inspirat secþiunea "Cum sã rãspundeþi la întrebãri". Mikhail Ramendik a contribuit cu sugestii valoroase.