Cum se pun întrebări în mod inteligent

De la Wiki.lug.ro
Salt la: navigare, căutare

autori, link la documentul original, data traducerii...

Introducere

În lumea 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 propune 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 folosirea open-source s-a răspândit pe scară largă, puteţi obţine 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 toleranţi cu greşelile începătorilor. Totuşi, tratându-i şi pe aceştia ca pe hackeri cum e descris 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ă intelectul. 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, „Buna intrebare!“ e un compliment.

In 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.

Suntem de fapt ostili cu acele persoane care parcă nu vor să gândească şi nu-şi fac temele înainte 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-adeva'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ă lumea 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, gândire, 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ă cu inteligentă, încredere şi cunoştinţe, care se întâmplă să aibe nevoie de ajutor cu o problemă punctuală.

Î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 pierde 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 vor î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 pune „Am cautat pe google dupa cuvintele următoare dar nu am găsit nimic folositor“ la inceputul 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ă raspundă literal, în speranţa că veţi învăţa ceva primind exact ce-aţi cerut în loc de ce aveaţi nevoie.

Niciodată sa nu consideraţi că aveti dreptul la un răspuns. Nu-l aveţi; în definitiv, nu plătiţi pentru un 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 sa ma îndrume cineva?“, „Ce lipseşte din exemplul meu?“ şi „Pe ce site ar mai trebui să mă uit?“ au şanse mult mai mari să primească un răspuns, decât „Vă rog să-mi spuneţi exact cum să fac.“ pentru că arată că aveţi doar nevoie de o mică îndrumare în direcţia corectă.

Când întrebaţi

Atenţie unde întrebaţi

Folosiţi-vă discernământul în alegerea locului unde puneţi întrebarea. E foarte probabil să fiţi ignorat sau catalogat ca loser, dacă:

  • postaţi întrebarea pe un forum unde este offtopic
  • postaţi o întrebarea elementară pe un forum unde se aşteaptă probleme tehnice complexe, sau invers
  • postaţi pe mai multe 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 locul greşit pentru a-şi proteja canalele de comunicaţie de zgomot inutil. Nu doriţi să se intâmple asta.

Primul pas, deci, este găsirea unui forum propice. 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 persoana 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.

Cand 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 on-topic. Citiţi arhivele î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 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, bibliotecă sau unealtă portabilă pe ambele 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 cu plăcere unei întrebări care poate ajută mai multă lume, decât în folosul câtorva.

De înţeles, hackerii talentaţi sau autorii de programe foarte populare primesc deja 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 si-au incetat participarea, datorită numărului prea mare de mesaje inutile venite pe adresa de mail personală.

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. Acestea 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ă întrebăti pe liste/forumuri ale distribuţiei respective înainte să încercaţi pe cele ale proiectului respectiv. 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 folosit 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ă acestea când aveţi nevoie de ajutor legat de un proiect.

Pasul doi, listele de email ale proiectului

Când un proiect are o lista de email, scrieţi pe aceasta, nu direct către programatorii implicaţi, chiar dacă vi se pare că ştiţi exact 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 din 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ă se distribuie mai bine munca pentru programatori. Un programator individual (în special daca 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 poate 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 si 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 e probabil că va fi tratată ca zgomot.

Bineinţeles, dacă sunteţi sigur că întrebarea e ne-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 orice listă privată).

Dacă nu găsiţi o listă de mail pentru un proiect şi aveţ 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).

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 - deviatie“. „Obiect“ desemneaza acel lucru care are o problema, iar „deviatie“ descrie deviaţia 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 întamplă doar cu chipset-ul Fooware? Doar cu modelul MV1005? Un hacker care vede un astfel de subiect poate întelege imediat cu ce 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 simplu nu vor vedea mesajul dvs.

Schimbarea liniei de subiect nu este suficientă. Mutt, probabil şi alte programe, se uită la alte informaţii din headerul 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 permit linii diferite 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 extrem de sigur că vreţi un răspuns doar de la cei activi în thread, porniţi unul nou.

