Come fare domande in modo intelligente – traduzione italiana


Eric Steven Raymond
Thyrsus Enterprises
<esr@thyrsus.com>
Rick Moen
<respond-auto@linuxmafia.com>
Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen

Indice delle revisioni (versione italiana)

+-------------------+---------+---------------+-------------+-------------------+
| Vers. originale   | Vers.   | Autore vers.  |             |                   |
| di riferimento    | tr. it. | italiana      |     Data    |       Note        |
+-------------------+---------+---------------+-------------+-------------------+
| 3.10 (21/05/2014) |   1.0   | Man from Mars | 08/Gen/2016 | 1a trad. italiana |
+-------------------+---------+---------------+-------------+-------------------+

Note alla traduzione italiana (Man from Mars)

Alcuni termini sono stati italianizzati secondo il comune utilizzo nel contesto di Internet, ad esempio il verbo “To Post” (inviare un messaggio ad una mailing list o newsgroup) è stato tradotto con “Postare”, mentre altri sono rimasti nella loro forma originale con una breve nota sul significato la prima volta che vengono incontrati.

Per rendere al meglio il tono del documento, ho preferito utilizzare una forma diretta (“…quando TU fai una domanda…“) piuttosto che una forma impersonale, così come è diretto lo stile di Raymond nel rivolgersi a chi legge il documento. Ho cercato anche di rendere al meglio le espressioni gergali o idiomatiche, trovando, quando possibile, le corrispondenti espressioni in italiano.

Come lo stesso Raymond chiarirà in seguito, questo testo non è una guida per principianti e quindi la terminologia può talvolta apparire troppo tecnica, d’altronde è quello che si definisce il Jargon (gergo) degli hacker. Nel Jargon troverete anche la descrizione di J. Random Hacker, il “prototipo” di hacker a cui Raymond si riferisce in alcuni passaggi.

I link di approfondimento che il documento contiene sono rimasti per la maggior parte in lingua originale; chi ne trovasse una traduzione italiana non esiti a segnalarmelo.

Per commenti e segnalazioni riferirsi al post “Come fare domande in modo intelligente (Eric S. Raymond) – traduzione italiana“.

Link alla versione originale


Indice dei contenuti

Traduzioni
Rinuncia di responsabilità
Introduzione
Prima di chiedere
Quando chiedi

Come interpretare le risposte

Non reagire istericamente
Domande da non fare
Domande buone e cattive
Se non ottieni una risposta
Come rispondere in modo utile
Risorse collegate
Riconoscimenti


Traduzioni

Traduzioni: Danish Bahasa Indonesian Belorussian Bulgarian Brazilo-Portuguese Bulgarian Chinese (Traditional) Croatian Dutch French Georgian German Greek Japanese Polish Romanian Russian Serbian Spanish Slovak Thai Ukrainian

Se volete copiare, duplicare, tradurre o pubblicare estratti di questo documento, per favore leggete la mia copying policy.

⇑ Indice

Rinuncia di responsabilità

Molti siti rimandano a questo documento nelle loro sezioni di aiuto. Va bene, è l’uso che intendevamo – ma se siete webmaster e create un link sulla vostra pagina, per favore evidenziate chiaramente accanto al link che noi non siamo l’help desk per il vostro progetto!

Abbiamo imparato nel modo peggiore che senza tale avviso, noi saremo ripetutamente importunati da idioti che pensano che la pubblicazione di questo documento renda nostro il lavoro di risolvere tutti i problemi tecnici del mondo.

Se stai leggendo questo documento perché cerchi aiuto ed hai l’impressione di poterlo avere direttamente dai suoi autori, tu sei uno degli idioti di cui stiamo parlando. Non fare a noi le domande. Semplicemente ti ignoreremo. Noi siamo qui per mostrarti come ottenere aiuto dalle persone che effettivamente conoscono il software o l’hardware con cui hai a che fare, ma il 99.9% delle volte quelle persone non siamo noi. A meno di non sapere per certo che uno degli autori è un esperto di ciò che ti interessa, lasciaci perdere e saremo tutti più felici.

⇑ Indice

Introduzione

Nel mondo degli hacker il tipo di risposta che si ottiene alle proprie domande tecniche dipende tanto dal modo in cui si chiede quanto dalla difficoltà di articolare la risposta. Questa guida vi indicherà come fare le domande in modo che sia più probabile ottenere una risposta soddisfacente.

Adesso che l’uso dell’open source si è diffuso, si può spesso avere una buona risposta tanto da utenti esperti quanto da hacker. Questa è una Cosa Buona; gli utenti tendono ad essere un tantino più tolleranti rispetto ai problemi che spesso hanno i principianti. Inoltre, trattare gli utenti esperti come hacker nei modi che raccomandiamo qui sarà generalmente il metodo più efficace per ottenere risposte utili anche da loro.

La prima cosa da capire è che agli hacker piacciono molto i problemi difficili e le domande interessanti e stimolanti in merito. Se non fosse stato così, non saremmo qui. Se ci dai una domanda interessante su cui riflettere, te ne saremo grati; le buone domande sono uno stimolo e un dono. Le buone domande ci aiutano a sviluppare la nostra comprensione, e spesso rivelano problemi che potremmo non aver notato o considerato altrimenti. Tra gli hacker, “Bella domanda!” è un complimento forte e sincero.

Malgrado ciò, gli hacker hanno la reputazione di trattare le domande semplici con quella che sembra ostilità o arroganza. Sembra a volte che noi siamo intenzionalmente scortesi verso i principianti e gli ignari. Ma questo non è del tutto vero.

Quel che è certo è che, senza remore, siamo ostili verso le persone che sembrano non voler pensare o svolgere i propri compiti prima di fare domande. Persone così assorbono tempo – prendono senza dare, ed occupano il tempo che avremmo potuto spendere su un’altra domanda più interessante e un’altra persona più degna di risposta. Noi chiamiamo queste persone “losers” [lett.: perdenti – N.d.T.] (e per ragioni storiche a volte lo scriviamo “lusers“) [gioco di parole con “users”, utenti – N.d.T.].

Ci rendiamo conto che ci sono molte persone che vogliono solo usare il software che scriviamo, e che non hanno alcun interesse ad imparare i dettagli tecnici. Per la maggioranza delle persone, un computer è solamente uno strumento, un mezzo per un fine; loro hanno cose più importanti da fare e vite da vivere. Noi ce ne rendiamo conto, e non ci aspettiamo che tutti si interessino alle questioni tecniche che ci affascinano. Nondimeno, il nostro stile di risposta alle domande è in accordo con le persone che invece vogliono interessarsene e desiderano essere parte attiva nella soluzione del problema. Tutto ciò non è destinato a cambiare. Né dovrebbe: se lo facesse, noi diventeremmo meno efficaci nelle cose che facciamo meglio.

Noi siamo (principalmente) volontari. Prendiamo tempo dagli impegni delle nostre vite per rispondere a domande, e a volte ne siamo sopraffatti. Quindi filtriamo spietatamente. In particolare, scartiamo le domande di persone che appaiono essere “lusers” per poter impiegare più efficientemente il tempo a disposizione per le risposte, sui “winners” [lett.: vincenti – N.d.T.].

Se trovi questo comportamento odioso, condiscendente, o arrogante, ripensa ai tuoi presupposti. Non ti stiamo chiedendo di genufletterti a noi – in realtà, la maggioranza di noi non vorrebbe altro che trattare con te da pari ed accoglierti nella nostra cultura, se tu fai lo sforzo richiesto per renderlo possibile. Ma semplicemente non è efficiente per noi tentare di aiutare persone che non vogliono aiutare se stesse. Va bene non sapere; non va bene fare la parte dello stupido.

Quindi, sebbene non sia necessario essere già tecnicamente competenti per ricevere attenzione da noi, è necessario dimostrare il tipo di atteggiamento che porta alla competenza – vigile, attento, riflessivo, intenzionato ad essere un collaboratore attivo nello sviluppare una soluzione. Se non puoi sopportare questo tipo di discriminazione, ti suggeriamo di pagare qualcuno per un contratto di supporto commerciale invece di chiedere agli hacker di darti personalmente aiuto.

Se decidi di rivolgerti a noi per un aiuto, non vorrai certo essere uno di quei perdenti. Non vorrai nemmeno sembrare uno di quelli. Il miglior modo per ottenere una risposta rapida ed esauriente è di chiederla come una persona con capacità, competenze e indizi a cui capita di aver bisogno di un aiuto su un problema in particolare.

(I miglioramenti a questa guida sono benvenuti. Potete inviare i suggerimenti via mail a esr@thyrsus.com o respond-auto@linuxmafia.com. Notate comunque che questo documento non è pensato per essere una guida generale alla netiquette, e generalmente rifiuteremo suggerimenti che non sono specificamente legati a ricavare risposte utili in un forum tecnico.)

⇑ Indice

Prima di chiedere

Prima di fare una domanda tecnica via e-mail, o in un newsgroup, o sulla chat di un sito web, fai così:

  1. Prova a trovare una risposta negli archivi del forum in cui vuoi postare.
  2. Prova a trovare una risposta sul Web.
  3. Prova a trovare una risposta leggendo il manuale.
  4. Prova a trovare una risposta leggendo le FAQ.
  5. Prova a trovare una risposta esaminando o sperimentando.
  6. Prova a trovare una risposta chiedendo ad un amico esperto.
  7. Se sei un programmatore, prova a trovare una risposta leggendo il codice sorgente.

