Menu Chiudi

Domande Intelligenti

Come porre domande in maniera furba e intelligente

Autore: Eric S.

Come porre domande in maniera furba e intelligente

Autore: Eric S. Raymond
Originale: http://www.catb.org/~esr/faqs/smart-questions.html
Traduzione: Maurizio Loreti [1] e Lele Gaifax [2]

Prefazione all’edizione in italiano

Alcuni termini in lingua inglese, ma largamente compresi, come ad esempio hacker (qui usato nel suo significato originale 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 utonto.

Introduzione

Nel mondo degli hacker 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.

Ora che l’uso del software libero si è diffuso, spesso si può ottenere risposte da altri utenti più esperti, oltre che dagli hacker. È una Cosa Buona e Giusta: gli utenti hanno la tendenza a essere un tantino più tolleranti verso gli errori tipicamente commessi dai neofiti. Comunque, usare lo stesso riguardo verso gli utenti esperti di quello usato per gli hacker nella modalità raccomandata qui è comunque la maniera più efficace per ottenere risposte soddisfacenti.

La prima cosa da capire è che agli hacker 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 hacker, dire “Questa è una buona domanda!” equivale a fare un complimento sincero ed importante.

A dispetto di quanto ora detto, però, gli hacker 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 siamo 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 nulla 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 utonti [3].

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 utonto 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 prostrino davanti, in effetti la maggior parte di noi non chiederebbe di meglio che dialogare con tutti quanti alla pari e dar loro il benvenuto nel nostro universo culturale, se solo gli altri facessero un piccolo sforzo per renderlo possibile. Semplicemente, non è remunerativo cercare di aiutare chi mostra di non saper fare lui stesso un piccolo sforzo. Essere ignoranti va bene; fare gli stupidi, no.

Insomma, mentre non è necessario essere già tecnicamente competenti per ottenere la nostra attenzione, è necessario dimostrare l’attitudine che porta alla competenza, attenzione, ponderazione, osservazione, disponibilità ad assumere un ruolo attivo nello sviluppo della soluzione. 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 hacker di regalarvi quello stesso aiuto per favore.

Se decidete di chiederci qualcosa, cercate di non comportarvi da utonti; il modo migliore di ottenere risposte rapide e complete è di fare domande a modo, da persona furba, consapevole e che conosce la materia, a cui capita di aver bisogno di un aiuto su un particolare problema.

Nota

Suggerimenti per migliorare questa guida sono i benvenuti. Mandateli a Eric S. Raymond; 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 e-mail o in un newsgroup o su una chat qualificata, dovete:

  1. Cercare di trovare una risposta cercando sul Web.
  2. Cercare di trovare una risposta leggendo il manuale.
  3. Cercare di trovare una risposta leggendo una FAQ
  4. Cercare di trovare una risposta ispezionando e sperimentando.
  5. Cercare di trovare una risposta chiedendo a un amico di talento.
  6. Se sei un programmatore, cerca di trovare la risposta leggendo il codice sorgente.

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.

Tentate la strada di cercare su Google il testo dell’errore che avete ottenuto (e cercate anche sui gruppi con Google, oltre che sulle pagine web). Questo spesso vi porta direttamente a documentazione aggiornata, oppure a un thread su una mailing list che risolve il vostro problema. Anche se così non fosse, dire “Ho cercato con goggle la seguente frase ma non ho trovato nulla di interessante” è una buona cosa da inserire nella mail o nella news di richiesta d’aiuto.

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 letterale 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; dopo tutto, non state mica pagando un servizio. Vi guadagnerete una risposta, se la otterete, ponendo una domanda interessante, circostanziata ed intellettualmente stimolante, una domanda che implicitamente dia un contributo alla comunità invece di richiedere passivamente conoscenza dagli altri.

Inversamente, il sottolineare che siete capaci e volete contribuire al processo dello sviluppo di una soluzione è un buon punto di partenza. “Potete darmi uno spunto?”, “Cosa non va 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 dove inviare la domanda

Siate giudiziosi nello scegliere in che sede proporre la vostra domanda; probabilmente sarete ignorati o, comunque, catalogati come utonti, 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 newsgroup differenti;
  • inviate un messaggio personale a qualcuno che non vi conosce né è personalmente responsabile della risoluzione del problema.

Gli hacker ignorano domande fatte in una sede inopportuna, 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.

Il primo passo, quindi, è trovare il giusto forum. Ancora una volta, Google e altri sistemi di ricerca sul web possono fornirti un valido aiuto: usali se non altro per trovare le pagine web del progetto più affini al tuo problema, hardware o software che sia. In genere trovi dei riferimenti a una raccolta di FAQ (Frequently Asked Questions, domande poste di frequente), oltre che alle mailing list del progetto e ai rispettivi archivi storici, che sono di fatto l’ultima risorsa a cui affidarsi, quando gli altri sforzi (incluso leggere le FAQ che avete trovato) non producono una soluzione valida.

Talvolta però spedire una mail a una persona o a un forum che non conoscete può essere rischioso. Ad esempio, non assumete che l’autore di una pagina web informativa desideri farvi da consulente gratuitamente. Non siate troppo ottimisti nel valutare se la vostra mail sarà bene accolta; se non siete sicuri, speditela altrove, o non speditela affatto.

Nella selezione del forum, newsgroup o mailing list, non fidatevi troppo del nome del progetto; date un’occhiata alle FAQ o ai suoi obbiettivi, per assicurarsi che il vostro messaggio non finisca nel posto sbagliato. Leggete magari un po’ del traffico recente prima di spedire il vostro messaggio, giusto per farsi un’idea di come siano gestite le cose. In effetti è una buona idea quella di fare una ricerca sulle parole chiave relative al problema da risolvere sul newsgroup o nella mailing list prima di spedirvi un messaggio. Potrebbe portarvi una soluzione, o comunque aiutarvi a formulare meglio la domanda.

Delineate con cura l’argomento! Uno degli errori classici è chiedere informazioni sull’interfaccia di programmazione di Unix o Windows in un forum dedicato a un linguaggio o a una libreria portabile in entrambi gli ambienti. Se non comprendete il motivo per cui questo un errore grossolano, è molto meglio che vi asteniate dal chiedere qualsiasi cosa finché non ci arrivate.

In generale, le domande rivolte ad un ambiente pubblico attentamente selezionato 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 hacker 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).

