Come fare domande in modo intelligente


Indice
Traduzioni
Introduzione
Prima di domandare
Quando si domanda
Come interpretare le risposte
Sul non reagire da sfigato
Domande da non fare
Domande buone e domande cattive
Se nessuno ci risponde
Risorse collegate

Traduzioni

La versione originale del documento è in questa URL; traduzioni di questo documento sono state fatte anche in francese.

Nota bene: alcuni termini in lingua inglese ma largamente compresi, come ad esempio hacker (qui usato nel significato originale, spiegato ad es. in questa URL, e non in quello, purtroppo diffuso tra i non addetti ai lavori, di pirata informatico) e newsgroup sono stati lasciati inalterati nella traduzione; di altri, meno diffusi, si è tentato di dare una traduzione in italiano — come ad esempio per loser, che si è reso con sfigato.


Introduzione

Nel mondo degli hackers, il tipo di repliche che ricevono le nostre domande tecniche dipende non solo dalla difficoltà di arrivare ad una risposta esauriente, ma anche da come si è posta la domanda stessa. Questa guida cerca di spiegare come andrebbero formulate le domande in modo da aumentare la probabilità che esse ricevano una risposta soddisfacente.

La prima cosa da capire è che agli hackers piacciono i problemi difficili, e le domande azzeccate e generatrici di riflessione che li riguardano; se così non fosse, non saremmo qui su Internet. Quando qualcuno ci propone un interrogativo interessante su cui rimuginare gliene siamo grati; in effetti, le domande ben poste sono uno stimolo: e quindi un buon regalo che ci viene fatto. Le belle domande ci aiutano a capire più a fondo un problema, e spesso ce ne rivelano angoli oscuri di cui non ci eravamo accorti e cui non avremmo fatto caso altrimenti. Tra gli hackers, dire "questa è una buona domanda!" equivale a fare un complimento sincero ed importante.

A dispetto di quanto ora detto, però, gli hackers sono ben noti per l'abitudine di rispondere, a quelle che sono in fondo domande semplici, con quella che appare ostilità e arroganza. Ogni tanto sembra che noi si sia studiatamente maleducati verso gli inesperti ed i novizi; ma questo non è del tutto vero.

Si tratta dell'essere, e dichiaratamente, ostili a coloro che si presentano come non disposti né a riflettere né a fare un minimo di lavoro prima di domandare. Persone così sono una perdita di tempo — prendono senza dare, e ci farebbero sprecare minuti che avremmo potuto dedicare a problemi più interessanti o a persone più meritevoli di una risposta. A gente come questa ci riferiremo chiamandoli sfigati.

Noi ci rendiamo conto del fatto che esistono individui che vogliono solamente utilizzare il software, e che non hanno alcun interesse nei dettagli tecnici. Per la maggior parte delle persone un computer è meramente un utensile, quindi un mezzo che consente di raggiungere un fine; hanno cose, nella vita, a cui pensare e da fare assai più importanti di quei dettagli. Lo sappiamo, e non ci aspettiamo che tutti provino interesse per le cose che ci affascinano. Nonostante questo, rispondiamo con stile del tutto diverso a coloro che condividono questo stesso nostro interesse e che si propongono come partecipanti attivi al processo di soluzione dei problemi. E sarà sempre così; se non lo fosse, in fondo faremmo con meno efficienza proprio le cose che sappiamo fare meglio.

Noi siamo, nella grande maggioranza, volontari: dedichiamo qualche minuto della nostra esistenza, oltre al tempo che dobbiamo dare al lavoro ed alla vita privata, per rispondere alle domande altrui; e, ogni tanto, siamo anche sopraffatti da questa occupazione "aggiuntiva". Per questo motivo filtriamo inflessibilmente le domande. In particolare saltiamo a pié pari tutto quello che sembra provenire da un qualche sfigato, per spendere il nostro tempo a vantaggio di chi ci appare come una persona interessata.

Se trovate questo atteggiamento sgradevole, condiscendente o arrogante, pensateci un attimo. Nessuno chiede che gli altri ci si prosternino davanti — in effetti la maggior parte di noi non chiederebbe di meglio che dialogare con tutti quanti da uguale e dar loro il benvenuto nel nostro universo culturale, se solo gli altri ci mettessero un piccolo sforzo per renderlo possibile. Ma, semplicemente, non è remunerativo cercare di aiutare chi mostra di non saper fare lui stesso un piccolo sforzo. Se non riuscite a sopportare questo atteggiamento forse discriminatorio, ebbene, pagate qualcuno per un aiuto prestato nei termini di un contratto commerciale invece di domandare agli hackers di regalarvi quello stesso aiuto per favore.

Se decidete di chiederci qualcosa, cercate di non comportarvi da sfigati; il modo migliore di ottenere risposte rapide e complete è di domandare a modino — domandare da persona furba, consapevole e che conosce la materia, e a cui solamente capita di aver bisogno di aiuto per un problema particolare.