Quando fai la tua domanda, dimostra che in precedenza hai fatto tutto questo; ciò aiuterà a stabilire che non sei una pigra “spugna” e che non fai sprecare tempo alle persone. Ancora meglio, mostra cosa hai imparato facendo questi passi. A noi piace rispondere alle domande di persone che hanno dimostrato di poter imparare dalle risposte.

Usa tattiche come ricercare su Google il testo di qualunque messaggio di errore tu abbia avuto (cercando nei Google groups e nelle pagine Web). Questo potrebbe portarti dritto a documentazione di supporto o ad una discussione di una mailing list che contiene la tua risposta. E se ciò non accade, dire “Ho cercato su Google la seguente frase ma non ho ottenuto niente che sembrasse promettente” è una buona cosa da fare nei post via mail o news di richiesta d’aiuto, se non altro perché registra quali ricerche non aiutano. Questo aiuterà anche altre persone con problemi simili alla tua discussione, collegando i termini di ricerca a quello che, si spera, sarà la discussione del tuo problema e della soluzione.

Prenditi il tuo tempo. Non aspettarti di riuscire a risolvere un problema complesso con pochi secondi di ricerca su Google. Leggi e comprendi le FAQ, mettiti comodo, rilassati e pensa un po’ al problema prima di contattare gli esperti. Fidati di noi, loro saranno capaci di capire dalle tue domande quanto hai letto e quanto hai riflettuto sul problema, e ti aiuteranno più volentieri se arrivi preparato. Non sparare subito tutto il tuo arsenale di domande solo perché la tua prima ricerca non ha dato risultati (o ne ha dati troppi).

Prepara le tue domande. Pensaci su. Le domande che suonano frettolose ricevono risposte frettolose, o non ne ricevono affatto. Più dimostri che hai pensato e ti sei sforzato di risolvere il tuo problema prima di cercare aiuto, e più probabilmente riceverai aiuto.

Attenzione a fare le domande sbagliate. Se ne fai una che è basata sui presupposti sbagliati, J. Random Hacker [come dire: un qualunque hacker – N.d.T.] probabilmente ti darà una risposta inutilmente dettagliata mentre pensa “Domanda stupida…”, sperando che l’esperienza di ottenere quello che chiedevi piuttosto che quello che ti serviva ti insegni una lezione.

Non presupporre mai di avere diritto ad una risposta. Non è così; dopotutto, non stai pagando per il servizio. Ti guadagnerai una risposta, eventualmente, facendo una domanda sostanziale, interessante e che dà spunti di riflessione – una che implicitamente contribuisce all’esperienza della comunità piuttosto che meramente richiedere passivamente la conoscenza di altri.

D’altro canto, rendere chiaro che sei capace e desideroso di aiutare nel processo di sviluppo della soluzione è un ottimo punto di partenza. “Qualcuno può darmi un’indicazione?”, “Cosa manca nel mio esempio?” e “Che sito avrei dovuto guardare?” riceveranno più probabilmente risposta rispetto a “Per favore scrivete l’esatta procedura che dovrei usare” perché stai dichiarando che hai veramente intenzione di completare il processo se solo qualcuno ti indirizza nella direzione giusta.

⇑ Indice

Quando chiedi

Scegli attentamente il forum

Sii accorto a scegliere dove porre le tue domande. È probabile che ti ignorino, o ti etichettino come loser, se:

  • poni la tua domanda in un forum dove è fuori tema (off topic)
  • poni una domanda molto elementare in un forum dove ci si aspetta questioni tecniche avanzate, o viceversa
  • poni la stessa domanda su troppi newsgroup differenti (cross-post)
  • mandi una e-mail personale a qualcuno che non è né di tua conoscenza né personalmente responsabile nel risolvere il tuo problema

Gli hacker spazzano via le domande che sono inappropriatamente indirizzate nel tentativo di proteggere i propri canali di comunicazione dall’essere affogati nell’irrilevanza. E tu non vuoi che questo accada a te.

Il primo passo, quindi, è di trovare il giusto forum. Di nuovo, Google ed altri metodi di ricerca sul Web sono tuoi amici. Usali per trovare la pagina del progetto maggiormente collegata all’hardware o al software che ti crea difficoltà. Di solito avrà collegamenti ad una lista di FAQ (Frequently Asked Questions), a mailing list del progetto ed ai loro archivi. Queste mailing list sono l’ultimo posto dove andare, se i tuoi sforzi (incluso leggere le FAQ che hai trovato) non portano ad una soluzione. La pagina del progetto può anche descrivere una procedura di segnalazione dei bug, o avere un collegamento ad una; se è così, seguilo.

Spedire una e-mail ad una persona od un forum con cui non si è familiari è, quantomeno, rischioso. Per esempio, non supporre che l’autore di una pagina informativa voglia essere il tuo consulente gratuito. Non fare previsioni ottimistiche sul fatto che la tua domanda sia la benvenuta – nel dubbio, inviala da un’altra parte, o evita del tutto di inviarla.

Quando si sceglie un forum, un newsgroup o una mailing list, non fidarti troppo del solo nome; cerca le FAQ o verifica che la tua domanda sia in tema (on-topic). Leggi qualcuno dei messaggi già presenti prima di postare, così avrai la sensazione di come ci si comporta lì. In effetti, è un’ottima idea fare una ricerca delle parole collegate al tuo problema sul newsgroup o gli archivi della mailing list prima di postare. Ti può fruttare una risposta, o altrimenti ti aiuterà a formulare meglio una domanda.

Non bruciare nello stesso momento tutti i canali d’aiuto disponibili, ciò equivale ad urlare ed irrita le persone. Piuttosto attraversali uno ad uno con cautela.

Sii sicuro dell’argomento! Uno dei classici errori è quello di domandare dell’interfaccia di programmazione di Unix o Windows in un forum dedicato ad un linguaggio, una libreria o uno strumento comune ad entrambi. Se non capisci perché questo sia un errore, faresti meglio a non fare alcuna domanda finché non ci arrivi.

In generale, le domande hanno più probabilità di ottenere una risposta utile se poste ad un forum pubblico accuratamente scelto rispetto ad un forum privato. Ci sono molte ragioni per questo. Una è semplicemente la quantità di persone potenzialmente disponibili a rispondere. Un’altra è la dimensione della platea; gli hacker preferiscono rispondere a domande che educano molte persone piuttosto che a domande che servono a pochi.

Comprensibilmente, gli hacker esperti e gli autori di software popolari già stanno ricevendo molto più della loro dose di messaggi male indirizzati. Aggiungendosi al mucchio, nel peggiore dei casi potresti essere la goccia che fa traboccare il vaso – in qualche occasione, i contributori di progetti popolari hanno ritirato il loro supporto perché il danno collaterale dell’inutile flusso di e-mail al proprio account era diventato insostenibile.

⇑ Indice

Stack Overflow

Cerca, e solo dopo chiedi su Stack Exchange.

Di recente  la comunità di siti di Stack Exchange si è imposta come una delle maggiori risorse per rispondere a questioni tecniche e di altro tipo ed è perfino il forum preferito per molti progetti open-source.

Comincia con una ricerca su Google prima di rivolgerti a Stack Exchange: Google indicizza in tempo reale. C’è un’ottima probabilità che qualcuno abbia già fatto una domanda simile, e i siti di Stack Exchange sono spesso nei primi posti dei risultati di ricerca. Se non trovi niente tramite Google, cerca nuovamente sul sito specifico più indicato per la tua domanda (vedi sotto). Cercare tramite “tag” può aiutare a restringere i risultati.

Se ancora non trovi nulla, posta la domanda su un solo sito che tratta più specificamente l’argomento. Usa gli strumenti di formattazione, specialmente per il codice, e aggiungi tag collegati alla sostanza della tua domanda (in particolare il linguaggio di programmazione, sistema operativo o libreria di programmazione con i quali stai avendo difficoltà). Se un commentatore chiede più informazioni, modifica il post principale per aggiungerle. Se una risposta è d’aiuto, clicca la freccia per promuoverla; se una risposta risolve il problema, clicca il segno di spunta sotto la freccia per accettarla come corretta.

Stack Exchange include più di 100 siti, ma tra questi i candidati più probabili sono:

  • Super User è per domande generali sull’informatica. Se la tua domanda non è su codice o programmi con cui dialoghi solo tramite rete, allora probabilmente va qui.
  • Stack Overflow è per domande di programmazione.
  • Server Fault è per domande su server e amministrazione di rete.

Molti progetti hanno i loro siti dedicati, inclusi Android, Ubuntu, TeX/LaTeX e SharePoint. Consulta la lista aggiornata sulla pagina di Stack Exchange.

Forum Web e IRC

Il tuo gruppo di utenti locali, o la tua distribuzione Linux, può indicare un forum Web o un canale IRC dove i principianti possono avere aiuto. (Nelle nazioni non di lingua inglese i forum per principianti sono più probabilmente delle mailing list.) Questi sono buoni posti dove iniziare a chiedere, specialmente se si pensa di stare affrontando un problema relativamente semplice o comune. Un canale IRC consigliato è un invito aperto a porre domande, per ottenere spesso risposte in tempo reale.