Comprensibilmente, gli hacker più noti e gli autori di software molto popolari ricevono già un considerevole volume di messaggi “a sproposito”. Aggiungendone altri, in casi estremi potreste essere la goccia che fa traboccare il vaso: non sarebbe la prima volta che un contributore a un progetto disdice il suo impegno a causa degli effetti collaterali che un inutile traffico email provoca al proprio account personale, rendendolo inutilizzabile.

Il Web e i forum su IRC dedicati ai neofiti di solito sono più veloci a rispondere

Il gruppo locale di utenti Linux, o la distribuzione che usate, potrebbe suggerire l’utilizzo di un determinato forum Web, oppure un canale IRC o una mailing list dove i neofiti possono trovare aiuto. Si tratta di un punto di inizio ottimale, specialmente se pensate di essere incappati in un problema relativamente semplice o comune. Un riferimento a un canale IRC è da considerare come un invito a porre là le proprie domande, spesso ottenendo risposte in tempo reale.

Qualora il programma che vi sta dando grattacapi sia parte di una distribuzione (cosa molto comune al giorno d’oggi), può essere meglio chiedere nel forum/lista dedicata alla particolare distro prima di provare quella specifica del progetto, dove potreste ottenere “Usa una versione compilata da te” come risposta.

Prima di porre il problema su un qualsiasi forum Web, verificate la presenza di una funzione di ricerca. Se è presente, provate a farne un paio cercando qualche cosa che abbia a che fare col vostro problema: potrebbe già darvi la risposta che volete. Se avete già svolto delle ricerche generiche sul Web (come avreste dovuto), ripetetele comunque all’interno del forum: il motore di ricerca usato potrebbe non avere indicizzato di recente tutto il forum.

C’è una tendenza sempre maggiore, nei progetti, a offrire il supporto agli utenti tramite un forum Web o su un canale IRC, mentre la mail viene riservata allo sviluppo del progetto. Consultate quindi questi canali per primi quando cercate informazioni specifiche a un certo progetto.

Secondo passo, usate la mailing list del progetto

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 sì, usatela. Ci sono diverse buone ragioni per farlo:

  • 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 leader del progetto) può essere troppo occupato per dedicarvi il suo tempo;
  • quasi tutte le mailing list 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;

