Cum se pun întrebări în mod inteligent
De la Wiki.lug.ro
Traducerea reviziei 3.1 a documentului How To Ask Questions The Smart Way (http://www.catb.org/~esr/faqs/smart-questions.html), de Eric S. Raymond (mailto:esr@thyrsus.com) şi Rick Moen (mailto:rick@linuxmafia.com)
Atenţie
editori: nu operaţi modificări de sens sau de exprimare în acest
articol fără a vă asigura că traducerea rămîne conformă cu originalul în
engleză. Pentru cititori: daca va place sa dati linkul altora,
incercati http://wiki.lug.ro/mediawiki/index.php/ … nteligente , nu contine diacritice care sa fie URL-encoded.
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
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 recomandat 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.
Suntem de fapt ostili faţă de 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-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ă 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, 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ă 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 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 exact 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
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 bună.
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 întrebare 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 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 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 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 cunoscute 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ă.
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ă creează 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 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ă primele când aveţi nevoie de ajutor în
legătură cu un proiect anume.
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
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 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 special 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 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).
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 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
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 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 foarte 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).
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ă.
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-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
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 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.
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 (http://www.chiark.greenend.org.uk/~sgtatham/bugs.html) 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 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 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 sunteţi 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 aceeaşi situaţie în caz
că v-aţi înşelat.
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.
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
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ă aibă 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 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 culoare 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ă.
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 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 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, punctuale
Î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ţ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.
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.
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 (http://homepages.tesco.net/~J.deBoynePo … swers.html)
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 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.
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, pline 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")
Reveniţi cu descrierea soluţiei
După rezolvarea problemei, reveniţi cu un scurt 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 extrem 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.
Cum se interpretează răspunsurile
citeste manualul te rog ş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
"citeste manualul te rog" (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!
citeste manualul te rog 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ţă.
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?"
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 problemelor 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.
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 moduri 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 prost î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).
Î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 (http://www.google.com)?
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 prost încât
situaţia e frecventă.
I: Am un program care nu merge. Cred că biblioteca X e defectă.
R:
Deşi e perfect posibil să fiţi primul care observă o problemă cu
apelurile sistem sau bibliotecile folosite intens 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 probleme 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 prost că ceri unui hacker să te ajute.
Î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.
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).
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 "citeste manualul te rog" 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.
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 (http://en.tldp.org/HOWTO/Unix-and-Inter … als-HOWTO/).
Când publicaţi software sau patch-uri pentru software, urmăriţi instrucţiunile din Software Release Practice HOWTO (http://en.tldp.org/HOWTO/Software-Relea … index.html).
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.
Adus de la "http://www.rlug.ro/mediawiki/index.php/ … inteligent"
Views
* Conţinutul este disponibil sub Licenţa Creative Commons Attribution ShareAlike 2.5.
Niciun comentariu:
Trimiteți un comentariu