Di fatto, se un programma che ti dà problemi è incluso in una distribuzione Linux (come è comune oggi), può essere meglio chiedere nel forum/lista della distro prima di provare sul forum/lista del programma. Gli hacker del progetto potrebbero semplicemente dire, “usa la nostra build”.

Prima di postare in qualunque forum Web, controlla se c’è una funzione di Ricerca. Se c’è, prova un paio di ricerche per parole chiave attinenti al tuo problema; potrebbe aiutare. Se hai fatto una ricerca globale sul Web in precedenza (come avresti dovuto fare), cerca comunque nel forum; il tuo motore di ricerca Web potrebbe non avere indicizzato tutto il forum di recente.

C’è una crescente tendenza per i progetti a fare supporto agli utenti tramite forum Web o canali IRC, con e-mail riservate a comunicazioni di sviluppo. Cerca questi canali prima di tutto quando ti serve aiuto su un progetto specifico.

⇑ Indice

Come secondo passo, usa le mailing list del progetto

Quando un progetto ha una mailing list di sviluppo, scrivi alla mailing list, non personalmente agli sviluppatori, anche se credi di sapere chi può rispondere meglio alla tua domanda. Controlla nella documentazione del progetto e nella sua homepage l’indirizzo della mailing list di progetto, e usalo. Ci sono molte buoni ragioni per comportarsi così:

  • Ogni domanda buona abbastanza da essere posta direttamente ad uno sviluppatore sarà preziosa anche per l’intero gruppo. Al contrario, se sospetti che la tua domanda sia troppo semplice per una mailing list, non è una scusa per molestare personalmente gli sviluppatori.
  • Porre domande nella lista distribuisce il carico tra gli sviluppatori. Il singolo sviluppatore (specialmente se è il responsabile di progetto) può essere troppo occupato per rispondere alle tue domande.
  • Gran parte delle mailing list sono archiviate e gli archivi sono indicizzati dai motori di ricerca. Se fai una domanda sulla lista e ottieni risposta, il prossimo che cercherà troverà la domanda e la risposta sul Web anziché farla di nuovo.
  • Se si nota che alcune domande vengono poste spesso, gli sviluppatori possono usare questa informazione per migliorare la documentazione o lo stesso software affinché sia meno confusionario. Ma se queste domande sono poste in privato, nessuno ha il quadro completo di quali siano le domande più frequenti.

Se un progetto ha sia una lista/forum “utenti” che “sviluppatori” (o “hacker”), e tu non stai modificando il codice, chiedi nella lista/forum “utenti”. Non supporre di essere il benvenuto sulla lista “sviluppatori”, in cui probabilmente percepiranno la tua domanda come “rumore” che disturba il flusso di informazioni di sviluppo.

Comunque, se sei sicuro che la tua domanda non sia banale, e non ottieni risposta dalla lista/forum “utenti” dopo molti giorni, prova quella per “sviluppatori”. Abbi cura di osservare per qualche giorno prima di postare per imparare i “costumi” locali (in effetti questo è un buon consiglio su qualunque lista privata o semi-privata).

Se non riesci a trovare un indirizzo della mailing list del progetto, ma vedi l’indirizzo del manutentore del progetto, fatti avanti e scrivigli. Ma anche in questo caso, non presupporre che la mailing list non esista. Menziona nella tua mail che hai provato e non sei riuscito a trovare la mailing list giusta. Menziona anche che non hai obiezioni al fatto che il messaggio sia inoltrato ad altre persone. (Molte persone credono che l’e-mail privata debba rimanere tale, anche se non c’è niente di segreto. Autorizzando l’inoltro del tuo messaggio dai al tuo corrispondente una scelta su come gestirlo.)

⇑ Indice

Usa titoli significativi e specifici

Sulle mailing list, i newsgroups o i forum Web, l’intestazione è la tua opportunità d’oro per attirare l’attenzione di esperti qualificati con circa 50 caratteri o meno. Non sprecarla in farfugliamenti tipo “Per favore aiutatemi” (per non parlare di “PER FAVORE AIUTATEMI!!!!”; i messaggi con simile intestazione vengono scartati d’istinto). Non provare ad impressionarci con la profondità della tua angoscia; piuttosto usa lo spazio per una descrizione molto sintetica del problema.

Una buona convenzione per le intestazioni, usata da molte organizzazioni di supporto tecnico, è “oggetto – malfunzionamento”. La parte “oggetto” specifica quali cose o gruppo di cose sta avendo problemi, e la parte “malfunzionamento” descrive la difformità dal funzionamento atteso.

  • Stupido:
    AIUTO! Il video non funziona bene sul mio laptop!
  • Intelligente:
    X.org 6.8.1 cursore mouse deformato, Fooware MV1005 vid. chipset
  • Più intelligente:
    X.org 6.8.1 cursore mouse su Fooware MV1005 vid. chipset – è deformato

Scrivere una descrizione strutturata in “oggetto – malfunzionamento” ti aiuterà ad organizzare in maggior dettaglio le tue riflessioni sul problema. Cosa ne è affetto? Solo il mouse o altri elementi grafici? È specifico per questa versione di X.org? Per la versione 6.8.1? È specifico per i chipset video Fooware? Per il modello MV1005? Un hacker che vede il risultato può immediatamente capire con cosa stai avendo problemi e il problema che hai alla prima occhiata.

Più in generale, immagina di guardare l’indice di un archivio di domande, con le solo intestazioni visibili. Fa’ che la tua intestazione rifletta la domanda abbastanza bene per cui il prossimo a cercare nell’archivio una domanda simile alla tua possa seguire la discussione fino alla risposta, piuttosto che porre nuovamente la domanda.

Se poni una domanda in una replica ad un messaggio, sii certo di cambiare l’intestazione indicando che stai facendo una domanda. Un’intestazione tipo “Re: test” or “Re: nuovo bug” probabilmente attirerà meno attenzioni utili. Inoltre, limita le citazioni dei messaggi precedenti al minimo necessario a dare indicazioni ai nuovi lettori.

Non rispondere ad un messaggio della lista solo per iniziare una discussione (thread) completamente nuova. Questo limiterà il tuo pubblico. Alcuni lettori di posta, come mutt, consentono all’utente di ordinare  e contrarre i thread, nascondendo i messaggi. Chi fa così non vedrà mai il tuo messaggio.

Cambiare l’intestazione non è sufficiente. Mutt, e probabilmente altri client di posta, guardano ad altre informazioni nell’intestazione del messaggio per assegnarlo ad un thread, non la sola riga d’intestazione. Piuttosto apri una nuova discussione.

Sui forum le regole di buona pratica sono leggermente differenti, perché i messaggi sono di solito molto più strettamente legati a specifiche discussioni e spesso invisibili al di fuori di essi. Cambiare l’intestazione facendo una domanda in replica non è essenziale. Non tutti i forum consentono linee separate di intestazione nelle repliche, e quasi nessuno le legge quando ciò è possibile. Ad ogni modo, porre una domanda in una risposta è di per sé una pratica di dubbia utilità, perché sarebbe vista solo da chi segue il thread in questione. Quindi, a meno di che tu non sia sicuro di voler chiedere solo alle persone attualmente partecipanti al thread, iniziane uno nuovo.

⇑ Indice

Rendi facile la risposta

Terminare la tua richiesta con “Per favore, rispondere a…” rende abbastanza improbabile che tu riceva una risposta. Se non vuoi nemmeno disturbarti ad impiegare pochi secondi per impostare una corretta intestazione di risposta nel tuo programma di posta, neanche noi possiamo farlo per dedicare qualche secondo al tuo problema. Se il tuo client di posta non permette ciò, usa un programma migliore. Se il tuo sistema operativo non supporta alcun programma di posta che lo permette, usa un sistema operativo migliore.

Nei forum, richiedere una risposta via mail è scortese, a meno che tu non ritenga l’informazione possa essere riservata (e qualcuno, per ragioni sconosciute, lo farà sapere a te e non a tutto il forum). Se vuoi una copia della mail quando qualcuno interviene nel thread, richiedi al forum di mandarla; questa funzionalità è supportata quasi ovunque con opzioni come “Osserva il thread”, “Invia mail in caso di risposte”, etc.

⇑ Indice

Scrivi in modo chiaro, grammaticalmente e ortograficamente corretto

Abbiamo capito per esperienza che le persone che scrivono in modo disattento e sciatto sono di solito disattente e sciatte nel pensare e nel programmare (comunque abbastanza spesso, ci scommetto). Rispondere alle loro domande non è gratificante; preferiamo impiegare il tempo da un’altra parte.

Quindi scrivere le domande in maniera chiara e corretta è importante. Se non vuoi prenderti la briga di farlo, noi non possiamo prenderci la briga di dedicarti attenzione. Fai uno sforzo in più per affinare il tuo linguaggio. Non deve essere rigido o formale — infatti, la cultura hacker apprezza il linguaggio informale, gergale e umoristico usato con precisione. Ma deve essere preciso; ci deve essere qualche indicazione che tu stai riflettendo e prestando attenzione.

Fai attenzione all’ortografia, all’uso della punteggiatura e delle maiuscole. Non confondere “its” con “it’s”, “loose” con “lose”, o “discrete” with “discreet” [esempi di comuni errori – N.d.T.]. Non DIGITARE TUTTO IN MAIUSCOLO, questo viene interpretato come se stessi urlando e ti fa passare per maleducato. Tutto minuscolo è solo un po’ meno seccante ma difficile da leggere. Per Alan Cox può andare, ma non per te [Alan Cox su Wikipedia – N.d.T.].