Quando un progetto offre sia di una mailing list o di un forum Web “utenti” che di una “sviluppo”, e non state intervenendo sul codice, usate la lista/forum dedicata agli utenti. Non assumete di essere i benvenuti sulla lista degli sviluppatori, dove probabilmente i vostri problemi sarebbero visti come una distrazione.

Però, se siete sicuri che il problema non è banale, e non avete ottenuto una risposta esauriente dalla lista utenti, provate con quella dedicata agli sviluppatori. Ancora una volta è consigliato rimanere in ascolto [4] per alcuni giorni prima di spedire il proprio messaggio, imparando le usanze locali (di fatto si tratta di un buon approccio a qualsiasi lista privata o semi privata).

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 e-mail venga forwardata ad altre persone (la maggioranza, su Internet, pensa che le e-mail 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).

Specificate un Oggetto esplicativo

L’header “Subject:” nelle mailing list o nei newsgroup è 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!!!!”: i messaggi con questo oggetto 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 e precisa, del vostro problema.

Una buona convenzione per scrivere l’oggetto dei messaggi, usato da molte organizzazioni di supporto tecnico, è “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.

Utonto
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 MV100
Più furbo
XFree86 4.1, scheda Fooware MV1005 – cursore del mouse errato.

Usando lo schema “oggetto – malfunzionamento” per descrivere il problema, vi sarà più facile organizzare le idee e analizzare il problema in maggiore dettaglio. Cosa non si comporta secondo le vostre aspettative? Solo il cursore del mouse o qualcos’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, fin dalla 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: nuovo bug” difficilmente attrae qualcuno; inoltre, quotate dal vecchio thread solo il minimo che è necessario per introdurre il nuovo argomento.

Non spedite una semplice replica a un messaggio per introdurre un nuovo thread. Questo limita il numero di ascoltatori. Alcuni programmi per leggere la posta, come mutt, consentono di ordinare i messaggi per thread per poi nasconderli raggruppando il thread stesso. Le persone che fanno così non vedranno mai il vostro messaggio.

Cambiare l’oggetto non è sufficiente. Mutt, e probabilmente altri programmi, usano altre informazioni nell’intestazione del messaggio per assegnarlo a un determinato thread, non usano l’oggetto del messaggio. Create invece un messaggio completamente nuovo.

Nei forum Web le regole sono leggermente diverse, dal momento che in genere i messaggi sono maggiormente legati a specifici thread di discussione e spesso non visibili all’infuori di essi. Cambiare l’oggetto chiedendo informazioni in una risposta non è essenziale (non tutti i forum prevedono un oggetto diverso per le singole repliche, e praticamente nessuno li legge, quando è possibile). Ma chiedere informazioni in una replica è comunque una pratica da scoraggiare, dal momento che verrà notata solo da chi sta seguendo quel particolare thread. Così, a meno che non vogliate espressamente chiedere alle persone correntemente attive nel thread, iniziatene uno nuovo.

Rendete facile il rispondervi

Concludendo la vostra richiesta di informazioni con un “Per favore, spedite le risposte a…” rende assai improbabile l’ottenere una risposta. Se non spendi i pochi secondi necessari a impostare correttamente l’header Reply-To del programma di posta che usi, noi non passeremo neanche un secondo a pensare una soluzione al tuo problema. Se il programma di posta che usi non lo consente, trova un programma migliore. Se il tuo sistema operativo non supporta nessuno dei programmi che lo consentono, trova un sistema operativo migliore.

Nei forum Web, chiedere una risposta via email è oltremodo rude, a meno ché le informazioni che richiedi siano confidenziali (e qualcuno, per qualsiasi ragione, te lo farà sapere tenendo all’oscuro il resto dei partecipanti al forum). Se vuoi ottenere una mail quando qualcuno risponde al thread, richiedi al programma che gestisce il forum di inoltrarti le risposte; questa funzionalità è supportata dovunque, solitamente con una opzione tipo watch this thread, o send email on answers, ecc.

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

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 (in genere gli hacker sanno cogliere la differenza). A meno che non sappiate con precisione qual è 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);
  • gli allegati 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 mailer 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 presupporre che un hacker debba essere in grado di leggere un attachment in un formato proprietario come, ad esempio, Microsoft Word o Excel. L’hacker tipico reagisce a questo come ad un vero e proprio affronto e si comporta esattamente come fareste voi se qualcuno avesse nottetempo scaricato un camion di letame fumante sulla vostra soglia di casa;
  • se inviate il messaggio da una macchina Windows, disabilitate le stupide “Smart Quotes” Microsoft. Eviterete così di disseminare caratteri-spazzatura nel testo del messaggio;
  • nei forum Web, non abusate delle faccine e delle funzionalità HTML (quando sono presenti). Una faccina o due sono bene accettate, mentre un testo colorato e artistico fa pensare a un incapace. Abusando di faccine, colori e font di caratteri vi farà passare per petulanti ragazzine, che generalmente non è una buona cosa, a meno che non siate più interessati al sesso che alle risposte.

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

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). Fornite le generalità e la versione della distribuzione che usate (esempio, “Fedora Core 1”, “Slackware 9.1”, ecc).
  • Parlate di quello che avete fatto per capire e risolvere il problema prima di chiedere aiuto.
  • Elencate i passi compiuti per isolare e riconoscere 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 Come riportare efficacemente i bug, 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 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.