(Suggerimenti per migliorare questa guida sono i benvenuti. Mandateli a Eric S. Raymond, esr@thyrsus.com; considerate però che questo documento non vuole essere una guida generale alla netiquette, e che per questo non verranno considerati suggerimenti che non riguardino il come ottenere risposte utili da un'audience tecnica).


Prima di domandare

Prima di presentare una domanda tecnica per email o in un newsgroup o su una chat qualificata, dovete:

  1. Cercare di trovare una risposta su un manuale
  2. Cercare di trovare una risposta leggendo una FAQ
  3. Cercare di trovare una risposta usando un motore di ricerca
  4. Cercare di trovare una risposta chiedendo a un amico

Quando formulate la domanda, fate presente che prima avete fatto tutto questo; questo ci aiuta a capire che non siete un pigrone o uno scroccone, e che non volete far sprecare tempo alla gente. Meglio ancora, fate capire quello che avete imparato tentando tutto questo; a noi piace rispondere a chi dimostra di aver imparato qualcosa da risposte ricevute in precedenza.

Pensate alla vostra domanda, e preparatela bene. Domande fatte in tono irascibile ricevono risposte irascibili, o nessuna risposta del tutto. Più mostrerete di aver pensato e di esservi sforzati per trovare una soluzione al vostro problema prima di aver chiesto aiuto, più sarà probabile che riceviate quell'aiuto.

Attenzione a non fare domande formulandole in modo poco corretto. Se chiedete qualcosa non correttamente, l'hacker tipico (mentre pensa "Ma che domanda stupida") in genere replica con una risposta alla lettera della domanda e per questo volutamente inutile; sperando che l'aver ricevuto la risposta a quello che avete letteralmente chiesto piuttosto che a quello di cui avevate bisogno vi insegni una lezione.

Non assumete mai di avere diritto ad una risposta. Non l'avete; non state mica pagando un servizio. Noi vi dobbiamo una risposta, se ve la dobbiamo, per l'aver posto una domanda interessante, ricca di sostanza ed intellettualmente stimolante — una domanda che implicitamente dia un contributo alla comunità invece di richiedere passivamente conoscenza dagli altri.

Inversamente, il sottolineare che siete capace e volete contribuire al processo dello sviluppo di una soluzione è un buon punto di partenza. "Potete darmi uno spunto?", "Cosa non fa bene nel mio esempio?", "C'è un sito dove potrei guardare?" sono domande che ricevono risposta più prontamente di "Per favore, spiegatemi passo passo cosa devo fare."; perchè chiarite che siete pronti ad arrivare da soli alla soluzione, se soltanto qualcuno vi da il giusto punto di partenza.


Quando si domanda

Scegliete con cura a chi domandare

Siate giudiziosi nello scegliere in che sede proporre la vostra domanda; probabilmente sarete ignorati, o comunque catalogati come sfigati, se:

  • la inviate ad un newsgroup dove è off-topic (fuori tema);
  • la domanda è elementare ma la inviate ad un newsgroup dove si discutono argomenti tecnici avanzati (o viceversa);
  • la domanda è cross-posted (inviata contemporaneamente) a molti newsgroups differenti.
(ovviamente quanto detto per un newsgroup vale anche in un contesto diverso, ad esempio una chat o una mailing list).

Gli hackers ignorano domande fatte in una sede inopportuna, e questo per cercare di impedire che i loro canali di comunicazione siano sepolti sotto una massa abnorme di comunicazioni irrilevanti. Voi non volete che questo accada anche a voi.

In generale, le domande rivolte ad un ambiente pubblico ricevono più risposte utili di quelle rivolte ad un destinatario privato — e ci sono svariate ragioni per questo: la prima è semplicemente il maggior numero di potenziali lettori della domanda; un'altra è il maggior numero di potenziali lettori della risposta, visto che gli hackers esperti in un certo campo preferiscono frequentare un contesto dove le loro conoscenze possono interessare un maggior numero di persone (e stimolare una discussione più lunga ed approfondita).


Ogni volta che è possibile, usate una mailing list

Se un progetto software ha una mailing list, usatela: scrivete alla lista e non ad un particolare sviluppatore — anche se pensate di sapere chi sia colui che può rispondere nel migliore dei modi possibili alla vostra domanda. Controllate la documentazione o la home page del progetto, guardate se viene citata una mailing list, e, se si, usatela. Ci sono diverse buone ragioni per questo:

  • Ogni domanda che può essere interessante per un particolare sviluppatore lo è anche per l'intero gruppo. O, al contrario, se pensate che la vostra domanda sia troppo terra-terra per la mailing list, a maggior ragione lo sarà per la singola persona.
  • Le domande inviate alla lista non aggravano il carico di lavoro individuale di una singola persona che (specialmente se è uno dei leaders del progetto) può essere troppo occupato per dedicarvi il suo tempo.
  • Quasi tutte le mailing lists sono archiviate, e gli archivi sono sia accessibili dal Web che schedati dai motori di ricerca. Qualcuno potrà in futuro vedere la vostra domanda sul Web con la relativa risposta, e beneficiarne senza essere costretto a chiedere a sua volta la stessa cosa.
  • Se certe domande si presentano troppo spesso, gli sviluppatori possono utilizzare questa informazione per migliorare o la documentazione o il software; nel caso le domande venissero poste privatamente, mancherebbe una visuale globale dei problemi che gli utilizzatori del software si trovano ad affrontare.

Se riuscite a trovare solo l'indirizzo del responsabile del progetto software ma non quello di una mailing list, scrivete al responsabile; ma non assumete che una mailing list non esista. Dite esplicitamente che non l'avete trovata, e che non avete obiezioni a che la vostra email venga forwardata ad altre persone (la maggioranza, su Internet, pensa che le email private debbano rimanere tali, anche se non vi è nulla di personale in esse; permettendo al vostro messaggio di essere girato ad altre persone, date al vostro corrispondente una maggior libertà di scelta su come trattare il vostro problema).


Scrivete chiaramente, correttamente e senza errori

L'esperienza suggerisce che chi scrive senza cura o sciattamente è anche trascurato e sciatto nel pensare e nello scrivere codice (o almeno lo è molto di frequente, potete scommetterci). E rispondere alle domande di persone sciatte e trascurate non è gratificante; l'hacker preferisce dedicare il suo tempo ad altri.

Ne consegue che esprimersi chiaramente e con precisione è importante; se voi non volete spendere un po' di tempo per rifinire il messaggio, non potete pretendere che altri spendano tempo per rispondere. Sacrificate qualche minuto per controllare il testo; non importa che sia eccessivamente formale — in effetti la cultura degli hacker apprezza un linguaggio informale e popolaresco, purchè spiritoso ed usato con precisione e senza strafare. Ma deve essere preciso e puntuale: questo vuol dire che state pensando e che siete vispi.

Controllate ortografia, punteggiatura e maiuscole. Non confondete fischi con fiaschi. Non scrivete mai IN TUTTE MAIUSCOLE, questo viene percepito come urlare e considerato maleducato. (Scrivere in tutte minuscole è un poco meno fastidioso, ma comunque difficile da leggere — e per questo ancora considerato maleducazione).

Riassumendo, se scriverete come un babbuino illetterato verrete probabilmente ignorati. Se scriverete in gergo (abbreviazioni spinte, k al posto del ch, e così via) vi farete ridere dietro (almeno in certi ambienti) e, piuttosto che silenzio totale, riceverete sarcasmo e mal celato disprezzo. Considerate che in questo testo viene usato perfino il congiuntivo — imitatemi!

Se la domanda è in una lingua che non è la vostra, avete a disposizione un poco di tolleranza in più; ma per il linguaggio, non per la trascuratezza (e, si, in genere gli hackers sanno cogliere la differenza). A meno che non sappiate con precisione quale sia la lingua usata dai vostri corrispondenti, servitevi dell'inglese; la gente impegnata non perde tempo a decifrare domande che non capisce bene, e l'inglese è la lingua franca di Internet. Scrivendo in inglese renderete minima la possibilità che tutti scartino a pié pari la vostra domanda senza leggerla.


Mandate le domande in un formato facilmente decifrabile

Se, magari senza rendervene conto, inviate le domande in modo che queste risultino difficili da leggere, è più facile che vengano trascurate da chi le riceve. Così:

  • Postate in puro testo, non in HTML (non è difficile disabilitare l'HTML).
  • Attachments MIME in genere sono accettati, ma solo se hanno un contenuto reale (come un file sorgente o un patch acclusi ad un messaggio di spiegazione) e non sono invece spazzatura generata dal vostro mailer (come una seconda copia del vostro messaggio).
  • Non spedite messaggi in cui ogni paragrafo è composto da una singola linea di testo senza a-capo: questo rende difficile rispondere a solo una parte del messaggio stesso. Assumete che chi legge utilizzi un display capace di linee lunghe non più di 80 caratteri, e programmate il vostro mailer per una lunghezza delle linee di testo un poco inferiore.
  • Comunque, non spezzate mai linee lunghe di dati (come log files, core dumps o trascrizioni di un'intera sessione di lavoro). I dati devono essere inclusi esattamente come sono, anche per rassicurare il corrispondente che nulla è andato perso nella formattazione.
  • Non mandate mai testo MIME Quoted-Printable ad un newsgroup, specialmente se in lingua inglese; questo encoding può essere necessario per un linguaggio non rappresentabile in puro ASCII (ossia per un linguaggio con lettere accentate), ma moltissimi mailers non lo accettano. Quando ricevono un messaggio di questo tipo, lo mostrano infarcito di codici =20 disseminati nel testo — che sono brutti a vedere ed un'ostacolo ad una rapida lettura.
  • Mai, mai, MAI presupporre che un hacker debba essere in grado di leggere un attachment in un formato proprietario come, ad esempio, Microsoft Word. L'hacker tipico reagisce a questo come ad un vero e proprio affronto, e si comporta esattamente come farebbe se qualcuno avesse nottetempo scaricato un camion di letame fumante sulla sua soglia di casa.
  • Se inviate il messaggio da una macchina Windows, disabilitate le "Smart Quotes" Microsoft; il cui scopo principale è quello di disseminare caratteri-spazzatura nel testo quando il messaggio è letto su una macchina non-Windows.
  • Se usate un mailer dotato di interfaccia grafica (come Netscape Messenger, Microsoft Outlook o simili), attenzione: può contravvenire silenziosamente a queste regole, se viene usato con le opzioni impostate di default. La maggior parte di questi programmi ha un comando a menu tipo "View Source"; usatelo, per controllare che state realmente mandando a spasso per il mondo puro testo — senza nessun'altra aggiunta non voluta.

Specificate dei "Subject:" che siano esplicativi

L'header "Subject:", nelle mailing lists o nei newsgroups, è un'occasione d'oro per attirare l'attenzione degli esperti qualificati a risolvere il vostro problema; il tutto però in non più di 50 caratteri. Non sprecate quest'occasione con balbettii tipo "Per favore aiutatemi" (o, peggio, "PER FAVORE AIUTATEMI!!!!" — messaggi con questo soggetto vengono scartati quasi automaticamente). Non cercate di fare impressione con la profondità della vostra sofferenza, ma usate lo spazio a disposizione per una descrizione, molto concisa ma precisa, del vostro problema.

Un buon metodo per scrivere i soggetti, usato da molte organizzazioni di supporto tecnico, è la convenzione "oggetto - malfunzionamento": la prima parte (oggetto) dice con che cosa avete dei problemi; e la seconda (malfunzionamento) descrive il comportamento anomalo che non vi aspettavate.

Sfigato:
AIUTO! Il video del mio laptop non funziona!
Furbo:
Il cursore del mouse vien fuori male sotto XFree86 4.1 con la scheda video Fooware MV1005
Ancora meglio:
XFree86 4.1, scheda Fooware MV1005 - cursore del mouse errato

Se descrivete il problema secondo lo schema "oggetto - malfunzionamento", questo aiuta anche ad analizzare il problema in maggiore dettaglio. Cosa non si comporta secondo le vostre aspettative? Solo il cursore del mouse, o qualcosa d'altro? Succede solo con XFree86? E solo con la release 4.1? È specifico di tutte le schede video Fooware? O del modello MV1005? Un hacker che legge il soggetto ha già un'idea approssimata del sistema che si comporta male, ed anche del tipo di problema — e questo alla prima occhiata.

Se chiedete qualcosa di nuovo in una risposta che fa parte di un vecchio thread, cambiate il soggetto per indicarlo chiaramente. Una "Subject line" come "Re: test" o "Re: new bug" difficilmente attrae qualcuno; e, inoltre, quotate dal vecchio thread solo il minimo che è necessario per introdurre il nuovo argomento.


Siate precisi ed esaurienti sul vostro problema

  • Descrivete i sintomi del vostro problema con cura e chiarezza.
  • Dite in che ambiente si presentano (hardware, sistema operativo, applicazione, versione di sistema ed applicazione; e così via).
  • Parlate di quello che avete fatto per capire e risolvere il problema, prima di chiedere aiuto.
  • Descrivete tutto quello che è cambiato recentemente nella vostra configurazione (hardware e software), e che potrebbe essere collegato al problema.

Cercate, per quanto possibile, di anticipare le domande che un hacker esperto potrebbe farvi; e anche di dare le relative risposte.

Simon Tatham ha scritto un buon saggio dal titolo How to Report Bugs Effectively, del quale è fortemente consigliata la lettura.


La quantità non è qualità

Dovete essere precisi ed informativi. Per riuscirci non basta semplicemente accludere quantità immani di codice o di dati assieme ad una richiesta di aiuto; se avete un programma complicato e lungo che produce errori, cercate di eliminare qualcosa in modo da renderlo tanto piccolo quanto possibile.

Questo è utile per diverse ragioni: la prima è che dimostrare di esservi sforzati per semplificare il problema aumenta la probabilità di una risposta; poi, l'aver circoscritto le cause del problema aumenta la probabilità di trovare una soluzione utile; infine, nel processo di capire esattamente da cosa derivi l'errore, non è detto che non troviate l'errore stesso (o, quanto meno, una maniera di evitarne gli effetti) da soli.


Descrivete i sintomi, non quello che ne pensate

Non serve a nulla dire agli hackers cosa, secondo voi, causa il vostro problema — in fin dei conti, se le vostre teorie fossero così azzeccate, perchè vi rivolgereste ad altri per essere aiutati? Quindi, assicuratevi di dire esattamente cosa non quadra, senza aggiungere interpretazioni e diagnosi.

Sfigato:
Mi arrivano in continuazione errori di tipo SIG11 compilando il kernel. Per me c'è un'interruzione, da qualche parte, nelle tracce dello stampato della motherboard; qual è il modo migliore per capire dove?
Furbo:
Ho un computer K6/233 fatto in casa a partire da una motherboard FIC-PA2007 (con chipset VIA Apollo VP2 e 256 MB di SDRAM Corsair PC133); mi arrivano continui errori di tipo SIG11, dopo una ventina di minuti dal bootstrap, compilando il kernel — ma i primi 20 minuti tutto è normale. Un reboot immediato non cura il problema, ma lasciando il computer spento tutta la notte tutto torna tranquillo. Togliendo uno dopo l'altro i banchi di RAM non cambia nulla. Accludo la trascrizione della sessione, con i comandi che cerco di eseguire ed i diagnostici.

Descrivete i sintomi nell'ordine in cui si presentano

Gli indizi più utili per capire cosa non va spesso sono legati agli eventi immediatamente precedenti il disastro. Quindi il vostro report dovrebbe descrivere con esattezza cosa avete fatto, voi e la macchina, fino al manifestarsi del problema; nel caso di sessioni guidate da comandi interattivi, un log dell'intera sessione o la descrizione degli ultimi comandi (una ventina al massimo) possono essere utilissimi.

Se l'applicativo che da errore ha opzioni diagnostiche (come un -v per ottenere output più dettagliato), pensate un poco a quali di queste opzioni potrebbe aggiungere informazioni utili al vostro contesto.

Se la descrizione diventa troppo lunga (diciamo più di quattro paragrafi), potrebbe essere utile riassumere brevemente il problema all'inizio; per poi proseguire passo passo con la cronologia di quanto è successo. In questo modo un hacker esperto già capisce cosa andare a cercare più avanti nel vostro messaggio.


Non chiedete mai risposte private

Gli hackers hanno la convinzione che il "problem solving" debba essere un processo pubblico e trasparente, durante il quale una prima risposta può (e deve) essere migliorata se qualcuno più esperto si accorge che essa è sbagliata o incompleta. Inoltre una risposta pubblica potrebbe essere utile ad altre persone; e, infine, gli hackers ricevono una sorta di ricompensa alla fatica di risolvere un problema — e la ricompensa viene dall'essere considerati competenti ed intelligenti dai loro "colleghi".

Chiedendo una risposta privata, si interferisce in questo processo; la risposta tipica è: "Se cerchi un servizio personalizzato, pagati un consulente". Se mai è chi risponde che può decidere di farlo in modo privato — e, se questo accade, di solito è perchè pensa che la domanda sia posta in modo sbagliato o che sia troppo banale: e quindi non interessante per gli altri.

C'è però una eccezione a questa regola: se pensate che la vostra domanda produrrà una valanga di risposte più o meno uguali (esempio: "Chi si propone per tradurre un capitolo di Thinking in C++ in italiano, e quale?"), la formula magica è: "rispondete per email, ed in un successivo messaggio riassumerò le risposte per voi". È infatti percepito come gentilezza il cercare di non far saturare una mailing list o un newsgroup da una gran mole di interventi sostanzialmente simili — ma dovete mantenere la promessa fatta, ed inviare il successivo sommario.


Siate espliciti nel fare una richiesta

Se esponete un problema ma non formulate una richiesta chiara, il vostro messaggio sarà percepito come una possibile trappola da evitare a tutti i costi. Coloro che hanno sia l'esperienza che l'abilità necessarie per aiutarvi sono probabilmente le persone più occupate tra quelle che vi leggeranno: e gente come loro è allergica allo spreco di tempo, per cui eviterà di imbarcarsi in un lavoro che non sanno chiaramente inquadrare.

È molto più facile ottenere una risposta utile se si è espliciti nel dire cosa si vuole che i nostri interlocutori facciano (dare indicazioni, scrivere codice, controllare un patch o qualsiasi altra cosa). Questo infatti focalizza il loro sforzo; e, soprattutto, implicitamente fissa un limite superiore allo sforzo ed al tempo che deve essere speso per aiutarvi: è, insomma, una Buona Cosa.

Per capire il mondo degli hackers, pensate alla competenza come ad una risorsa abbondante; ed al tempo come ad una risorsa rara e preziosa. Meno tempo durerà fare quello che chiedete, più sarà probabile che una persona molto capace, ma molto impegnata, sia invogliata a rispondere.

Così, in ultima analisi, è opportuno inquadrare la richiesta in modo da minimizzare l'impegno richiesto — e questo abbastanza spesso equivale a stare attenti a cosa domandare. Per esempio, "Dove posso trovare una spiegazione dell'uso dei puntatori in C" è una domanda più furba da fare piuttosto che "Spiegatemi l'uso dei puntatori in C"; e, se avete un programmino che non funziona, è più furbo chiedere di indicare cosa è sbagliato che domandare di postare un programma che funzioni.


Non chiedete di farvi i compiti

Gli hackers sono bravissimi nel capire che una certa domanda è in realtà l'esercizio di un compito a casa; e parecchi di loro hanno svolto dei compiti simili in passato (e magari ora li danno da svolgere ai loro studenti). A quelle domande dovete rispondere voi: vi sono state fatte perchè il risolvere l'esercizio vi insegnerà qualcosa. Va benissimo chiedere uno spunto, od esporre quanto avete già fatto e chiedere un giudizio; non va bene chiedere l'intera soluzione.


Eliminate le richieste insensate

Resistete alla tentazione di concludere con domande semanticamente insignificanti come "Qualcuno mi può aiutare?" o "Qual è la risposta?". Primo: se il problema è descritto in modo mediamente buono, una conclusione di quel genere è chiaramente superflua; secondo: gli hackers odiano le cose superflue — ed è possibilissimo che riceviate delle risposte dalla logica impeccabile, ma altrettanto superflue — tipo "Si, io potrei aiutarti".


Non sottolineate che la vostra domanda è urgente, nemmeno se per voi lo è davvero

Quelli sono affari tuoi, non nostri. Chiedere un aiuto urgente è controproducente: la maggior parte degli hackers semplicemente salta il messaggio, considerando maleducato il tentativo di ottenere un'attenzione speciale ed immediata nei confronti delle altre richieste.


Essere educati non fa mai male, e talvolta aiuta

Siate gentili; dite "per favore" e "grazie in anticipo". Chiarite che apprezzate il fatto che qualcuno spenda il suo tempo per aiutarvi, e senza chiedere nulla in cambio.

Ad esser sinceri, questo non è importante come l'essere precisi e chiari, l'usare un linguaggio corretto e l'evitare i formati proprietari; in genere gli hackers preferiscono un bug report appropriato ed essenziale ma un po' ruvido ad una educatissima vaghezza (e, se questo vi intriga, ricordate che apprezziamo le domande perchè possono insegnare qualcosa anche a noi).

Comunque, una volta che avete messo le vostre cosine tecniche sull'attenti, allineate e coperte, la buona educazione aumenta abbastanza le speranze di ottenere una risposta utile.

(Notiamo, incidentalmente, che l'unica obiezione che abbiamo ricevuto a questo capitoletto da parte di hackers seri è stata all'uso di "grazie in anticipo"; qualcuno lo interpreta come l'intenzione di non ringraziare nessuno dopo... Il nostro consiglio è di fare entrambe le cose).


Terminate con una breve nota dopo che tutto è stato risolto

Mandate una noticina a tutti quelli che vi hanno aiutato, dopo che il vostro problema è stato risolto; fate loro sapere cosa è successo, e ringraziateli. Se il problema aveva suscitato un certo interesse nella mailing list o nel newsgroup, mandate la nota come followup; altrimenti usate l'email.

Non è necessario che la vostra nota sia lunga e dettagliata; un semplice "Ehilà! Si trattava di una connessione di rete difettosa - grazie a tutti!" può essere sufficiente. Come dato di fatto, un corto sommario è preferibile ad una lunga dissertazione — a meno che la soluzione non avesse inaspettate e profonde implicazioni tecniche. Dite quale dei vari suggerimenti ha risolto il problema, senza scendere nei dettagli di tutta l'operazione di troubleshooting.

Oltre che come un fatto di cortesia, questo genere di conclusione aiuterà altre persone che consulteranno gli archivi della mailing list o del newsgroup in futuro, per sapere esattamente che cosa ha risolto il vostro problema (e che potrebbe risolvere il loro).

Per finire, una nota del genere comunica a tutti quelli che vi hanno aiutato una piacevole sensazione di chiusura del problema. Se non siete un tecnico o un hacker, fidatevi di noi: questa sensazione è assai importante per i guru e gli esperti da cui avete sollecitato (ed ottenuto) aiuto. Threads su problemi effettivi che alla fine terminano nel nulla lasciano invece un senso di frustrazione, una specie di prurito che tormenta ognuno degli hackers che hanno suggerito qualcosa. Il karma positivo che vi procurerà l'aver posto fine a questi pruriti vi sarà molto, molto utile la prossima volta che avrete la necessità di fare una domanda.


Come interpretare le risposte

RTFM e STFW: quando vi dicono che avete seriamente rotto

Questa è un'antica e santa tradizione: se in una risposta leggete "RTFM", vuol dire che chi ve la manda pensa che avreste dovuto leggervi un fottutissimo manuale (RTFM = Read The Fucking Manual). Ed in genere ha ragione. Andatevelo a leggere.

RTFM ha come fratello minore un'altro, più recente, acronimo: se nella risposta leggete "STFW", colui che ve la manda pensa che avreste fatto prima e meglio a consultare un fottutissimo motore di ricerca (STFW = Search The Fucking Web). Ed in genere ha ragione. Andatevelo a consultare.

Spesso, chi vi manda l'una o l'altra di queste risposte ha già sotto il naso il manuale (o la pagina Web) con l'informazione che vi serve — e le sta guardando intanto che usa la sua tastiera. Le risposte vogliono semplicemente dire che lui pensa che l'informazione richiesta sarebbe stata facilissima da trovare se aveste avuto un minimo di buona volontà o di iniziativa; e che imparerete comunque di più tentando di trovarla da soli piuttosto che trovandovela sotto il naso su un piatto d'argento.

RTFM può anche voler dire che la vostra domanda rivela un'ignoranza abissale delle tematiche che proponete; non potete chiedere un consiglio su un programma e nel contempo mostrare di non conoscere nemmeno le basi del linguaggio che state adoperando. Studiatevelo, e riprovate dopo.

Non sentitevi offesi; secondo lo standard degli hackers vi è stata dimostrata una certa rude considerazione semplicemente non ignorandovi — dovreste invece rispondere ringraziando per la gentilezza usata dalla buona nonnina (l'hacker) verso il nipotino sfigato (voi :-)


Se non capite...

Se non riuscite a capire la risposta, non saltatevene immediatamente fuori con una richiesta di spiegazioni: cercate invece di usare gli stessi metodi che avete usato per cercare di risolvere il vostro problema prima di chiedere (manuali, FAQ, il Web, gli amici esperti); questa volta, però, per cercare di capire la risposta. Dopo, se avrete ancora dei dubbi, potrete chiederne il chiarimento; ma, nello stesso tempo, farete capire che qualcosa avete appreso.

Per esempio, supponiamo che la risposta dica "Sembra che tu abbia una supercazzola bloccata; devi sbloccarla". E poi? Un cattivo followup consiste nel domandare "Cos'è una supercazzola?"; un buon followup potrebbe contenere (dopo essersi documentati): "Va bene; ma, nella man page, di supercazzole si parla solo in relazione alle command options -z e -p. Purtroppo, sotto nessuna delle due si chiarisce come si sblocca una supercazzola. Mi sono perso qualcosa, o puoi essere più chiaro?"


Come ci si comporta con i maleducati

La maggioranza di quello che ad un neofita sembra maleducazione, nell'ambiente degli hackers non è pensato come linguaggio potenzialmente offensivo. Piuttosto, si tratta dello stile di comunicazione diretta e senza abbellimenti né fronzoli tipica di persone cui interessa risolvere problemi — non far sentire gli altri coccolati ed a loro agio.

Se percepite maleducazione in una risposta, cercate comunque di reagire con calma. Se il vostro interlocutore per davvero è uscito fuori dai gangheri a torto, probabilmente qualcuno dei vecchi e rispettati frequentatori abituali della lista lo rimprovererà. Se questo non accade, assai probabilmente (nonostante quello che sembra a voi) chi vi ha risposto è rimasto entro i limiti delle norme della comunità; e se voi aveste già risposto perdendo la calma, sareste voi ad essere considerato uno sfigato — e questo peggiorerebbe le vostre probabilità di ottenere aiuto.

D'altra parte, di tanto in tanto succede di inciampare veramente nella maleducazione, o comunque in atteggiamenti rudi abbastanza gratuiti. L'altro lato della medaglia consiste nel fatto che, in questi casi, è consentito prendere a ceffoni (verbali) chi vi ha offeso, anche andandoci pesante, e dissezionando il suo cattivo comportamento col bisturi della vostra lingua tagliente. Però pensateci due volte; siate molto, molto sicuri di essere nel giusto; ed usate solo l'ironia e mai la volgarità. Il confine tra reagire ad un comportamento scorretto e l'iniziare una guerra verbale di insulti priva di scopo è così sottile che gli hackers stessi ogni tanto si trovano dalla parte sbagliata; se siete un novellino, le probabilità per voi di rimanere sempre dalla parte giusta sono scarse. Se quello che vi interessa sono le informazioni e non lo spettacolo, è meglio tenere le dita lontano dalla tastiera.

(C'è chi sostiene che parecchi hackers soffrano di una blanda forma di autismo, o "sindrome di Asperger", e che abbiano dei difetti in quelle connessioni cerebrali che sono preposte alle "normali" relazioni interpersonali. Questo può essere vero, o falso; ma, se voi non siete hackers, potrebbe aiutarvi a sopportare le nostre eccentricità pensare che siamo tutti un po' tocchi. Avanti, fatelo. A noi non interessa; a noi piace essere come siamo, e comunque siamo moooolto scettici sia sull'etichettare in blocco un'intera categoria, che sulla psichiatria in generale).

Nel prossimo capitoletto, parleremo di qualcosa di assai differente: il genere di "maleducazione" che vedete quando voi vi comportate impropriamente.


Sul non reagire da sfigato

Le leggi della probabilità garantiscono che, nelle prime uscite verso la comunità degli hackers, ne combinerete qualcuna — o nei modi che abbiamo appena descritto, o in un modo nuovo inventato da voi stessi. In questi casi, vi verrà rinfacciato esattamente quello in cui avete mancato, né più né meno, e generalmente in modo colorito. E pubblicamente.

Quando capita qualcosa di questo genere, la cosa peggiore che potete fare è piagnucolare su quanto vi è capitato, lamentarvi di essere stati assaliti verbalmente, domandare scusa, urlare, trattenere il fiato fino a diventare rossi in faccia, minacciare querele, lamentarvi con i capiufficio di chi vi ha trattato male, non abbassare il coperchio del water dopo averlo usato, e così via. Invece, ecco cosa dovete fare:

Lasciar perdere. È normale. In effetti, è giusto e vi farà anche del bene.

Le regole di una qualsiasi società non si mantengono da sole per vita propria; ma si mantengono perchè c'è una sostanziale parte di quella società che le applica e si cura del fatto che siano rispettate, visibilmente e pubblicamente. Non lamentatevi perchè le critiche non vi sono arrivate in modo riservato, per email: non è così che vanno le cose. Né è utile insistere sul fatto che siete stati insultati personalmente, se qualcuno ha asserito che qualcosa che avete detto è completamente sbagliato (o soltanto che lui la pensa diversamente). Questi sono atteggiamenti da sfigato.

Sono esistiti dei luoghi di incontro di hackers, su Internet, dove (in nome di un malinteso senso di eccessiva cortesia) i partecipanti avevano come regola quella di non dire nulla che si potesse interpretare come un rimprovero o come il rinfacciare un errore a qualcuno; la regola era "rispondi alle domande; e, per il resto, stai zitto". Il risultato è stato l'allontanarsi progressivo di tutti i partecipanti esperti, ed il decadere della lista in balbettii di partecipanti impreparati — fino a divenire inutilizzabile come luogo di consulenza tecnica.

Quindi: o troppo gentile, o utile. Bisogna scegliere.

Ricordatevelo: se un hacker vi dice che vi siete comportati male, non importa affatto il modo (magari ruvidissimo) in cui ve lo dice; sappiate che lo fa a vantaggio sia di voi, che, soprattutto, della sua intera comunità. Sarebbe molto più facile, per lui, ignorarvi; mettervi nel suo kill-file ed escludervi del tutto dalla sua vita. Se non riuscite ad essergli grati, almeno comportatevi con dignità, non piagnucolate, e non aspettatevi di essere trattati come una bamboletta solo perchè siete un nuovo venuto inesperto e dall'animo troppo sensibile per poter sopportare un insuccesso.


Domande da non fare

Questa è una breve rassegna di (ben note) domande stupide; e di quello che pensano gli hackers intanto che non rispondono loro.

Domanda: dove posso trovare il programma X?
Domanda: il mio programma (o la mia configurazione, od il mio comando SQL, o ...) non funziona.
Domanda: ho dei problemi con la mia macchina Windows. Potete aiutarmi?
Domanda: ho problemi nell'installare Linux (o il programma X, o ...). Potete aiutarmi?
Domanda: come posso rubare l'accesso alla password del system administrator (o infrangere la protezione del programma X, o trovare una copia sprotetta di Y, o leggere la posta di Z, o ...)?

Domanda: dove posso trovare il programma X?

Risposta: nello stesso posto dove l'ho trovato io, deficiente — alla fine di una ricerca sul Web. Cacchio, non ha ancora sentito nominare Google, questo sfigato?

Domanda: il mio programma (o la mia configurazione, od il mio comando SQL, o ...) non funziona.

Risposta: questa non è una domanda, e non ho voglia di giocare agli indovinelli per farti sputar fuori quello che non ti quaglia — ho di meglio da fare. Vedendo uno sfigato del genere, però, qualcuno potrebbe aver voglia di rispondere — magari così:

  • Non hai qualcosa da aggiungere?
  • Oh, peccato. Spero che tu metta tutto a posto.
  • E di questo cosa mi frega?

Domanda: ho dei problemi con la mia macchina Windows. Potete aiutarmi?

Risposta: si. Butta nel cesso quella merda ed installa un sistema decente come Linux od OpenBSD.

Domanda: ho problemi nell'installare Linux (o il programma X, o ...). Potete aiutarmi?

Risposta: no. Dovrei poter mettere le mani sulla tua macchina. Rivolgiti ad uno strafottuto LUG (Local User Group) di Linux. (Una lista degli user groups è sotto questa URL).

Domanda: come posso rubare l'accesso alla password del system administrator (o infrangere la protezione del programma X, o trovare una copia sprotetta di Y, o leggere la posta di Z, o ...)?

Risposta:sei uno str@#&% a voler fare una cosa del genere, ed un cog&@$&# a domandarlo qui.


Domande buone e domande cattive

E, per finire, qualche esempio di come porre le proprie domande: per ogni problema considerato, sono elencate due maniere di chiedere; il modo stupido ed il modo furbo.

Stupido: dove posso trovare qualcosa sul Foonly Flurbamatic?

Questa domanda è una vera e propria richiesta di "STFW" come risposta.

Furbo: ho usato Google per cercare di trovare informazioni sul "Foonly Flurbamatic 2600", ma senza successo. Può qualcuno darmi una indicazione su dove guardare, per trovare informazioni sull'uso di questo device?

Chi domanda ha già STFW-ato; ha solo delle difficoltà a trovare informazioni.

Stupido: non riesco a compilare il vostro programma "foo" sulla mia macchina. C'è uno sbaglio nel vostro codice!

Assume che siano gli altri a sbagliare. È un arrogante.

Furbo: il vostro programma "foo" versione y.z non compila in ambiente Nulix versione 6.2 col compilatore Gronk Professional versione w.x. Ho letto le FAQ, ma non dicono nulla riguardo a questo problema. Accludo di seguito una trascrizione della compilazione; potete darmi un suggerimento?

Ha specificato l'ambiente, letto le FAQ e descritto l'errore; non assume che lo sbaglio sia degli altri; questo ragazzo merita un po' di attenzione.

Stupido: ho problemi con la mia scheda madre. Chi mi può aiutare?

La risposta potrebbe essere "Quali sono i problemi con la scheda madre? Non ti allatta bene? Non ti cambia i pannolini?"

Furbo: ho tentato di intervenire su X, Y e Z nella motherboard; e, dopo, ho provato a fare A, B e C. Stranamente, dopo aver fatto C, ho osservato D. La causa potrebbe essere E, ma l'effetto non dovrebbe essere differente? Qualcuno ha un'idea di cosa posso tentare per capire da dove viene il problema?

Costui sembra aver lavorato; ha cercato di capire con svariate prove cosa ha causato i suoi problemi — merita di essere aiutato.

Nell'ultima domanda, notate ancora la sottile ma importante differenza tra "Rispondetemi" e "Per favore, aiutatemi a capire che altre prove potrei fare per raggiungere la luce".

In effetti, l'ultima domanda (nella forma furba) è la parafrasi di un messaggio reale, inviato nell'agosto 2001 alla mailing list "linux-kernel" da me (Eric). Vedevo misteriosi lockups su una motherboard Tyan S2464; i frequentatori della lista mi hanno dato tutte le informazioni necessarie per venire a capo del problema.

Presentando la domanda in quella forma, ho dato ai lettori del messaggio qualcosa su cui rimuginare; ho stimolato, rendendo la cosa un attraente problema logico, la loro voglia di farsi coinvolgere nei miei guai. Ho dimostrato rispetto per l'abilità dei frequentatori della lista, e li ho invitati a discutere con me la situazione come con un loro pari; e, nello stesso tempo, ho dimostrato anche rispetto per il valore del loro tempo: segnalando tutti i vicoli ciechi in cui mi ero già cacciato.

Alla fine, quando ho ringraziato tutti per l'aiuto e sottolineato con quanta rapidità si era arrivati alla soluzione, un altro membro della lista ha osservato che questo era successo non perchè io fossi già un "nome noto" della lista stessa — ma perchè la domanda era stimolante e ben posta.

Quella degli hackers è, in un certo senso, una spietata meritocrazia; sono certo che quella persona avesse ragione e che, se io avessi presentato la cosa malamente, sarei stato sbeffeggiato o ignorato nonostante fossi, appunto, un "nome noto". Questa constatazione è stata la causa scatenante che ha portato alla scrittura di questa pagina.


Se nessuno ci risponde

Se non arriva una risposta, non prendete come un affronto personale il fatto che nessuno vi abbia aiutato. Ogni tanto i membri del gruppo, semplicemente, non conoscono la risposta; "nessuna risposta" non è lo stesso che "essere ignorato", nonostante io ammetta che non sia facile, dall'esterno, capire la differenza.

In generale, riproporre la domanda pari pari è una cattiva idea — che viene percepita come insistenza gratuita, seccante e molesta.

Ci sono altre fonti di aiuto, spesso più adatte ad un novizio; e molti newsgroups differenti: forse avete scelto quello sbagliato per trovare esperti in grado di aiutarvi.

Ci sono anche parecchie società commerciali, grandi e piccole, che potete contattare per essere assistiti (Red Hat e Linuxcare sono due delle più note, e ce ne sono diverse altre). Non spaventatevi all'idea di dover pagare per l'aiuto! Dopo tutto, se il motore della vostra auto si rompe, assai probabilmente dovrete portarla in un'officina e pagare perchè venga riparata; anche se un certo software non vi è costato niente, questo non implica l'esistenza di una assistenza gratuita.

Per un software così diffuso come (ad esempio) Linux, ci sono circa 10000 utilizzatori per ogni sviluppatore; ricordatevi che, se anche dovrete pagare qualcosa per l'assistenza, sarà probabilmente assai meno di quello che avreste dovuto pagare per acquistare un software dello stesso pregio da uno sviluppatore commerciale (ed il servizio di supporto per il software commerciale è di solito molto più costoso e soprattutto molto meno competente di quello a disposizione per il software open-source).


Risorse collegate

Istruzioni di base su come funzionano i personal computers, Unix ed Internet: leggete The Unix and Internet Fundamentals HOWTO.

Se scrivete software o patches per il software, cercate di seguire le regole di massima delineate nel Software Release Practice HOWTO.


Versione originale: in questa URL, a cura di Eric S. Raymond (email esr@thyrsus.com).

Questa pagina è stata scritta con [vim]

==> Ultima revisione: 17 Marzo 2002 - MLO (loreti at pd dot infn dot it)

==> Commenti? Cliccate qui.

==> Valido HTML 4.01; clicca qui per rivalidare la pagina.