Più in generale, se scrivi come uno stupido semi-analfabeta sarai probabilmente ignorato. Quindi non usare abbreviazioni da chat. Scrivere “u” al posto di “you” [come in italiano scrivere “x” al posto di “per”, ad esempio – N.d.T.] solo per risparmiare due lettere ti fa sembrare uno stupido semi-analfabeta. Peggio ancora: scrivere in “l33t” come uno “script kiddie hax0r” [l33t: Tipo di scrittura che sostituisce alcune lettere con numeri o altri simboli, es.: Leet Speak -> |33t 5p34k; script kiddie: coloro che usano strumenti scritti da altri per fare danni in rete – N.d.T.] è l’assoluto colpo di grazia e ti garantisce che in cambio non riceverai altro che un silenzio tombale (o, al massimo, un bel po’ di disprezzo e sarcasmo).

Se partecipi ad un forum in cui non si usa la tua lingua madre, avrai una tolleranza limitata per l’ortografia e gli errori di grammatica – ma nessuna tolleranza per la pigrizia (e sì, di solito riusciamo a capire la differenza). Inoltre, a meno che tu non sappia la lingua del tuo corrispondente, scrivi in inglese. Gli hacker impegnati tendono semplicemente ad ignorare le domande in lingue che non capiscono, e l’inglese è la lingua con cui si lavora su Internet. Scrivendo in inglese ridurrai al minimo le possibilità che la tua domanda sia scartata senza essere letta.

Se scrivi in inglese ma non è la tua lingua madre, è buona norma avvertire i potenziali corrispondenti delle possibili difficoltà di lingua e delle opzioni per superarle. Esempi:

  • L’inglese non è la mia lingua madre; scusate i miei errori di ortografia.
  • Se parlate $LANGUAGE [la lingua madre di chi scrive, indicata da un hacker! – N.d.T.], per favore mandatemi una mail o un messaggio privato; potrei aver bisogno di aiuto per tradurre la domanda.
  • Ho familiarità con i termini tecnici, ma mi risulta difficile capire alcune espressioni idiomatiche.
  • Ho inserito la mia domanda in $LANGUAGE e in inglese. Sarò lieto di tradurre la risposta, se voi usate solo una delle due lingue.

⇑ Indice

Invia le domande in formati standard e accessibili

Se rendi la tua domanda artificiosamente difficile da leggere, è più probabile che sia ignorata in favore di un’altra che non lo è. Quindi:

  • Invia e-mail in testo semplice, non HTML (non è difficile disattivare l’HTML). Ulteriori discussioni sul perché questa sia una buona regola si possono trovare qui e qui.
  • Gli allegati MIME di solito vanno bene, ma solo se sono dei contenuti utili (un file sorgente o una patch), e non un semplice riempitivo generato dal tuo programma di posta (come un’altra copia del tuo messaggio).
  • Non inviare e-mail in cui interi paragrafi sono linee singole mandate più volte a capo. Questo rende troppo difficile rispondere ad una sola parte del messaggio. Considera che i tuoi corrispondenti leggeranno il messaggio su un monitor con 80 caratteri di larghezza e regola la messa a capo automatica coerentemente, ad un valore poco minore di 80.
  • Comunque, non mandare a capo i dati (come i dump di file di registro o le trascrizioni di sessione) ad un valore di larghezza fissa. I dati dovrebbero essere inclusi nella loro forma originale, in modo che chi risponde sia sicuro di vedere quello che hai visto tu.
  • Non usare la codifica MIME Quoted-Printable [lettere accentate e caratteri non Standard Ascii – N.d.T.] in un forum di lingua inglese. Questa codifica può essere necessaria quando scrivi in una lingua che non usa caratteri ASCII, ma molti client di posta non la supportano. Se i caratteri sono male interpretati, tutti quei segni “=20” sparsi nel testo sono brutti e fastidiosi – o possono inficiare il significato del tuo testo.
  • Non aspettarti mai e poi mai che gli hacker possano leggere documenti in formato chiuso e proprietario come Microsoft Word o Excel. A questo la maggior parte degli hacker reagisce come farebbe se gli scaricassero un cumulo di sterco di maiale fumante davanti alla porta di casa. E anche quando ci convivono, si sentono offesi a doverlo fare.
  • Se invii una mail da una macchina Windows, disattiva la problematica opzione Microsoft “Smart Quotes” [Virgolette semplici > Virgolette inglesi – N.d.T.] (da Strumenti > Correzione automatica, smarca la casella “Correggi automaticamente durante la digitazione”). Così facendo eviterai di spargere caratteri spazzatura nella tua mail.
  • Nei forum, non abusare degli “smiley” e dei tag “HTML” (quando sono disponibili). Uno smiley o due di solito va bene, i testi stravaganti e colorati inducono le persone a pensare che tu sia stupido. Utilizzare molti smiley, colori e font ti fa apparire come una sciocca ragazzina sghignazzante, cosa che non è generalmente una buona idea a meno che tu non sia più interessato al sesso che alle risposte.

Se stai usando un client con interfaccia grafica come Netscape Messenger, MS Outlook, o simili, tieni presente che il programma può violare queste regole se usato con le impostazioni predefinite. Molti di questi programmi hanno un menu con il comando “Visualizza sorgente”. Usalo su un messaggio nella della tua posta inviata, verificando di aver mandato testo semplice senza inutili schifezze allegate.

⇑ Indice

Sii preciso ed informativo sul tuo problema

  • Descrivi i sintomi del tuo problema o il bug accuratamente e chiaramente.
  • Descrivi le condizioni in cui si verifica (macchina, SO, applicazione, qualunque cosa). Includi il nome della distribuzione e la release (ad es.: “Fedora Core 7”, “Slackware 9.1”, etc.).
  • Descrivi la ricerca che hai fatto per provare a capire il problema prima di porre la domanda.
  • Descrivi i passi diagnostici che hai fatto per cercare di evidenziare il problema da solo prima di porre la domanda.
  • Descrivi ogni cambiamento recente potenzialmente rilevante nel tuo computer o configurazione software.
  • Se possibile, indica un modo di riprodurre il problema in condizioni controllate.

Fai del tuo meglio per anticipare le domande che un hacker farà, e danne le risposte preventivamente nella tua richiesta d’aiuto.

Dare agli hacker la possibilità di riprodurre il problema in condizioni controllate è particolarmente importante se stai segnalando qualcosa che tu pensi sia un bug nel codice. Così facendo, le tue probabilità di ottenere una risposta utile e la velocità con cui potresti riceverla aumentano enormemente.

Simon Tatham ha scritto un eccellente saggio intitolato How to Report Bugs Effectively. Ne raccomando caldamente la lettura.

⇑ Indice

La quantità non è precisione

Devi essere preciso ed informativo. Questo risultato non si consegue semplicemente scaricando mucchi di codice o dati in una richiesta d’aiuto. Se hai un caso di test ampio e complesso che blocca un programma, prova a ridurlo al minimo possibile.

Questo è utile per almeno tre ragioni. Uno: mostrare di fare lo sforzo di semplificare la domanda rende più probabile ricevere una risposta. Due: semplificare la domanda rende più probabile ricevere una risposta utile. Tre: nel processo di affinamento della tua segnalazione del bug, potresti sviluppare tu stesso una correzione o una soluzione.

⇑ Indice

Non precipitarti a gridare “Ho trovato un bug!”

Se stai avendo problemi con un software, non affermare di aver trovato un bug a meno che tu non sia molto, molto sicuro dei tuoi mezzi. Suggerimento: se non puoi fornire una patch al codice sorgente che risolve il problema, o un test di regressione rispetto ad una versione precedente che dimostri il comportamento anomalo, probabilmente non ne sei abbastanza sicuro. Questo vale anche per le pagine web e la documentazione: se hai trovato un “bug” nella documentazione, dovresti suggerire il testo sostitutivo e le pagine su cui deve andare.

Ricorda che ci sono molti altri utenti che non stanno riscontrando il tuo problema, altrimenti l’avresti capito leggendo la documentazione e cercando sul Web (l’hai fatto prima di lamentarti, vero?). Questo significa che molto probabilmente sei tu che fai qualcosa di sbagliato, non il software.

Le persone che hanno scritto il software hanno lavorato sodo per farlo funzionare al meglio possibile. Se sostieni di aver trovato un bug, stai mettendo in dubbio la loro competenza, cosa che può offendere alcuni di loro anche nel caso tu abbia ragione. É particolarmente poco diplomatico inserire “Bug!” nell’oggetto del messaggio.

Quando poni le tue domande, è meglio scrivere come se supponessi di essere tu stesso in errore, anche se sei abbastanza sicuro di avere effettivamente trovato un bug. Se c’è veramente un bug, ne sentirai parlare nella risposta. Fai in modo che i responsabili del progetto si scusino con te se il bug è reale, piuttosto che dovergli tu delle scuse per aver sbagliato.

⇑ Indice

Umiliarti non ti esime dal fare il tuo “lavoro”

Alcune persone che comprendono di non doversi comportare in modo scortese o arrogante, chiedendo una risposta, si spostano sull’estremo opposto dell’umiliazione. “Lo so che sono un patetico novellino, ma…”. Questo confonde e non aiuta. E’ particolarmente fastidioso quando è accompagnato da una descrizione vaga del problema.