Non sostenete di aver trovato un bug

Quando incontrate dei problemi con un pezzo di software, non affermate subito di aver trovato un bug se non siete molto, molto sicuri del fatto vostro. Suggerimento: a meno che non forniate una patch al sorgente che corregga il problema, o un regression test che dimostra il comportamento scorretto, probabilmente non siete abbastanza sicuri.

Tenete presente che ci sono molti altri utenti che non hanno riscontrato il vostro problema. Altrimenti ne avreste sentito nominare o nella documentazione o nei risultati della ricerca sul Web (che avete effettuato, prima di lamentarvi, giusto?). Questo significa che molto probabilmente siete voi a sbagliare qualche cosa, non il software.

Le persone che hanno scritto il software hanno lavorato sodo per farlo funzionare al meglio. Dicendo di aver trovato un bug, sottintendete che hanno fatto qualche cosa di sbagliato, cosa che generalmente li offende, anche quando siete nel giusto. È particolarmente poco diplomatico esordire con un “Bug” nell’oggetto del messaggio.

Quando chiedete informazioni, è meglio scrivere come se foste convinti di sbagliare qualche cosa, anche quando, privatamente, siete abbastanza sicuri di aver effettivamente trovato un bug. Se si tratta di un bug reale, ne sentirete parlare nella risposta. Giocate le vostre carte in modo tale che sia il manutentore a chiedervi scusa, una volta dimostrata l’anomalia, piuttosto che esser voi a doverlo fare perché avete commesso qualche errore.

Il prostrarsi non può sostituire il lavoro di ricerca

Alcune persone che hanno compreso che non si dovrebbe comportarsi in maniera rude o arrogante, pretendendo una risposta, passano all’estremo opposto, alla protrazione. So di non esser altro che un patetico utonto neofita, ma…. Si tratta di una distrazione e non è di aiuto, particolarmente noiosa quando si accompagna a indicazioni troppo vaghe sul problema in sè.

Non sprecare il tuo tempo, o il nostro, on crude primate politics. Cerca invece di presentare i fatti basilari e le tue domande nella maniera più chiara che puoi. Questo è un modo migliore per introdurti al gruppo, piuttosto che piagnucolare.

Certe volte i forum Web prevedono un posto specifico per le domande dei neofiti. Se credi di dover fare una domanda del genere, falla là. Ma non ti commiserare nemmeno lì.

Descrivete i sintomi, non quello che ne pensate

Non serve a nulla dire agli hacker che cosa, secondo voi, causa il vostro problema; 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.

Utonto
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

Descrivete gli obbiettivi, non i passaggi

Se state cercando di capire come fare qualche cosa (piuttosto che notificando un’anomalia), cominciate col indicare dove volete arrivare. Solo successivamente, descrivete i passaggi per arrivare là che non siete riusciti a superare.

Spesso, le persone che necessitano di un aiuto tecnico hanno a grandi linee in mente l’obiettivo ma si bloccano su qualche passaggio di quel che ritengono il percorso da seguire per arrivarci. Allora chiedono aiuto su quel passaggio particolare, senza realizzare che è il percorso, a essere sbagliato. A volte, superare questo impasse può richiedere molto tempo.

Utonto
Come posso far sì che il selettore dei colori del programma FooDraw accetti un valore RGB esadecimale?
Furbo
Sto cercando di sostituire la tabella dei colori di una immagine con dei valori scelti da me. Finora, l’unico modo per farlo che mi è venuto in mente è di modificare ciascun elemento della tabella, ma non riesco a impostare il colore inserendo il valore RGB in esadecimale.