Nu îngreunaţi răspunsul

Dacă încheiaţi mesajul cu „Vă rog să răspundeţi pe adresa...“, e mai 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 să ne gândim 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 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ă în trimită astfel; această facilitate este foarte răspândită, o puteţi găsi sub numele „watch this thread“, „send email on answers“ etc).

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, nici noi nu suntem dispuşi să vă acordăm atenţie. Periaţ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 cu puţin mai 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 sesizabila). 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ă micşoraţi şansele ca întrebarea dvs. să nu fie citită.

Folosiţi un format 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 setul 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-doua smiley-uri sunt OK, dar colorarea cât mai variată a textului e neserioasă. Abuzul de smiley-uri, culori şi fonturi vă descriu ca fetiţă, o idee nu foarte 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 asemenea) fiţi atent că 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.


Fiţi precis şi informativ asupra problemei

  • descrieţi clar simptomele problemei sau bug-ului
  • descrieţi mediul în care apar (arhitectură, sistem de operare, aplicaţie, etc). Furnizaţ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 <a href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How to Report Bugs Effectively</a> pe care vi-l recomand cu căldură.

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 sa-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 unui răspuns. Doi: simplificarea întrebării face mai probabil un răspuns folositor. Trei: rafinând formularea problemei e posibil să găsiţi singur o rezolvare sau metodă de evitare a problemei.


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 foarte 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 sunteti foarte 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 aceeasi situaţie în caz că v-aţi înşelat.


Umilinţa nu înlocuieşte munca

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 în mod special enervantă când este însoţită de o descriere prea vagă a problemei.

Nu pierdeţi timpul (dvs si al nostru) cu astfel de tentative de manipulare. Prezentaţi contextul şi întrebarea pe 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 în e locul, dar nu exageraţi cu servilismul nici acolo.

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ă, i-aţi ajuta pe alţii?). 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 incompletă pentru rezolvarea problemei.


Stupid 
Primesc frecvent SIG11 la compilarea kernelului, 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 minute 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 noapte nu. Am schimbat RAM-ul, nu ajută. Aşa arată mesajele de eroare la compilare [...]

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ă aibe o idee la ce să se aştepte.

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 o problemă), începeţi prin a descrie acel lucru. Doar apoi, descrieţi etapa intermediară la care v-aţi blocat.

Adesea cei care au nevoie de ajutor au în minte un obiectiv complex 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ăsi etapa, dar nu realizează 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 văd că s-ar putea face asta e
     să schimb manual fiecare culoare din paletă, dar nu văd 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 o metodă mai potrivită pentru scopul propus.

Nu solicitaţi răspunsuri private

Hackerii consideră că rezolvările problemelor trebuie să fie făcute în public, printr-un proces transparent în care primele tentative de răspuns pot fi corectate de către cei mai experimentaţi, când observă că sunt incomplete sau incorecte. De asemenea, o parte a satisfacţiei personale este construirea unei reputaţii bune în 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, lucru care se întămplă de obicei pentru că întrebarea e prost 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 elegant 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).


Puneţi întrebări concrete

întrebările deschise dezbaterilor tind să fie văzute ca pierdere de vreme. Persoanele 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ţii indicaţii, trimiteţi cod, doriţi validarea unui patch, etc). însi 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.

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ă e de această factură, dar totuşi nu aveţi un răspuns, puteţi incerca 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.

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ă ma 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. <a href="http://homepages.tesco.net/~J.deBoynePollard/FGA/questions-with-yes-or-no-answers.html" target="_top">yes-or-no answer</a>

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ă 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 o şansă.

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ă, de exemplu, dar să postaţi din partea unei mari organizaţii caritabile sau politice aproape sigur nu. Un mesaj de genul "Urgent: ajutaţi-mă să salvez balenele verzi!" vă va face ţinta unui flame chiar din partea 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.