Non sprecare il tuo tempo, o il nostro, in grezza politica da primate. Invece, presenta i fatti essenziali e le domande il più chiaramente possibile. Questo è un modo migliore di guadagnarsi un posto, piuttosto che umiliarsi.

A volte i forum hanno sezioni separate per le domande dei principianti. Se senti di avere una domanda del genere, vai lì. Ma non umiliarti neanche lì.

⇑ Indice

Descrivi i sintomi del problema, non le tue ipotesi

Non è utile dire agli hacker quello che tu ritieni essere la causa del problema. (Se le tue teorie diagnostiche fossero così buone, staresti consultando qualcun altro in cerca di aiuto?) Quindi, accertati di elencare i sintomi di quello che non va, piuttosto che le tue interpretazioni e teorie. Lascia a loro l’interpretazione e la diagnosi. Se ritieni importante esprimere la tua ipotesi, segnalala chiaramente come tale e descrivi perché la risposta fornita non va bene per te.

  • Stupido:
    Sto ricevendo continui errori SIG11 durante la compilazione del kernel, e sospetto una sottile crepa in una delle tracce della motherboard. Qual è il miglior modo per verificarlo?
  • Intelligente:
    Il mio assemblato K6/233 su motherboard FIC-PA2007 (VIA Apollo VP2 chipset) con 256Mb Corsair PC133 SDRAM comincia a dare frequenti errori SIG11, circa 20 minuti dopo averlo acceso e durante la compilazione del kernel, ma mai nei primi 20 minuti. Riavviarlo non azzera il minutaggio della durata [ovvero non rimane attivo per altri 20 minuti – N.d.T.], ma tenerlo spento durante la notte si. Scambiare la RAM non aiuta. Segue il log delle parti rilevanti di una tipica sessione di compilazione.

Poiché il punto precedente sembra essere di difficile comprensione per molti, ecco una frase per ricordartelo: “Tutti quelli che fanno diagnosi vengono dal Missouri”. Il motto ufficiale di questo stato degli USA è “Dimostramelo!” (coniato nel 1899, quando il rappresentante del Congresso Willard D. Vandiver disse: “Io vengo da una nazione che coltive mais e cotone e nappole [un tipo di pianta – N.d.T.] e Democratici, e la vuota eloquenza non mi convince né mi soddisfa. Io vengo dal Missouri. Dovete dimostrarmelo.”). Nel caso del diagnosta, non è una questione di scetticismo, quanto piuttosto un bisogno funzionale di vedere qualunque cosa accada il più possibile nello stesso modo in cui tu lo vedi, piuttosto che le tue congetture e riassunti. Dimostracelo.

⇑ Indice

Descrivi i sintomi del problema in ordine cronologico

Gli indizi più utili per capire qualcosa che è andato storto spesso stanno negli eventi immediatamente precedenti. Quindi, il tuo resoconto dovrebbe descrivere precisamente quello che hai fatto, e quello che hanno fatto la macchina e il software, per portare al malfunzionamento. Nel caso di processi da linea di comando, avere un registro della sessione (ad esempio usando il programma script) e citare una ventina di righe importanti è molto utile.

Se il programma che è saltato ha delle opzioni diagnostiche (ad esempio -v per “verbose”) [dettagliato – N.d.T.], cerca di selezionare le opzioni che aggiungono nella trascrizione informazioni utili per il debugging. Ricorda che di più non è necessariamente meglio: cerca di scegliere un livello di debug che informi piuttosto che affondare chi legge nell’immondizia.

Se il tuo resoconto finisce per essere lungo (più di quattro paragrafi), potrebbe essere utile dichiarare sinteticamente il problema all’inizio, e poi far seguire il racconto cronologico. In questo modo, gli hacker sapranno cosa cercare mentre leggono il tuo resoconto.

⇑ Indice

Descrivi l’obiettivo, non il passaggio

Se stai cercando un modo per fare qualcosa (al contrario del riportare un bug), incomincia col descrivere l’obiettivo. Solo dopo descrivi il particolare passaggio verso l’obiettivo, sul quale sei bloccato.

Spesso, le persone che necessitano supporto tecnico hanno un obiettivo di alto livello in mente e si bloccano su quello che pensano sia un particolare procedimento per arrivare all’obiettivo. Cercano aiuto sul quel passaggio, ma non capiscono che è il procedimento ad essere sbagliato. Superare queste convinzioni può richiedere un discreto sforzo.

  • Stupido:
    Come faccio a far accettare al selettore colori di FooDraw un valore esadecimale RGB?
  • Intelligente:
    Sto provando a sostituire la tavolozza di colori di un immagine con valori di mia scelta. Al momento l’unico metodo che vedo possibile è di modificare ogni singolo valore della tavolozza, ma non riesco a far accettare al selettore colori di FooDraw un valore esadecimale RGB.

La seconda versione è intelligente, perché permette una risposta che suggerisce uno strumento più indicato per lo scopo.

⇑ Indice

Non chiedere risposte private via mail

Gli hacker ritengono che la soluzione di un problema debba essere un processo pubblico e trasparente, durante il quale un primo tentativo di risposta può e deve essere corretto se qualcuno più esperto si accorge che è incompleto o scorretto. In più, chi aiuta ottiene parte del proprio riconoscimento per aver risposto dal fatto di essere visto come competente ed informato dai propri pari.

Quando richiedi una risposta privata, stai rovinando sia il processo che il riconoscimento. Non farlo. È una scelta di chi risponde se farlo privatamente – e se lo fa, di solito è perché pensa che la domanda sia troppo mal posta o ovvia per interessare anche agli altri.

C’è una limitata eccezione a questa regola. Se pensi che la domanda riceverà tante risposte molto simili tra loro, allora le parole magiche sono: “Rispondete via mail e riassumerò le risposte per il gruppo”. É gentile tentare di risparmiare alla mailing list o al newsgroup una valanga di risposte sostanzialmente identiche – ma devi mantenere la promessa di riassumere.

⇑ Indice

Sii esplicito nella tua domanda

Le domande indeterminate tendono ad essere percepite come a delle perdite di tempo indeterminate. Le persone presumibilmente più adatte a darti una risposta sono anche le più impegnate (se non altro perché si fanno carico della maggior parte del lavoro). Persone così sono allergiche alle perdite di tempo indeterminate, e quindi tendono ad essere allergiche alle domande indeterminate.

È più probabile che tu riceva una risposta utile se sei esplicito su cosa vuoi che faccia chi ti risponde (fornire indicazioni, mandare codice, verificare una patch, qualunque cosa). Questo concentrerà il loro sforzo e implicitamente porrà un limite superiore al tempo e all’energia che chi risponde deve dedicare ad aiutarti. E questo è bene.

Per capire il mondo in cui vivono gli esperti, pensa all’esperienza come ad una risorsa abbondante e al tempo come ad una risorsa scarsa. Minor impegno di tempo richiedi, più è probabile che tu abbia una risposta da qualcuno molto bravo e molto occupato.

Quindi è utile inquadrare la tua domanda per minimizzare l’impegno di tempo richiesto ad un esperto per rispondere – ma spesso non è la stessa cosa di semplificare la domanda stessa. Allora, per esempio, “Mi dareste un’indicazione per una buona spiegazione di X?” è di solito una domanda più intelligente di “Mi spieghereste X, per favore?”. Se hai del codice mal funzionante, è solitamente più intelligente chiedere a qualcuno di spiegare cosa c’è di sbagliato piuttosto che chiedere a qualcuno di correggerlo.

⇑ Indice

Chiedere righe di codice

Non chiedere agli altri di correggere il tuo codice non funzionante senza dare un suggerimento su che tipo di problema dovrebbero cercare. Includere qualche centinaio di linee di codice, dicendo “non funziona”, farà sì che ti ignorino. Includere una dozzina di righe, dicendo “dopo la linea 7 mi aspettavo di vedere <x>, invece è successo <y>” è più probabile che ti faccia avere una risposta.

Il modo più efficace per essere precisi riguardo a problemi di programmazione è di fornire un caso minimo di dimostrazione del bug. Che cos’è un caso di test minimo? É una descrizione del problema; solo il codice sufficiente a mostrare il comportamento indesiderato e niente più. Come costruire un caso di test minimo? Se sai quale riga o sezione del codice produce il comportamento problematico, fanne una copia e aggiungi codice di supporto quanto basta per produrre un esempio completo (ad es.: abbastanza affinché il sorgente sia accettato dal compilatore/interprete/qualunque programma lo elabori). Se non puoi restringere il campo ad una particolare sezione, fai una copia del sorgente e comincia a rimuovere i pezzi che non influenzano il comportamento problematico. Quanto più è ridotto il caso di test minimo, tanto meglio è (vedi la sezione “La quantità non è precisione“).

Generare un caso di test ridotto non sarà sempre possibile, ma provarci è una buona regola. Questo ti può aiutare a risolvere il problema da solo – e anche se non accade, agli hacker piace vedere che ci hai provato. Li renderà più cooperativi.

Se semplicemente vuoi una revisione del codice, chiedi quando basta, ed assicurati di menzionare quali aree tu pensi abbiano particolarmente bisogno di revisione e perché.

⇑ Indice

Non postare i compiti a casa