La seconda versione della domanda è più furba. Consente a chi risponde di suggerire uno strumento migliore per ottenere il medesimo risultato.

Non chiedete di rispondervi privatamente

Gli hacker 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; infine, gli hacker ricevono una sorta di ricompensa alla fatica di risolvere un problema: l’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 e-mail 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; dovete però 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 hacker 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 hacker sono bravissimi nel capire che una certa domanda è in realtà l’esercizio di un compito a casa; 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 hacker odiano le cose superflue — ed è possibilissimo che riceviate delle risposte dalla logica impeccabile, ma altrettanto superflue — tipo “Sì, io potrei aiutarti”.

In generale, porre delle domande “si/no” è una cosa da evitare, a meno di non voler ottenere una risposta “si/no”.

Non marcate la vostra domanda come Urgente, nemmeno se per voi lo è davvero

Quelli sono affari tuoi, non nostri. Chiedere un aiuto urgente è controproducente: la maggior parte degli hacker 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 hacker 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 hacker 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’e-mail.

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. Thread su problemi effettivi che alla fine terminano nel nulla lasciano invece un senso di frustrazione, una specie di prurito che tormenta ognuno degli hacker 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 hacker 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 utonto (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 hacker 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 e 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 utonto, peggiorando così 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 hacker 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 hacker 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 hacker, 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 utonto

Le leggi della probabilità garantiscono che, nelle prime uscite verso la comunità degli hacker, 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 e-mail: 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 utonto.

Sono esistiti dei luoghi di incontro di hacker, 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 hacker quando non rispondono loro.

Domanda
Dove posso trovare il programma o la risorsa X?
Risposta
Nello stesso posto dove la troverei io, scemo: facendo una ricerca sul Web. Diamine, c’è ancora qualcuno che non sa usare Google?
Domanda
Come posso usare X per fare Y?
Risposta
Se quello che vuoi fare è Y, dovresti porre la questione senza presupporre l’utilizzo di un metodo inappropriato. Questo tipo di domande indicano generalmente una persona che non solo è ignorante su X, ma è anche confusa su quale effettivamente sia il problema Y e troppo fissata sul dettaglio della sua particolare situazione. È meglio, in genere, ignorare queste persone finché non abbiano definito meglio il loro problema.
Domanda
Come posso configurare il prompt della mia shell?
Risposta
Se sei abbastanza sveglio per porre questa domanda, lo sei anche per RTFM e trovare da solo la risposta.
Domanda
È possibile convertire un documento AcmeCorp in un file TeX usando il convertitore Bass-o-matic?
Risposta
Prova e verifica. Se l’avessi fatto, a) avresti imparato qualche cosa e b) non mi avresti fatto perder tempo.
Domanda
il mio programma (o la mia configurazione o 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. Quando vedo questo genere di domande, di solito reagisco in un dei seguenti modi:

  • 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

sì. Butta nel cesso quella merda ed installa un sistema decente come Linux o Open BSD.

Nota

potete porre delle domande relative a macchine Windows, se si tratta di programmi ufficialmente supportati su quell’architettura o che interagiscono con macchine di quel tipo (come Samba, ad esempio), ma non meravigliatevi che chi vi risponde sostenga che si tratta di un problema di Windows e non del programma stesso, perché Windows è talmente bacato che molto spesso è proprio così.

Domanda
Il mio programma non funziona. Ho l’impressione che la funzionalità X del sistema sia bacata.
Risposta
Sebbene sia possibile che tu sia la prima persona a notare un errore così evidente in chiamate di sistema e librerie usate da centinaia o migliaia di persone, è più ragionevole ritenere che ti stia sbagliando. Affermazioni straordinarie devono essere supportate da fatti altrettanti straordinari; quando fai questo genere di uscite, devi produrre una documentazione chiara ed esaustiva che dimostri l’anomalia.
Domanda
Ho problemi nell’installare Linux (o il programma X o …). Potete aiutarmi?
Risposta

No. Dovrei poter mettere le mani sulla tua macchina. Rivolgiti al gruppo di utenti linux (LUG = Local User Group) più vicino. (Qui puoi trovare una lista degli user group conosciuti).

Nota

le domande sull’installazione di Linux possono essere appropriate in un forum o mailing list dedicata a una distro particolare, e il problema è con quella distro; oppure sul forum del locale gruppo di utenti Linux. In questo caso, assicurati di descrivere accuratamente il problema, ma solo dopo attente ricerche, cercando “linux” più il nome di tutti i componenti hardware sospetti.

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 domandare a un hacker di aiutarti a farlo.

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.

Utonto

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 un’indicazione su dove guardare per trovare informazioni sull’uso di questo device?

Chi domanda ha già indagato un pochino; ha solo delle difficoltà a trovare informazioni.

Utonto

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.

Utonto

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 hacker è, 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 newsgroup 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; 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).