Gli hacker sono bravi ad individuare le domande dei “compiti a casa”; molti di noi li hanno fatti da sé. Queste domande sono fatte per far lavorare te, così che tu impari da quest’esperienza. Va bene chiedere suggerimenti, ma non l’intera soluzione.

Se sospetti che ti sia stata passata una domanda da “compiti a casa”, ma non riesci comunque a risolverla, prova a chiedere in un forum di utenti o (come ultima risorsa) in un forum/lista di utenti di un progetto. Mentre gli hacker riescono ad individuare queste domande, alcuni degli utenti esperti potrebbero per lo meno darti un’indicazione.

⇑ Indice

Limita le richieste superflue

Resisti alla tentazione di concludere la tua richiesta di aiuto con domande semanticamente nulle come “Qualcuno può rispondermi?” o “Esiste una risposta?”. Primo: se hai scritto la descrizione del problema in maniera mediamente competente, queste domande appiccicate sono quantomeno superflue. Secondo: poiché sono superflue, gli hacker le trovano fastidiose – e risponderanno in maniera logicamente impeccabile ma sprezzante: “Sì, puoi essere aiutato” e “No, non c’è aiuto per te”.

In generale, fare domande che comportano una risposta sì/no è una cosa da evitare, a meno che tu non voglia una risposta “sì/no”.

⇑ Indice

Non marcare la domanda come “Urgente”, anche se lo è

É un tuo problema, non nostro. Dichiarare l’urgenza è solitamente controproducente: molti hacker bolleranno questi messaggi come scortesi ed egoistici tentativi di attirare attenzione speciale ed immediata. inoltre la parola “Urgente!” (e altri modi simili di attirare l’attenzione con l’oggetto del messaggio) spesso fanno scattare i filtri anti-spam: i potenziali destinatari potrebbero perfino non vedere mai il messaggio!

C’è una semi-eccezione. Può valer la pena farlo presente se stai usando il programma in un posto di alto profilo, uno per il quale gli hacker si infervoreranno; in questo caso, se sei sotto pressione, e lo dici educatamente, qualcuno potrebbe interessarsi abbastanza da rispondere presto.

Questa è una cosa molto rischiosa da fare, ad ogni modo, perché il criterio degli hacker per cui qualcosa è eccitante probabilmente differisce dal tuo. Scrivere un messaggio dalla Stazione Spaziale Internazionale ti qualificherebbe, ad esempio, ma non altrettanto scrivere un messaggio per conto di un’organizzazione di beneficenza o politica. Di fatto, scrivere: “Urgente: per favore aiutatemi a salvare le piccole e soffici foche!” farà sì che anche gli hacker che ritengono le piccole e soffici foche importanti ti evitino o ti “brucino”.

Se trovi tutto questo misterioso, rileggi il resto di questo documento più e più volte finché non lo comprendi, prima di scrivere qualunque messaggio.

⇑ Indice

La cortesia non guasta mai, e qualche volta aiuta

Sii cortese. Usa “Per favore” e “Grazie per l’attenzione” o “Grazie per la considerazione”. Dimostra che apprezzi il tempo che le persone impiegano per aiutarti gratuitamente.

Ad essere onesti, questo non è così importante (e non sostituisce) come l’essere grammaticalmente corretto, chiaro, preciso e descrittivo, evitare i formati proprietari etc…; gli hacker in generale preferirebbero ricevere un resoconto di bug un po’ brusco ma tecnicamente preciso piuttosto che un’educata imprecisione. (Se questo ti lascia stupito, ricorda che noi valutiamo una domanda rispetto a ciò che ci insegna.)

Comunque, se hai tutti i dettagli messi bene in mostra, l’educazione aumenta le tue possibilità di ottenere una risposta utile.

(Faccio notare che l’unica obiezione seria che abbiamo ricevuto dagli hacker “veterani” su questo “HOWTO” riguarda la nostra precedente raccomandazione di usare “Grazie in anticipo”. Alcuni hanno la sensazione che questo denoti l’intenzione di non ringraziare nessuno dopo. La nostra raccomandazione è di dire “Grazie in anticipo” ed anche di ringraziare chi risponde dopo, o esprimere gentilezza in modo diverso, ad esempio dicendo “Grazie per l’attenzione” o “Grazie per la vostra considerazione”.)

⇑ Indice

Scrivi una breve nota sulla soluzione

Scrivi una nota dopo che il problema è stato risolto a tutti quelli che ti hanno aiutato; fai sapere loro il risultato e ringraziali ancora per il loro aiuto. Se il problema ha attirato l’attenzione generale della mailing list o del newsgroup, è appropriato inserire lì la conclusione.

Ancora meglio, la risposta dovrebbe essere aggiunta alla discussione iniziata dalla domanda originale, e dovrebbe avere “RIPARATO”, “RISOLTO” o un’etichetta ugualmente esplicativa nell’oggetto. Nelle mailing list con aggiornamenti rapidi, un potenziale corrispondente che vede una discussione su “Problema X” che termina con “Problema X – RISOLTO” sa di non sprecare il suo tempo a leggerla (a meno di non essere personalmente interessato/a al problema X) e può quindi usare quel tempo per risolvere un problema differente.

La tua conclusione non deve essere lunga e complicata; un semplice: “Hey – era un cavo di rete difettoso! Grazie a tutti. – Bill” sarebbe meglio di niente. Di fatto, un riassunto breve e piacevole è meglio di una lunga dissertazione a meno che la soluzione abbia una reale difficoltà tecnica. Di’ quale azione ha risolto il problema, senza tuttavia replicare l’intera sequenza di diagnosi del problema.

Per problemi di una certa complessità, è appropriato scrivere un riassunto della cronologia di diagnosi del problema. Descrivi il tuo resoconto finale del problema. Descrivi cosa ha funzionato per la soluzione, e indica i vicoli ciechi evitabili alla fine. I vicoli ciechi dovrebbero venire dopo la soluzione corretta ed altro materiale riassuntivo, piuttosto che trasformare la conclusione in una storia di spionaggio. Nomina le persone che ti hanno aiutato; in questo modo ti farai degli amici.

Oltre ad essere cortese ed informativo, questa sorta di conclusione aiuterà gli altri che cercano nell’archivio della mailing list/newsgroup/forum a sapere esattamente quale soluzione ha funzionato e quindi può funzionare anche per loro.

Infine, ma non meno importante, la conclusione dà a tutti quelli che hanno assistito la soddisfazione di percepire la chiusura del problema. Se non sei un tecnico o un hacker, fidati di noi che questa sensazione è molto importante per i guru e gli esperti che hai scomodato. Le descrizioni di problemi che si perdono in una nullità irrisolta sono frustranti; gli hacker scalpitano per vederli risolti. La benevolenza che ti guadagnerai sollevandoli da questo disagio sarà molto, molto utile la prossima volte che porrai una domanda.

Considera come puoi fare ad evitare ad altri lo stesso problema nel futuro. Chiediti se una correzione alla documentazione o alle FAQ aiuterebbe, e se la risposta è sì spedisci la correzione al responsabile.

Per gli hacker, questo tipo di buona abitudine alla conclusione è più importante che una convenzionale buona educazione. È il modo in cui ti crei una reputazione di collaborare bene con gli altri, il che può essere un patrimonio molto prezioso.

⇑ Indice

Come interpretare le risposte

RTFM e STFW: Come capire che hai commesso un errore

C’è una vecchia e sacra tradizione: se ricevi una risposta del tipo “RTFM” [Read The Fucking Manual: Leggi il fottuto manuale – N.d.T.], la persona che te l’ha spedita pensa che tu avresti dovuto leggere il fottuto manuale. Questa persona ha quasi certamente ragione. Vai a leggerlo.

RTFM ha un parente più giovane: se ricevi una risposta del tipo “STFW” [Search The Fucking Web: Cerca Nella Fottuta Rete – N.d.T.], la persona che l’ha spedita pensa che tu avresti dovuto Cercare Nella Fottuta Rete. Questa persona ha quasi certamente ragione. Fai una ricerca. (La versione più gentile di quest’espressione è “Google is your friend” [Google è tuo amico – N.d.T.].)

Nei forum, ti si potrebbe dire di cercare negli archivi. Peraltro, qualcuno potrebbe essere così gentile da fornirti anche un’indicazione alla precedente discussione in cui il problema è stato risolto. Ma non contare troppo su questa considerazione; fai la tua ricerca in archivio prima di chiedere.

Spesso, la persona che ti dice di cercare ha aperti davanti a sé il manuale o la pagina web con le informazioni che cerchi, e li guarda mentre scrive. Queste risposte significano che la persona pensa che (a) l’informazione che cerchi è molto facile da trovare, e (b) che imparerai di più se cerchi queste informazioni piuttosto che averle belle e pronte da parte di qualcun altro.

Non dovresti offenderti per questo; per gli standard degli hacker, il tuo corrispondente ti sta mostrando una rozza forma di rispetto semplicemente perché non ti ignora. Dovresti invece essere grato di questa gentilezza materna.

⇑ Indice

Se non capisci…

Se non capisci la risposta, non ritornare immediatamente con una richiesta di chiarimenti. Usa gli stessi strumenti che hai usato per cercare di rispondere alla domanda originale (manuali, FAQ, il Web, amici esperti) per capire la risposta. Poi, se ancora ne hai bisogno, chiedi un chiarimento mostrando quello che hai imparato.

Ad esempio, supponi che io ti dica: “Sembra che tu abbia uno zentry [parola di fantasia – N.d.T.] bloccato; dovrai sbloccarlo”. Ora: c’è una cattiva risposta: “Che cos’è uno zentry?” e c’è una buona risposta: “OK, ho letto il manuale e gli zentry sono elencati sotto le opzioni -z e -p. Non c’è niente a proposito dello sblocco degli zentry. È una di queste o c’è qualcosa che mi sfugge?”.

⇑ Indice

Rapportarsi con la scortesia

Molto di ciò che sembra scortesia negli ambienti hacker non intende essere offensivo. Piuttosto, è il prodotto dello stile di comunicazione diretta e senza inutili fronzoli che è naturale per le persone che sono più interessate a risolvere problemi piuttosto che far sentire gli altri a proprio agio e coccolati.

Quando percepisci scortesia, cerca di reagire con calma. Se qualcuno sta veramente esagerando, è probabile che un moderatore o un utente usuale del forum/mailing list/newsgroup lo richiamerà a proposito. Se questo non accade e perdi le staffe, magari la persona con cui ti sei arrabbiato stava agendo secondo le regole della comunità hacker e tu sarai considerato in difetto. Questo intaccherà le tue possibilità di ricevere le informazioni o l’aiuto che vuoi.

D’altro canto, ti capiterà occasionalmente di trovare scortesia o atteggiamenti sgradevoli gratuiti. L’altra faccia della medaglia delle considerazioni sopra dette, è che è accettabile il controbattere con veemenza alle persone realmente offensive, dissezionando il loro cattivo comportamento con un affilato bisturi verbale. Ad ogni modo sii molto, molto sicuro dei tuoi mezzi quando lo fai. Il confine tra correggere un’inciviltà ed iniziare un inutile battibecco è tanto sottile che non di rado gli stessi hacker la sorpassano; se sei un principiante o un visitatore casuale, le tue probabilità di evitare questo sconfinamento sono basse. Se cerchi informazioni più che divertimento, è meglio per te tenere le mani lontane dalla tastiera piuttosto che prenderti questo rischio.

(Alcune persone asseriscono che molti hacker hanno una debole forma di autismo o sindrome di Asperger, e mancano in effetti di alcuni normali schemi mentali che facilitano la “normale” interazione sociale umana. Ciò potrebbe essere vero o non vero. Se non sei tu stesso un hacker, pensare che noi abbiamo danni cerebrali può aiutarti a trattare con le nostre stravaganze. Fai pure. A noi non importa; a noi piace essere qualunque cosa noi siamo, e generalmente abbiamo un salutare scetticismo rispetto alle classificazioni cliniche.)

Anche le osservazioni di Jeff Bigler sui filtri del tatto sono interessanti e meritevoli di una lettura.

Nella prossima sezione parleremo di una questione differente: il tipo di “scortesia” che sperimenti quando sei tu a comportarti male.

⇑ Indice

Non reagire istericamente

Capiterà pure che qualche volta tu faccia una stupidaggine sui forum di una comunità hacker – nei modi elencati in quest’articolo, o simili. E ti verrà detto esattamente che stupidaggine hai fatto, probabilmente con colorite aggiunte. In pubblico.

Quando questo succede, la peggior cosa che puoi fare è di piagnucolare su questa esperienza, lamentarti di essere stato assalito verbalmente, richiedere scuse, urlare, trattenere il respiro, minacciare azioni legali, fare reclami ai datori di lavoro, lasciare alzata la tavoletta del water, etc. Invece, ecco cosa devi fare.

Lascia perdere. È normale. In effetti, è sano ed appropriato.

Gli standard della comunità non si mantengono da sé: si mantengono grazie a persone che li applicano attivamente, visibilmente, in pubblico. Non lamentarti che tutte le critiche avrebbero dovuto essere spedite in una mail privata: non è così che funziona. Non è neanche utile insistere sul fatto di essere stato personalmente insultato quando qualcuno commenta che una delle tue pretese è sbagliata, o che le sue opinioni divergono. Questi sono comportamenti da stupido [loser, nel testo originale – N.d.T.].

Ci sono stati forum hacker in cui, per un frainteso senso di iper-cortesia, i partecipanti venivano espulsi per aver scritto messaggi critici verso post altrui, con motivazioni del tipo: “Non dite niente se non avete intenzione di aiutare l’utente”. Il risultante abbandono da parte dei partecipanti più esperti rende questi forum pieni di chiacchiere senza senso ed inutili come forum tecnici.

Esageratamente “amichevoli” (in questo senso) o utili: scegline una.

Ricorda: quando un hacker ti dice che hai fatto una scemenza, e (non importa quanto aspramente) ti dice di non farlo più, lo sta facendo a ragion veduta per (1) te e (2) per la propria comunità. Sarebbe molto più facile per lui ignorarti ed escluderti dalla sua vita. Se non riesci ad esserne grato, almeno abbi un po’ di dignità, non piagnucolare, e non ti aspettare di essere trattato come una fragile bambolina solo perché sei l’ultimo arrivato con un animo drammaticamente ipersensibile e pretese di diritti.

A volte le persone ti attaccheranno personalmente, litigheranno senza ragione apparente, etc, anche se non commetti errori (o hai sbagliato solo nella loro immaginazione). In questo caso, lamentarti è il modo per fare davvero una sciocchezza.

Questi attaccabrighe sono o degli stupidi che non sanno nulla ma si credono esperti, o psicologi da quattro soldi che provano a vedere se sbagli. Gli altri lettori li ignorano o trovano da sé modi per averci a che fare. Il comportamento di questi “flamer” [chi crea dei “flame”, ossia delle discussioni accese ed inutili – N.d.T.] crea problemi a loro stessi, cosa che non deve interessarti.

Non farti neanche trascinare in una di queste inutili guerre. È meglio ignorare la maggior parte di questi “flame” – dopo aver controllato se lo sono davvero, e non piuttosto indicazioni sul modo in cui hai sbagliato o risposte abilmente cifrate alla tua reale domanda (anche questo può succedere).

⇑ Indice

Domande da non fare

Ecco alcune classiche domande stupide, e ciò che gli hacker pensano quando non gli danno risposta.

D: Dove posso trovare il programma o la risorsa X?
R: Nello stesso posto dove la troverei io, stupido – tramite una ricerca sul web. Oddio, qualcuno ancora non sa come usare Google?

D: Come posso usare X per fare Y?
R: Se vuoi fare Y, dovresti fare questa domanda senza presupporre l’uso di un metodo che potrebbe non essere appropriato. Domande in questa forma denotano persone che non sono semplicemente ignoranti in materia, ma confuse rispetto a che problema Y stanno risolvendo e troppo fissate sui dettagli della specifica situazione. É generalmente meglio ignorare queste persone finché non definiscono meglio il problema.

D: Come posso configurare il mio prompt dei comandi?
R: Se sei abbastanza esperto da fare questa domanda, sei abbastanza esperto da “RTFM” e capirlo da solo.

D: Posso convertire un documento AcmeCorp in un file TeX usando il convertitore Bass-o-matic?
R: Prova e vedi. Se ci riesci, avrai (a) imparato la risposta e (b) smesso di farmi perdere tempo.

D: Il mio {programma, configurazione, richiesta SQL} non funziona
R: Questa non è una domanda, ed io non sono interessato a giocare a Twenty Questions [gioco in cui si tenta di indovinare un oggetto tramite non più di 20 domande – N.d.T.] per tirarti fuori la vera domanda – ho cose migliori da fare. Vedendo una cosa del genere, la mia reazione è normalmente una delle seguenti:

  • Hai qualcos’altro da aggiungere?
  • Oh, che peccato, spero che tu lo risolva
  • E questo esattamente cosa ha a che fare con me?

D: Sto avendo problemi con la mia macchina Windows. Potete aiutarmi?
R: Sì, butta quella spazzatura Microsoft e installa un sistema operativo open-source come Linux o BSD. Nota: tu puoi fare domande relative a macchine Windows se riguardano programmi che hanno una versione ufficiale per Windows, o interagiscono con Windows (ad esempio Samba). Semplicemente non essere sorpreso dalla risposta che il problema è in Windows e non nel programma, perché Windows in genere è messo così male che questo è molto spesso il caso.

D: Il mio programma non funziona. Penso che l’utility di sistema X sia danneggiata.
R: Mentre è possibile che tu sia la prima persona ad accorgerti di una ovvia mancanza in chiamate di sistema e librerie intensamente usate da centinaia o migliaia di persone, è piuttosto più probabile che tu sia completamente fuori strada. Dichiarazioni straordinarie richiedono prove straordinarie; quando fai un’affermazione del genere, devi supportarla con documentazione chiara ed esaustiva sulle condizioni di errore.

D: Sto avendo problemi ad installare Linux o X. Mi potete aiutare?
R: No, avrei bisogno di accesso fisico alla tua macchina per diagnosticare il problema. Chiedi al tuo gruppo utenti Linux [LUG: Linux User Groups – N.d.T.] per aiuto sul posto. Puoi trovare una lista di gruppi utenti qui.
Nota: le domande sull’installazione di Linux possono essere appropriate se sei su un forum o una mailing list di una specifica distribuzione, ed il problema è con quella “distro”, oppure sui forum di un LUG. In questo caso, assicurati di descrivere i dettagli esatti del malfunzionamento. Ma fai una accurata ricerca prima, usando come parole chiave “linux” e tutti i componenti hardware sospetti.