Come rispondere alle domande in maniera utile

Siate gentili.
Lo stress provocato da un certo problema può far apparire rude, piuttosto che stupida, una persona che in realtà non lo è.
Replicate in privato a chi vi offende.
Non c’è alcun bisogno di umiliare pubblicamente qualcuno che ha fatto un errore senza intenzionalità. Un vero principiante può effettivamente non sapere come effettuare delle ricerche negli archivi o dove sia disponibile la lista delle FAQ.
Se non ne siete sicuri, ditelo!
Una risposta sbagliata ma data con tono autorevole è peggio di non averne ottenuta alcuna. Non indicate a qualcuno la strada sbagliata, solo perchè è divertente farsi passare per un esperto. Siate modesti e onesti; siate di buon esempio sia verso chi chiede che agli altri “ascoltatori”.
Se non potete essere d’aiuto, non provocate confusione.
Non scherzate con procedure che potrebbero danneggiare la configurazione di un altro utente: il pover’uomo potrebbe interpretarle come istruzioni da seguire.
Stimolate l’interlocutore con altre domande al fine di ottenere ulteriori dettagli.
Se siete bravi a farlo, l’altro imparerà qualcosa di interessante, e magari anche voi. Cercate di trasformare le domande brutte in buone domande; ricordatevi che nessuno è nato professore, e siamo stati tutti dei principianti, una volta.

Anche se ribattere con un RTFM è talvolta giusticato, quando il destinatario è solo un pigrone, di solito è meglio indicare dove si possa trovare della documentazione adatta (fosse anche suggerire un frase chiave da cercare con Google).

Se proprio darai una risposta, fa che contenga del valore aggiunto.
Non suggerire strane peripezie quando qualcuno sta usando lo strumento sbagliato o con un approccio non corretto. Riformula la domanda.
Aiuta la comunità a imparare qualche cosa dal problema.
Quando vi imbattete in una domanda interessante, chiedetevi Che modifiche potrei apportare alla documentazione del caso o alle FAQ per far si che nessun’altro debba più rispondere a questa domanda? e poi mandate una patch al manutentore del documento.

Quando svolgete delle ricerche, per rispondere a una domanda, dimostrate la vostra abilità nel farla, piuttosto che far sembrare abbiate estratto dal cappello la soluzione. Rispondere a una buona domanda è come offrire un pranzo a una persona affamata, insegnare a svolgere in autonomia le ricerche necessarie è come insegnare a coltivarsi il cibo, per il resto della vita.

Risorse

Se avete bisogno di istruzioni sui fondamenti che fanno funzionare i personal computer, Unix e Internet, consultate i The Unix and Internet Fundamentals HOWTO.

Quando rilasciate del software o vi apportate delle modifiche, cercate di seguire le linee guida descritte nel Software Release Practice HOWTO.

Riconoscimenti

Evelyn Mitchell ha contribuito qualcuno degli esempi di domande stupide e ha ispirato la sezione Come rispondere alle domande in maniera utile section. Mikhail Ramendik ha tradotto il testo in russo e ha suggerito svariate migliorie.

[1] È sua la traduzione originale, da cui deriva gran parte di questo documento.
[2] Ha traslato in reST e aggiornato il lavoro di Maurizio alla versione 3.0 del documento originale.
[3] In inglese to lurk.
[4] La parola originale, loser o anche luser, è una voce gergale, e come tale non è direttamente traducibile: è di fatto un gioco sulla somiglianza con looser, perdente. In questa versione si è reso l’idea usando utonto, storpiando la parola utente (grazie al anonimo segnalatore!-). Vorrei dissentire: Mi permetto di insistere, per amor del vero 😉 Google translate mi dà ragione. Nella pagina originale http://www.catb.org/~esr/faqs/smart-questions.html non compare mai la parola “looser”, c’è invece “loser”, che viene tradotto come “perdente”. Google translate traduce loser, non looser. Ringrazio G******* M******* per la post… (Diaolin)