D: Come posso craccare l’utente root / rubare i privilegi di channel-op / leggere la posta di qualcuno?
R: Sei un poveraccio a voler fare questo tipo di cose e un cretino a chiedere ad un hacker di aiutarti a farlo.

⇑ Indice

Domande buone e cattive

In conclusione, illustrerò come porre domande in modo intelligente con un esempio; coppie di domande sullo stesso problema, una posta in modo stupido e l’altra in modo intelligente.

Stupido: Dove posso trovare informazioni sul Foonly Flurbamatic [parole inventate – N.d.T.]?

Questa domanda semplicemente prega di ricevere un “STFW” in risposta.

Intelligente: Ho usato Google per cercare informazioni su “Foonly Flurbamatic 2600” in Rete, ma non ho avuto risultati utili. Mi date un’indicazione su dove trovare informazioni per la programmazione di questo dispositivo?

A questo qui è già stato detto di “STFW”, e sembra che abbia un vero problema.

Stupido: Non riesco a compilare il codice del progetto. Perché è difettoso?

Il richiedente assume che qualcun altro abbia sbagliato. Tipo arrogante..

Intelligente: Il codice del progetto “foo” non si compila sotto Nulix versione 6.2. Ho letto le FAQ, ma non contengono nulla sui problemi legati a Nulix. Questa è una trascrizione del mio tentativo di compilazione; è qualcosa che ho fatto io?

Il richiedente ha specificato l’ambiente, ha letto le FAQ, sta mostrando l’errore e non sta presupponendo che i suoi problemi siano colpa di qualcun altro. Potrebbe essere degno di attenzione.

Stupido: Sto avendo un problema con la mia scheda madre. Qualcuno mi può aiutare?

La risposta di J. Random Hacker a questo sarà presumibilmente: “Va bene, hai bisogno anche che ti faccia fare il ruttino e ti cambi il pannolino?”, seguito da un colpo sul tasto di cancellazione.

Intelligente: Ho provato X, Y e Z sulla scheda madre S2464. Quando questo non ha funzionato, ho provato A, B e C. Notate il curioso sintomo quando ho provato C. Ovviamente il coso sta cosando [“the florbish is grommicking” – parole inventate – N.d.T.], ma i risultati non sono quelli che mi aspettavo. Quali sono le cause comuni di cosamento su una scheda madre Athlon MP? Qualcuno ha idee di ulteriori test che posso fare per individuare il problema?

Questa persona, al contrario, sembra degna di risposta. Ha mostrato propensione alla soluzione dei problemi piuttosto che attendere passivamente che una risposta gli cada dal cielo.

Nell’ultima domanda, nota la sottile ma importante differenza tra il chiedere “Datemi una risposta” e “Per favore, aiutatemi a capire quali prove aggiuntive posso fare per chiarirmi le idee”.

In effetti, la forma dell’ultima domanda è strettamente basata su un reale problema che ho avuto ad Agosto 2001, discusso sulla mailing list del kernel linux (lkml). Io (Eric) ero quello che faceva le domande in quel momento. Vedevo misteriosi blocchi su una scheda madre Tyan S2462. I membri della lista hanno fornito le informazioni critiche di cui avevo bisogno per risolverli.

Ponendo le domande nel modo in cui ho fatto io, ho dato alle persone qualcosa su cui rimuginare; ho reso semplice ed invitante essere coinvolti. Ho mostrato rispetto per le capacità dei miei pari e li ho invitati a rapportarsi a me come tale. Ho anche mostrato rispetto per il valore del loro tempo elencando i vicoli ciechi in cui ero già incorso.

Alla fine, quando ho ringraziato tutti e rimarcato quanto aveva funzionato bene il processo, un membro di lkml ha commentato che la cosa aveva funzionato non perché io sono un “nome” su quella lista, ma perché ho fatto le domande nel modo giusto.

Gli hacker sono in qualche modo una meritocrazia spietata; sono certo che questa persona avesse ragione e che, se mi fossi comportato come una spugna, sarei stato attaccato o ignorato, chiunque io fossi. Il suo suggerimento di descrivere tutto l’episodio come esempio per gli altri ha portato direttamente alla scrittura di questa guida.

⇑ Indice

Se non ottieni una risposta

Se non ottieni una risposta, per favore non prenderla sul personale come se noi sentissimo di non poterti aiutare. Qualche volta i membri del gruppo a cui si chiede semplicemente non conoscono la risposta. Nessuna risposta non è lo stesso di essere ignorati, sebbene sia dichiaratamente difficile comprendere la differenza dall’esterno.

In generale, inviare nuovamente la domanda è una cattiva idea. Questo verrà visto come inutilmente fastidioso. Abbi pazienza: la persona con la tua risposta può stare dormendo, in un posto del mondo con un diverso fuso orario. O forse la tua domanda non era abbastanza ben posta, tanto per cominciare.

Ci sono altre fonti d’aiuto a cui puoi rivolgerti, spesso più consone alle necessità di un principiante.

Ci sono molti gruppi di utenti online e locali che sono appassionati di software, anche se potrebbero non aver mai scritto loro stessi un programma. Questi gruppi spesso sono costituiti in modo che le persone si possano aiutare reciprocamente e possano aiutare i nuovi utenti.

Ci sono anche tantissime aziende commerciali con cui puoi fare un contratto di assistenza, sia grandi che piccole. Non essere turbato dall’idea di dover pagare in cambio di un po’ d’aiuto! Dopo tutto, se si bruciasse una guarnizione del motore della macchina, la porteresti probabilmente in officina e pagheresti per farla riparare. Anche se il software non ti è costato nulla, non puoi aspettarti che il supporto sia sempre gratuito.

Per software popolari come Linux, ci sono almeno 10,000 utenti per ogni sviluppatore. È semplicemente impossibile per una sola persona gestire le richieste di supporto da oltre 10,000 utenti. Ricorda che anche se devi pagare il supporto, la spesa è comunque molto più bassa di quella che avresti dovuto sostenere anche per acquistare il software stesso (e il supporto per il software proprietario è normalmente più costoso e meno competente rispetto al supporto per il software open-source).

⇑ Indice

Come rispondere in modo utile

Sii gentile. Lo stress legato ai problemi può far sembrare le persone scortesi o stupide anche se non lo sono.

Rispondi in privato a chi sbaglia per la prima volta. Non c’è bisogno di umiliazione pubblica per qualcuno che potrebbe aver fatto un errore in buona fede. Un vero principiante può non sapere come cercare negli archivi o dove sono elencate le FAQ.

Se non lo sai per certo, dillo! Dare un risposta sbagliata ma che suoni autorevole è peggio che non darne affatto. Non spingere nessuno su un percorso sbagliato semplicemente perché è divertente sembrare un esperto. Sii umile e onesto; dai il buon esempio sia a chi chiede che ai tuoi pari.

Se non puoi aiutare, non intralciare. Non fare battute sulle procedure che potrebbero rovinare la configurazione dell’utente – il poveretto potrebbe interpretarle come istruzioni.

Fai domande mirate per richiedere più dettagli. Se sei bravo in questo, chi chiede imparerà qualcosa – e potresti farlo anche tu. Cerca di trasformare le domande cattive in buone; ricorda che, una volta, siamo stati tutti principianti. Seppure brontolare “RTFM” sia qualche volta giustificato quando si risponde a qualcuno che è solo un pigrone, un’indicazione alla documentazione (anche solo un suggerimento della frase di ricerca su Google) è meglio.

Se dai una risposta, fallo per bene. Non suggerire rimedi approssimativi quando qualcuno sta usando lo strumento o l’approccio sbagliato. Suggerisci buoni strumenti. Inquadra diversamente la domanda.

Rispondi alla vera domanda! Se il richiedente è stato così scrupoloso da fare le proprie ricerche ed ha specificato nella richiesta di aver già provato X, Y, Z, A, B, e C senza successo, è estremamente inutile rispondere con “Prova A o B” o con un link a qualcosa che dice solo “Prova X, Y, Z, A, B o C..

Aiuta la comunità ad imparare dalla domanda. Quando discuti su una buona domanda, chiediti: “Come dovrebbe cambiare la relativa documentazione o le FAQ in modo che nessuno debba più rispondere a questa domanda?”. Quindi manda una correzione al responsabile del documento.

Se hai fatto ricerche per rispondere alla domanda, dimostra le tue abilità piuttosto che scrivere come se avessi tirato fuori la risposta dal cilindro. Rispondere ad una buona domanda è come servire ad un affamato un buon pasto, ma insegnargli come cercare grazie al tuo esempio è come insegnargli a coltivare il proprio cibo per tutta la vita.

⇑ Indice

Risorse collegate

Se necessiti di istruzioni di base su come funzionano i computer, Unix e Internet, vedi The Unix and Internet Fundamentals HOWTO.

Quando rilasci software o scrivi correzioni per il software, cerca di seguire le linee guida nella Software Release Practice HOWTO.

⇑ Indice

Riconoscimenti

Evelyn Mitchell ha contribuito con alcuni esempi di domande stupide ed ha ispirato la sezione “Come rispondere in modo utile”. Mikhail Ramendik ha contribuito con alcuni suggerimenti particolarmente preziosi per i miglioramenti.

⇑ Indice

Annunci