Come Porre Domande Nel Modo Intelligente

Eric Steven Raymond

Thyrsus Enterprises

<esr@thyrsur.com>

Rick Moen

<rick@linuxmafia.com.com>

Tradotto dall'originale How To Ask Questions The Smart Way da Armando "Army1987" Di Matteo <army1987@email.it>.

Copyright (c) 2001 Eric S. Raymond


Indice

Traduzioni
Disclaimer
Introduzione
Prima che tu chieda
Quando chiedi
Scegli il tuo forum attentamente
I forum Web e IRC diretti verso i principianti spesso danno la risposta più veloce
Come secondo passo, usa le mailing list dei progetti
Usa oggetti espressivi e specifici
Rendi facile rispondere
Scrivi in un linguaggio chiaro, grammaticalmente ed ortograficamente corretto
Invia le domande in formati che siano facili da capire
Sii preciso ed istruttivo riguardo al tuo problema
Il volume non è precisione
Non reclamare di aver trovato un bug
Leccare i piedi non è un'alternativa a fare i tuoi compiti
Descrivi i sintomi del problema, non le tue supposizioni
Descrivi i sintomi del tuo problema in ordine cronologico
Descrivi l'obiettivo, non il passaggio
Non chiedere alle persone di rispondere via e-mail privata
Sii esplicito riguardo alla domanda che hai
Non porre domande sui compiti per casa
Limita le domande inutili
Non segnalare la tua domanda come "Urgente", anche se per te lo è
La cortesia non fa mai male, e a volte aiuta
Invia una breve annotazione sulla soluzione
Come interpretare le risposte
RTFM e STFW: Come Dire Che L'Hai Seriamente Fatta Fuori Dal Vaso
Se non capisci...
Trattare con la scortesia
Per Non Reagire Come Un Perdente
Domande Da Non Porre
Domande Buone e Cattive
Se Non Riesci Ad Ottenere Una Risposta
Come Rispondere alle Domande in Modo Utile
Risorse Correlate
Ringraziamenti

Traduzioni

Traduzioni: Cinese Ceco Danese Estone Francese Tedesco Ebraico Ungerese Italiano Giapponese Polacco Russo Spagnolo Svedese Turco. Se vuoi copiare, tradurre, o stralciare questo documento, per favore vedi la mia linea di copia.


Note del traduttore

Disclaimer

Molti siti di progetti linkano questo documento nella loro sezione su come ricevere aiuto. Questo va bene, è l'uso che intendevamo — ma se sei un webmaster che sta creando un tale link per la tua pagina di progetto, per favore visualizza ben in vista vicino al link nota che noi non siamo un help desk per il tuo progetto!

Abbiamo imparato con difficoltà che senza una tale nota, noi saremo ripetutamente importunati da idioti che pensano che il nostro aver pubblicato questo documento rende nostro lavoro risolvere tutti i problemi tecnici del mondo.

Se stai leggendo questo documento perché ti serve aiuto, e te ne vai con l'impressione che non lo puoi ricevere direttamente dagli autori, sei tu uno degli idioti in questione. Non porre domande a noi. Ti ignoreremo soltanto. Noi siamo qui per mostrarti come ricevere aiuto dalle persone che veramente sono al corrente del software o hardware di cui ti stai occupando, ma il 99% delle volte non saremo noi. A meno che non sai per certo che uno degli autori è un esperto di ciò di cui ti stai occupando, lasciaci in pace e saranno tutti più contenti.

Introduzione

Nel mondo degli hacker, il tipo di risposte che ricevi alle tue domande tecniche dipende tanto dal modo in cui poni le domande quanto dalla difficoltà di sviluppare la risposta. Questa guida t'insegnerà come porre domande in modo che ti sia probabile ricevere una risposta soddisfacente.

Adesso che l'uso di open source [software, solitamente gratuito, il cui codice sorgente è liberamente ottenibile NdT] è diventato diffuso, puoi spesso ricevere risposte da altri utenti, più esperti, piuttosto che hacker. Questa è una Cosa Buona; gli utenti tendono ad essere solo un pochettino più tolleranti del tipo di fallimenti che i principianti spesso hanno. Comunque, trattare gli utenti esperti come hacker nei modi che raccomandiamo qui sarà generalmente il modo più efficace per ricevere risposte utili anche da loro.

La prima cosa da capire è che agli hacker in realtà piacciono problemi difficili e buone domande che incitino alla riflessione riguardo ad essi. Se no, non saremmo qui. Se ci dai una domanda interessante su cui rimuginare ti 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 non avremmo potuto notare o pensarci sopra altrimenti. Tra gli hacker, "Buona domanda!" è un complimento forte e sincero.

Nonostante questo, gli hacker hanno la reputazione di venire incontro a domande semplici con quella che sembra ostilità o arroganza. Talvolta sembra che siamo riflessivamente maleducati verso i principianti e gli ignoranti. Ma questo non è realmente vero.

Ciò che noi siamo, senza scuse, è ostile alle persone che sembrano essere non disposte a pensare o a fare i propri compiti prima di porre domande. Persone così sono perdite di tempo — prendono senza restituire, sprecano tempo che avremmo potuto spendere su un'altra domanda più interessante e un'altra persona più degna di una risposta. Noi chiamiamo le persone persone così "losers", perdenti (e per ragioni storiche a volte lo scriviamo "lusers").

Capiamo che ci sono molte persone che semplicemente vogliono usare il software che scriviamo, e non hanno alcun interesse nell'imparare dettagli tecnici. Per la maggior parte delle persone, un computer è soltanto uno strumento, un mezzo per un fine; hanno cose più importanti da fare e vite da vivere. Noi ammettiamo ciò, e non ci aspettiamo che tutti s'interessino agli argomenti tecnici che ci affascinano. Tuttavia, la nostra maniera di rispondere alle domande è accordata per le persone che hanno un tale interesse e sono disposte ad essere partecipanti attivi nella risoluzione dei problemi. Ciò non cambierà. Né dovrebbe; se no, diventeremmo meno efficienti nelle cose che facciamo meglio.

Siamo (in gran parte) volontari. Sottraiamo tempo dalle nostre vite indaffarate per rispondere alle domande, e a volte siamo sopraffatti da esse. Così filtriamo spietatamente. In particolare, buttiamo via domande da persone che sembrano essere perdenti allo scopo di spendere il nostro tempo per rispondere a domande più efficientemente, sui vincitori.

Se trovi quest'atteggiamento odioso, condiscendente, o arrogante, controlla i tuoi presupposti. Non ti stiamo chiedendo di inginocchiarti a noi — di fatto, la maggior parte di noi non amerebbe nulla più di trattare con te come un pari e accoglierti nella nostra cultura, se ci metti lo sforzo richiesto per rendere ciò possibile. Ma è semplicemente non efficace per noi provare ad aiutare persone che non sono disposte ad aiutarsi da sole. È OK essere ignoranti; non è OK fare gli stupidi.

Così, mentre non è necessario essere già tecnicamente competenti per ricevere attenzione da noi, è necessario dimostrare il tipo d'atteggiamento che guida alla competenza — sveglio, premuroso, dotato di spirito d'osservazione, disposto ad essere un socio attivo nello sviluppare una soluzione. Se non puoi vivere con questo tipo di discriminazione, ti suggeriamo di pagare qualcuno per un contratto di supporto commerciale invece di chiedere a hacker di donarti personalmente aiuto.

Se decidi di venire da noi per aiuto, non vuoi essere uno dei perdenti. Non vuoi nemmeno sembrare uno di loro. Il miglior modo per ricevere una risposta rapida e comprensiva è chiederla come una persona con furbizia, fiducia, ed indizi a cui capita solo che serva aiuto su un particolare problema.

(Miglioramenti a questa guida sono benvenuti. Puoi inviare suggerimenti ad esr@thyrsus.com. [NdT: Non credo che Eric S. Raymond capisca l'italiano, perciò scrivete in inglese. L'email mia è army1987@email.it.] Nota comunque che questo documento non è inteso per essere una guida generale alla netiquette, e generalmente rifiuterò suggerimenti che non sono specificamente relativi al ricavare risposte utili in un forum tecnico.)

Prima che tu chieda

Prima di porre una domanda tecnica via e-mail, o in un newsgroup, o sulla chat di un sito Web, fai le seguenti cose:

  1. Prova a trovare una risposta cercando sul Web.

  2. Prova a trovare una risposta leggendo il manuale.

  3. Prova a trovare una risposta leggendo una FAQ.

  4. Prova a trovare una risposta con un controllo o sperimentazione.

  5. Prova a trovare una risposta chiedendo ad un amico esperto.

  6. Se sei un programmatore, prova a trovare una risposta leggendo il codice sorgente.

Quando poni la tua domanda, visualizza il fatto che hai fatto queste cose prima; questo aiuterà a stabilire che non sei uno scroccone pigro e non stai sprecando il tempo delle persone. Ancora meglio, mostra ciò che hai imparato facendo queste cose. Ci piace rispondere alle domande per persone che hanno dimostrato di saper imparare dalle risposte.

Usa tattiche come fare una ricerca su Google sul testo di qualunque messaggio d'errore tu ottenga (e cercate non solo nelle pagine web ma anche nei gruppi di Google). Questo potrebbe ben portarti direttamente alla documentazione del dilemma o ad un thread di mailing list che risponderà alla tua domanda. Anche se no, dire "Ho cercato su Google la seguente frase ma non ho trovato nulla che sembrava utile" è una cosa buona da poter mettere in un'e-mail o in un post su un forum chiedendo aiuto.

Prepara la tua domanda. Riflettici a fondo. Domande che sembrano affrettate ricevono risposte affrettate, o proprio nessuna. Più dimostri di aver messo attenzione e sforzo per risolvere il tuo problema, più probabilmente riceverai realmente aiuto.

Guardati dal porre la domanda sbagliata. Se ne poni una che è basata su false ipotesi, J. Hacker Qualsiasi piuttosto probabilmente replicherà con una risposta inutilmente letterale pensando "Domanda stupida...", e sperando che l'esperienza di ottenere ciò che hai chiesto piuttosto che ciò che ti serviva t'insegnerà una lezione.

Non presupporre mai di avere diritto ad una risposta. Non ne hai; non stai, dopotutto, pagando il servizio. Guadagnerai una risposta, se la guadagnerai, ponendo una domanda che è sostanziosa, interessante, e che inciti a pensare — una che implicitamente contribuisce all'esperienza della comunità piuttosto che solamente chiedere passivamente conoscenza dagli altri.

D'altra parte, rendere chiaro che sei in grado e disposto ad aiutare nel processo di sviluppare la soluzione è un inizio molto buono. "Qualcuno mi fornirebbe un'indicazione?", "Cosa manca al mio esempio" e "Quale sito avrei dovuto controllare?" riceveranno risposte più probabilmente di "Per favore pubblicate la procedura esatta che dovrei usare." perché stai rendendo chiaro che sei sinceramente disposto a completare il processo se qualcuno può semplicemente rivolgerti nella direzione giusta.

Quando chiedi

Scegli il tuo forum attentamente

Sii sensibile nello scegliere dove porre la tua domanda. Probabilmente sarai ignorato, o considerato un perdente, se:

Gli hacker scartano domande che sono inappropriatamente indirizzate allo scopo di provare a proteggere i loro canali di comunicazione dall'essere annegati in non pertinenza. Tu non vuoi che questo accada a te.

Il primo passo, perciò, è trovare il forum giusto. Di nuovo, Google e gli altri motori di ricerca sono il tuo amico. Usali per trovare la pagina web di progetto più strettamente associata con l'hardware o software che ti sta dando difficoltà. Di solito avrà collegamenti ad una lista di FAQ ("Frequently Asked Questions", domande frequentemente poste), e a mailing list del progetto e loro archivi. Queste mailing list sono gli ultimi posti dove andare in cerca d'aiuto, se i tuoi propri sforzi (incluso leggere quelle FAQ che hai trovato) non trovano una soluzione.

Ma mandare un'e-mail ad una persona o forum con cui non sei familiare è rischioso nella migliore delle ipotesi. Per esempio, non presupporre che l'autore di una pagina web informativa voglia essere il tuo consulente gratuito. Non fare congetture ottimistiche su se la tua domanda sarà benvenuta — se non sei sicuro, inviala altrove, o trattieniti proprio dal mandarla.

Scegliendo un forum Web, newsgroup o mailing list, non confidare nel nome da solo fino in fondo; cerca una FAQ o regolamento per verificare che la tua domanda sia in argomento. Leggi un po' del traffico precedente prima di postare così avrai un'idea per come si fanno le cose lì. Di fatto, è un'idea molto buona fare una ricerca con parole chiave su parole che si riferiscono al tuo problema sul newsgroup o archivi di mailing list prima di pubblicare. Può darsi che ti trovi una risposta, e se no ti aiuterà a formulare una domanda migliore.

Sappi qual è il tuo argomento! Uno degli sbagli classici è porre domande riguardo all'interfaccia di programmazione di Unix o Windows su un forum dedicato a un linguaggio o libreria o strumento che è portabile da uno all'altro. Se non capisci perché questa è una cantonata, sarebbe meglio che tu non ponga alcuna domanda finché non lo capisci.

In generale, domande ad un forum pubblico ben selezionato riceveranno risposte utili più probabilmente di domande equivalenti su uno privato. Ci sono motivi complessi per questo. Uno è semplicemente la dimensione dell'insieme dei potenziali convenuti. Un altro è la dimensione del pubblico; gli hacker risponderebbero piuttosto a domande che educano molte persone che domande che servono solo pochi.

Comprensibilmente, gli hacker esperti e gli autori di software popolare ricevono sempre più della loro giusta parte di messaggi mal indirizzati. Aggiungendo al diluvio, potresti in casi estremi perfino essere la goccia che fa traboccare il vaso — non poche volte, collaboratori a progetti popolari hanno ritirato il loro supporto perché il danno collaterale sotto forma di traffico e-mail inutile verso i loro account personali è diventato insopportabile.

I forum Web e IRC diretti verso i principianti spesso danno la risposta più veloce

Il tuo user group locale, o la tua distribuzione Linux, può darsi pubblicizzino un forum Web o canale IRC dove i principianti possono ricevere aiuto. (In nazioni non di lingua inglese i forum per principianti sono ancora più probabilmente mailing list.) Questi sono buoni primi posti, per chiedere, specialmente se pensi che potresti essere inciampato in un problema relativamente semplice o comune. Un canale IRC pubblicizzato è un invito aperto a porre domande lì e spesso ricevere risposte in tempo reale.

Di fatto, se ti sei procurato il programma che ti sta dando problemi da una distribuzione (com'è comune oggi), può darsi sia meglio chiedere nel forum/list della distro prima di provare il forum/list del progetto del programma. Gli hacker del progetto protrebbero dire soltanto: "usa il nostro build".

Prima di pubblicare in alcun forum Web, controlla se ha una caratteristica Cerca. E se sì, prova un paio di ricerche di parole chiave per qualcosa come il tuo problema; potrebbe soltanto aiutare. Se hai fatto una ricerca Web prima (come avresti dovuto), cerca nel forum comunque; il tuo motore di ricerca web potrebbe non avere tutto questo forum indicizzato recentemente.

C'è una tendenza in aumento che i progetti facciano supporto utenti su un forum Web o canale IRC, con l'email più riservata per il traffico di sviluppo. Così cerca prima questi canali quando cerchi aiuto specifico a un progetto.

Come secondo passo, usa le mailing list dei progetti

Quando un progetto ha una mailing list di sviluppo, scrivi alla mailing list, non ai singoli sviluppatori, anche se credi di sapere chi può rispondere meglio alla tua domanda. Controlla la documentazione del progetto e la sua homepage per l'indirizzo di una mailing list del progetto, e usalo. Ci sono diverse buoni motivi per questa politica:

Se un progetto ha sia una mailing list o forum Web per gli "utenti" sia una per gli "sviluppatori" (o "hacker"), e non stai smanettando sul codice, chiedi nella list/forum degli "utenti". Non presumere che sarai benvenuto sulla list degli sviluppatori, dove probabilmente sentiranno la tua domanda come rumore che scompiglia il loro traffico di sviluppatori.

Comunque, se sei sicuro che la tua domanda è non-banale, e non ricevi alcuna risposta nella list/forum degli "utenti" per diversi giorni, prova quella degli "sviluppatori". Ti sarebbe ben consigliato di consultarla per un po' di giorni prima di pubblicare per imparare gli usi e costumi locali (in realtà questo è un buon suggerimento su qualunque list privata o semi-privata).

Se non riesci a trovare un indirizzo della mailing list del progetto, ma vedi solo l'indirizzo del mantenitore del progetto, procedi e scrivi al mantenitore. Ma anche in tal caso, non presumere che la mailing list non esista. Specifica nella tua e-mail che hai provato e non sei riuscito a trovare la mailing list appropriata. Inoltre accenna che non sei contrario se il tuo messaggio viene inoltrato ad altre persone. (Molte persone credono che le e-mail private debbano rimanere private, anche se non c'è niente di segreto in esse. Permettendo al tuo messaggio di essere inoltrato dai al tuo corrispondente una scelta su come trattare la tua e-mail.)

Usa oggetti espressivi e specifici

Sulle mailing list o newsgroups, l'oggetto è la tua occasione d'oro per attrarre l'attenzione di esperti qualificati in circa 50 caratteri o meno. Non sprecarlo su ciance come "Per favore aiutatemi" (per non parlare di "PER FAVORE AIUTATEMI!!!!"; messaggi con oggetti come quello si eliminano istintivamente). Non provare ad impressionarci con la profondità della tua angoscia; invece usa questo spazio per una descrizione super-concisa del problema.

Una buona convenzione per gli oggetti, usata da molte organizzazioni per il supporto tecnico, è "oggetto - deviazione". La parte "oggetto" specifica quale cosa o gruppo di cose sta avendo un problema, e la parte "deviazione" descrive la deviazione dal comportamento previsto.

Stupido:

AIUTO! Il video non funziona correttamente sul mio laptop!

Intelligente:

XFree86 4.1, puntatore del mouse deformato, chipset video Fooware MV1005

Più intelligente:

XFree86 4.1, il puntatore del mouse sul chipset video Fooware MV1005 è deformato

Il processo di scrivere una descrizione "oggetto-deviazione" ti aiuterà ad organizzare la tua riflessione sul problema più in dettaglio. Cosa è affetto? Solo il puntatore del mouse o anche l'altra grafica? È specifico a XFree86? Alla versione 4.1? È specifico ai chipset video Fooware? Al modello MV1005? Un hacker che vede il risultato può subito capire con cosa stai avendo un problema e il problema che stai avendo, con uno sguardo.

Più generalmente, immagina di guardare l'indice di un archivio di domande, con solo la linea dell'oggetto mostrata. Fa' riflettere alla linea dell'oggetto la tua domanda abbastanza bene che il prossimo tizio che cercherà nell'archivio con una domanda simile alla tua potrà seguire il thread [insieme di messaggi facenti parte della stessa discussione] fino ad una risposta piuttosto che pubblicare la domanda di nuovo.

Se poni una domanda in una risposta, assicurati di cambiare l'oggetto per indicare che stai ponendo una domanda. Un oggetto che sembra come "Re: test" o "Re: nuovo bug" attirerà meno probabilmente quantitativi utili di attenzione. Inoltre, riduci le citazioni di precedenti messaggi al minimo indispensabile per informare i nuovi lettori.

Non premere semplicemente rispondi a un messaggio della lista per iniziare un thread interamente nuovo. Questo limiterà la tua audience. Alcuni programmi di mail, come mutt, permettono all'utente di ordinare per thread e quindi nascondere i messaggi in un thread comprimendo il thread. Coloro che fanno ciò non vedranno mai il tuo messaggio.

Cambiare l'oggetto non basta. Mutt, e probabilmente altri programmi di mail, cerca altre informazioni nelle intestazioni dell'email per assegnarla a un thread, non l'oggetto. Invece apri un'email interamente nuova.

Sui forum Web le regole di buona pratica sono leggermente differenti, perchè i messaggi sono di solito molto più strettamente legati ai thread di discussioni specifiche e spesso invisibili al di fuori di quei thread. Cambiare l'oggetto quando si pone una domanda in risposta non è essenziale (nemmeno tutti i forum permettono linee dell'oggetto separate sulle risposte, e quasi nessuno le legge quando ci sono). Ma chiedere una domanda in una risposta è una pratica dubbia in sè, perché sarà vista solo da coloro che stanno guardando questo thread. Così, a meno che non sei sicuro di voler chiedere alle persone correntemente attive nel thread, iniziane uno nuovo.

Rendi facile rispondere

Finire la tua richiesta con "Per favore inviate la vostra risposta a..." rende piuttosto improbabile che otteniate una risposta. Se non puoi disturbarti per impiegare anche i pochi secondi richiesti per impostare un campo Indirizzo per risposte corretto nel tuo programma di mail, noi non possiamo disturbarci per impiegare anche i pochi secondi per pensare al tuo problema. Se il tuo programma di mail non permette questo, procurati un programma di mail migliore. Se il tuo sistema operativo non supporta alcun programma di mail che permetta questo, procurati un sistema operativo migliore.

Nei forum Web, chiedere una risposta via email è francamente maleducato, a meno che non pensi che le informazioni potrebbero essere sensibili (e qualcumo, per qualche sconosciuto motivo, te le farà sapere a te ma non all'intero forum). Se vuoi ricevere un'email quando qualcuno risponde nel thread, richiedi che il forum Web te la invii; questa caratteristica è supportata quasi ovunque sotto opzioni come "segui questo thread", "avvisami delle risposte", etc.)

Scrivi in un linguaggio chiaro, grammaticalmente ed ortograficamente corretto

Abbiamo trovato per esperienza che le persone che sono scrittori sbadati e trascurati sono di solito sbadate e trascurate anche nel pensare e nel programmare (abbastanza spesso per scommetterci, comunque). Rispondere a domande per pensatori sbadati e trascurati non è rimunerativo; piuttosto spenderemmo il nostro tempo altrove.

Così esprimere la tua domanda chiaramente e bene è importante. Se non puoi disturbarti a fare ciò, noi non possiamo disturbarci per prestare attenzione. Spendi lo sforzo aggiuntivo per correggere il tuo linguaggio. Non deve essere aulico o formale — di fatto, la cultura hacker apprezza il linguaggio informale, gergale e umoristico usato con precisione. Ma deve essere preciso; ci deve essere qualche segno che stai pensando e prestando attenzione.

Usa ortografia, punteggiatura e maiuscole correttamente. Non confondere "its" (suo) con "it's" (è), "loose" (allentare) con "lose" (perdere), o "discrete" (distinto) con "discreet" (riservato). Non SCRIVERE IN TUTTE MAIUSCOLE, questo è interpretato come gridare e considerato maleducato (Tutte-minuscole è solo un po' meno irritante, essendo difficile da leggere. Alan Cox può fuggirne, ma tu no.)

Più generalmente, se scrivi come un idiota semi-analfabeta molto probabilmente verrai ignorato. Scrivere come un l33t script kiddie hax0r [Cioè, come viene spiegato in questa pagina NdT] è il bacio della morte totale e ti garantisce di non ricevere nulla tranne silenzio di pietra (o, nella migliore delle ipotesi, un'assistenza coperta di disprezzo e sarcasmo) come risposta.

Se stai ponendo domande in un forum che non usa la tua lingua madre, chiuderemo un occhio sugli errori di ortografia e grammatica — ma non sulla pigrizia (e sì, di solito sappiamo individuare tale differenza). Inoltre, a meno che non sai quali sono le lingue del tuo convenuto, scrivi in inglese. Gli hacker indaffarati tendono semplicemente a cestinare le domande in lingue che non capiscono, e l'inglese è la lingua attiva di Internet. Scrivendo in inglese minimizzi le tue possibilità che la tua domanda venga scartata senza essere letta.

Invia le domande in formati che siano facili da capire

Se rendi la tua domanda artificialmente difficile da leggere, sarà più probabilmente ignorata a favore di una che non lo è. Così:

Se stai usando un programma di mail ad interfaccia grafica, (come Netscape Messenger, MS Outlook, o uno del genere) evita che possa violare queste regole se usato con le impostazioni predefinite. La maggior parte di tali programmi hanno un comando da menu "Messaggio originale". Usa questo su qualcosa nella tua cartella della posta inviata per controllare di star inviando testo normale senza superflua robaccia attaccata.

Sii preciso ed istruttivo riguardo al tuo problema

Fai del tuo meglio per prevedere le domande che un hacker porrà, e rispondere ad esse anticipatamente nella tua richiesta di aiuto.

Simon Tatham ha scritto un saggio eccellente intitolato How to Report Bugs Effectively (come annunciare bugs efficacemente). Ti raccomando fortemente di leggerlo.

Il volume non è precisione

Devi essere preciso e istruttivo. Questo fine non si ottiene gettando enormi volumi di codice o dati in una richiesta di aiuto. Se hai un problema grande e complicato che sta rompendo un programma, prova a ridurlo e renderlo più piccolo possibile.

Questo è utile per almeno tre motivi. Uno: sembrar investire sforzo nel semplificare la domanda rende più probabile che otterrai una risposta. Due: semplificare la domanda rende più probabile che otterrai una risposta utile. Tre: nel processo di perfezionare la relazione del tuo bug, può darsi che sviluppi un rimedio o una soluzione tu stesso.

Non reclamare di aver trovato un bug

Quando stai avendo problemi con un software, non reclamare di aver trovato un bug a meno che non sia proprio, proprio sicuro delle tue ragioni. Suggerimento: a meno che non puoi fornire una patch in codice sorgente che sistemi il problema, o un test di regressione contro una versione precedente che dimostri il comportamento scorretto, probabilmente non sei abbastanza sicuro.

Ricorda, ci sono molti altri utenti che non stanno sperimentando il tuo problema. Altrimenti avresti appreso riguardo esso leggendo la documentazione e cercando sul Web (hai fatto ciò prima di lamentarti, non è vero?). Questo significa che molto probabilmente sei tu che stai facendo qualcosa di sbagliato, non il software.

Chi ha scritto il software lavora molto duramente per farlo funzionare meglio possibile. Se pretendi di aver trovato un bug, starai insinuando che hanno fatto qualcosa di sbagliato, e quasi sempre li offenderai — anche quando hai ragione. È specialmente privo di tatto gridare "bug" nell'oggetto.

Ponendo la domanda, è meglio scrivere come se presupponi che tu stia facendo qualcosa di sbagliato, anche se in privato sei abbastanza sicuro di aver trovato un vero bug. Se c'è davvero un bug, ne sentirai parlare nella risposta. Fai così che i mantenitori vorranno scusarsi con te se il bug è vero, piuttosto che così da dover loro una scusa se ti sei sbagliato.

Leccare i piedi non è un'alternativa a fare i tuoi compiti

Alcune persone che capiscono che non dovrebbero comportarsi maleducatamente o arrogantemente, chedendo una risposta, indietreggiano fino all'estremo opposto di leccare i piedi. "Lo so che sono solo un patetico perdente principiante, ma..." Questo è distraente e inutile. È specialmente irritante quando è accoppiato con vaghezza riguardo il vero problema.

Non sprecare il tuo tempo, o il nostro, su rozza politica da primate. Invece, presenta le informazioni di preparazione e la tua domanda più chiaramente che puoi. Questo è un modo migliore di posizionarti che leccando i piedi.

A volte i forum Web hanno posti separati per le domande dei principianti. Se senti di avere una domanda da principiante, vacci e basta. Ma non leccare i piedi nemmeno lì.

Descrivi i sintomi del problema, non le tue supposizioni

Non è utile dire agli hacker cosa credi stia causando il tuo problema. (Se le tue teorie diagnostiche fossero così eccezionali, staresti consultando altri per essere aiutato?) Così, assicurati di star loro dicendo solo i sintomi di ciò che va male, piuttosto che le tue interpretazioni e teorie. Lascia fare l'interpretazione e la diagnosi a loro. Se senti che è importante esporre la tua supposizione, etichettala chiaramente come tale e descrivi perché quella risposta non ti sta funzionando.

Stupido:

Sto ottenendo errori back-to-back SIG11 durante le compilazioni del kernel, e sospetto la rottura di una delle tracce della scheda madre. Qual è il modo migliore per controllarle?

Intelligente:

Il mio K6/233 assemblato su una scheda madre FIC-PA2007 (chipset VIA Apollo VP2) con 256MB di SDRAM PC133 Corsair inizia a dare frequenti errori SIG22 circa 20 minuti dopo l'accensione nel corso delle compilazioni del kernel, ma mai nei primi 20 minuti. Riavviare non azzera l'orologio, ma tenerlo spento per una notte sì. Cambiare tutta la RAM non ha aiutato. Segue la parte relativa ad una trascrizione di una sessione di compilazione tipica.

Descrivi i sintomi del tuo problema in ordine cronologico

Gli indizi più utili nel capire qualcosa che è andato male spesso si trovano negli eventi immediatamente precedenti. Così, la tua descrizione dovrebbe descrivere precisamente cosa hai fatto, e cosa ha fatto la macchina, fino al disastro. Nel caso di processi in linea dei comandi, avere una trascrizione della sessione (p.e., usando la script utility) e citare le relative venti righe è molto utile.

Se il progamma che ha provocato il disastro ha opzioni diagnostiche (come -v per verbose), prova a pensare attentamente di selezionare opzioni che aggiungeranno informazioni utili al debug nella trascrizione.

Se la tua descrizione finisce per essere troppo lunga (più di quattro paragrafi), potrebbe essere utile indicare succintamente il problema all'inizio, quindi continuare col racconto cronologico. In tal modo, gli hacker sapranno cosa guardare leggendo la tua descrizione.

Descrivi l'obiettivo, non il passaggio

Se stai cercando di scoprire come fare qualcosa (in contrasto con riferire un bug), inizia descrivendo l'obiettivo. Solo allora descrivi il particolare passaggio verso ciò su cui ti sei bloccato.

Spesso, le persone a cui serve aiuto tecnico hanno un obiettivo di alto livello in mente e si bloccano su ciò che pensano sia un particolare percorso verso l'obiettivo. Può richiedere molti sforzi per superare questo.

Stupido:

Come faccio prendere un valore RGB esadecimale al color-picker sul programma FooDraw?

Intelligente:

Sto provando a sostituire la tabella dei colori di un'immagine con valori di mia scelta. Proprio adesso l'unico modo che riesco a vedere per fare questo è modificando ogni spazio della tabella, ma non so far prendere un valore RGB esadecimale al color picker di FooDraw.

La seconda versione se la domanda è intelligente. Permette una risposta che suggerisce uno strumento più adatto al compito.

Non chiedere alle persone di rispondere via email privata

Gli hacker credono che risolvere i problemi debba essere un processo pubblico e trasparente durante il quale il primo tentativo di risposta può e dovrebbe essere corretto se qualcuno meglio informato nota che è incompleto o scorretto. Inoltre, ricevono parte del loro rispetto per essere convenuti dall'essere visti essere competenti e ben informati dai loro pari.

Quando chiedi una risposta privata, stai scombussolando sia il processo che il rispetto. Non fare questo. È la scelta del convenuto se rispondere in privato — e se sì, di solito è perche pensa che la domanda sia troppo mal formata o ovvia per interessare altri.

C'è una limitata eccezione a questa regola. Se pensi che la domanda sia tale che probabilmente riceverai molte domande che sono piuttosto simili, allora le parole magiche sono "mandatemi un'email e riassumerò le risposte per il gruppo". È cortese provare a salvare la mailing list o newsgroup da un'inondazione di messaggi sostanzialmente identici — ma devi mantenere la promessa di riassumere.

Sii esplicito riguardo alla domanda che hai

Le domande indeterminate tendono ad essere percepite come perdite di tempo indeterminate. Le persone che potranno più probabilmente darti una risposta utile sono anche le persone più indaffarate (se solo perchè intraprendono la maggior parte del lavoro loro stesse). Persone come quelle sono allergiche alle perdite di tempo indeterminate, perciò tendono ad essere allergiche alle domande indeterminate.

Riceverai più probabilmente una risposta utile se sei esplicito riguardo ciò che vuoi che i convenuti facciano (fornire indicazioni, inviare codice, controllare la tua patch, qualunque cosa). Questo metterà a fuoco i loro sforzi e implicitamente metterà un limite al tempo e all'energia che un convenuto deve metterci per aiutarti. Questo è bene.

Per capire il mondo in cui gli esperti vivono, pensa alla perizia come una risorsa abbondante ed al tempo per rispondere come una scarsa. Meno impegno di tempo chiedi implicitamente, più probabilmente riceverai una risposta da qualcuno veramente buono e veramente indaffarato.

Così è utile inquadrare la tua domanda per minimizzare l'impegno di tempo richiesto affinché un esperto risponda ad essa — ma questo spesso non è la stessa cosa di semplificare la domanda. Perciò, 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 che non è funzionante, è di solito più intelligente chiedere a qualcuno di spiegare cosa è sbagliato con esso che chiedere a qualcuno di sistemarlo.

Non porre domande sui compiti per casa

Gli hacker sono bravi a individuare le domande sui compiti; la maggior parte di noi li ha fatti da soli. Quelle domande sono affinchè tu le risolva, così che imparerai dall'esperienza. È OK chiedere suggerimenti, ma non intere soluzioni.

Se sospetti che ti sia stata data una domanda come compito per casa, ma non la sai risolvere comunque, prova a chiedere nel forum di un gruppo di utenti o (come ultima risorsa) in una list/forum per gli "utenti" di un progetto. Mentre gli hacker la individueranno, alcuni degli utenti avanzati può darsi ti daranno almeno un suggerimento.

Limita le domande inutili

Resisti alla tentazione di chiudere la tua richiesta di aiuto con domande semanticamente nulle come "Qualcuno può aiutarmi?" o "C'è una risposta?" Primo: se hai scritto la descrizione del tuo problema quasi con competenza, tali domande aggiunte sono nella migliore delle ipotesi superflue. Secondo: poichè sono superflue, gli hacker le trovano irritanti — e probabilmente replicheranno risposte logicamente impeccabili ma destituibili come "Sì, puoi essere aiutato" e "No, non c'è niente da fare per te."

In generale, chiedere domande sì-o-no è una buona cosa da evitare a meno che non vuoi una risposta sì-o-no.

Non segnalare la tua domanda come "Urgente", anche se per te lo è

Quello è un tuo problema, non nostro. Pretendere urgenza sarà molto probabilmente controproduttivo: la maggior parte degli hacker semplicemente cancelleranno tali messaggi come tentativi maleducati e egoistici di suscitare attenzione immediata e speciale.

C'è una sola semi-eccezione. Può valere la pena di menzionare se stai usando il programma in qualche posizione ben in vista, uno su cui gli hacker si ecciteranno; in un tale caso, se sei sotto la pressione del tempo, e lo dici educatamente, le persone potrebbero interessarsi abbastanza per rispondere più velocemente.

Questa è una cosa molto rischiosa da fare, comunque, perchè la metrica degli hacker per che cosa è eccitante probabilmente differisce dalla tua. Scrivere dalla Stazione Spaziale Internazionale qualificherebbe, per esempio, ma scrivere per conto di una causa di beneficenza o politica quasi certamente no. Di fatti, scrivere "Urgente: Aiutatemi a salvare i cuccioli di foca pelosi!" ti renderà credibilmente snobbato o offeso anche dagli hacker che pensano che i cuccioli di foca pelosi siano importanti.

Se trovi questo misterioso, rileggi il resto di questa guida ripetutamente finchè non lo capisci prima di scrivere affatto.

La cortesia non fa mai male, e a volte aiuta

Sii cortese. Usa "Per favore" e "Grazie in anticipo". Rendi chiaro che apprezzi il tempo che le persone spendono aiutandoti gratis.

Ad essere onesti, questo non è tanto importante quanto (e non è un'alternativa a) essere grammatici, chiari, precisi e descrittivi, evitare formati proprietari ecc.; gli hacker in generale preferirebbero relazioni di bug alquanto brusche ma tecnicamente acute piuttosto che vaghezza educata. (Se questo ti sconcerta, ricorda che valutiamo una domanda per ciò che c'insegna.)

Comunque, se hai le tue carte tecniche in regola, l'educazione aumenta le tue possibilità di ricevere una risposta utile.

(Dobbiamo notare che la sola obiezione seria che abbiamo ricevuto da hacker veterani a questa guida riguarda la nostra raccomandazione di usare "Grazie in anticipo". Alcuni hacker sentono che questo connoti un'intenzione di non rigraziare nessuno dopo. La nostra raccomandazione è o dire "Grazie in anticipo" prima e ringraziare i convenuti dopo, o forse esprimere la cortesia in un modo diverso, come dicendo "Grazie per la tua considerazione".)

Fai seguito con una breve annotazione sulla soluzione

Invia un'annotazione dopo che il problema è stato risolto a tutti coloro che ti hanno aiutato; fa' loro sapere com'è venuto fuori e ringraziari di nuovo per il loro aiuto. Se il problema ha attirato interesse generale in una mailing list o newsgroup, è appropriato pubblicare l'articolo di seguito lì.

Ottimamente, la risposta dovrebbe essere al thread iniziato dal messaggio della domanda originale, e dovrebbe avere 'SISTEMATO' 'RISOLTO' o un'espressione ugualmente ovvia nell'oggetto. Nelle mailing list veloci, un potenziale convenuto che vede un thread riguardo "Problema X" terminante con "Problema X - SISTEMATO" sa di non dover sprecare il suo tempo senza nemmeno leggere il thread (a meno che non trovi personalmente il Problema X interessante) e può perciò usare quel tempo risolvendo un problema diverso.

Il tuo articolo di seguito non deve essere lungo e involuto; un semplice "Salve — era un cavo di rete fallito! 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 non abbia vera profondità tecnica. Di' quale azione ha risolto il problema, ma non hai bisogno di ripetere l'intera serie di risoluzione del problema.

Per problemi con qualche profondità, è appropriato pubblicare un riassunto della storia della risoluzione del problema. Descrivi il tuo resoconto finale del problema. Descrivi cosa ha funzionato come soluzione, e indica i vicoli ciechi evitabili dopo ciò. I vicoli ciechi dovrebbero venire dopo la soluzione corretta ed altro materiale di riassunto, piuttosto che trasformare l'articolo di seguito in una storia di detective. Fai i nomi delle persone che ti hanno aiutato; te le farai amiche in tal modo.

Oltre ad essere cortese e istruttivo, questo tipo di articolo di seguito aiuterà gli altri che cercano nell'archivio della mailing-list/newsgroup/forum a sapere esattamente quale soluzione ti ha aiutato e perciò potrà aiutare anche loro.

Ultimo, e non meno importante, questo tipo di articolo di seguito aiuta chiunque abbia assistito a sentire un soddisfacente senso di conclusione riguardo al problema. Se non sei un techie o un hacker tu stesso, credici che questa sensazione è molto importante per i guru e gli esperti da cui hai attinto aiuto. Racconti di problemi che vengono meno in nullità irrisolta sono cose frustanti; gli hacker fremono per vederli risolti. Il buon karma che calmare quel fremito ti guadagnerà ti sarà molto, molto utile la prossima volta che dovrai porre una domanda.

Considera come potresti prevenire che altri abbiano lo stesso problema in futuro. Chiediti se una documentazione o FAQ aiuterebbe, e se la risposta è sì mandala al mantenitore.

Tra gli hacker, questo tipo di comportamento è in realtà più importante dell'educazione convenzionale. È come ottieni una reputazione per comportarti bene con gli altri, che può essere un bene molto prezioso.

Come interpretare le risposte

RTFM e STFW: Come Dire Che L'Hai Seriamente Fatta Fuori Dal Vaso

C'è una tradizione antica e consacrata: se ricevi una risposta in cui si legge "RTFM", la persona che l'ha mandata pensa che avresti dovuto "leggere il fottuto manuale" (Read The Fucking Manual). Ha quasi certamente ragione. Vai a leggerlo.

RTFM ha un parente più giovane. Se ricevi una risposta in cui si legge "STFW", la persona che l'ha mandata pensa che avresti dovuto "cercare sul fottuto web" (Search The Fucking Web). Ha quasi certamente ragione. Vai a cercarlo. (La versione più lieve di questo è quando ti viene detto "Google è tuo amico!"

Nei forum Web, ti potrebbe anche essere detto di cercare negli archivi del forum. Di fatto, qualcuno potrebbe perfino essere così gentile da provvedere un puntatore al thread precedente dove il problema fu risolto. Ma non contare su questa considerazione; fai la tua ricerca nell'archivio prima di chiedere.

Spesso, la persona che ti sta mandando una di queste due risposte ha la pagina del manuale o del web con le informazioni che ti servono aperta, e la sta guardando mentre scrive. Queste risposte significano che pensa (a) che le informazioni che ti servono sono facili da trovare, e (b) che imparerai di più se cerchi le informazioni che se sei imboccato.

Non dovresti essere offeso da questo; per gli standard hacker, ti sta mostrando una grezza forma di rispetto semplicemente non ignorandoti. Dovresti invece ringraziarlo per la sua gentilezza da nonna.

Se non capisci...

Se non capisci la risposta, non far rimbalzare immediatamente una domanda per chiarimenti. Usa gli stessi strumenti che hai usato per provare a rispondere alla tua domanda originale (manuali, FAQ, il Web, amici esperti) per capire la risposta. Allora, se hai ancora bisogno di chiedere chiarimenti, esibisci ciò che hai imparato.

Per esempio, supponi che ti dica: "Mi sa che hai uno zentry bloccato; dovrai toglierlo." Allora ecco una cattiva domanda: "Che cos'è uno zentry?" Ed ecco una buona domanda: "OK, ho letto la pagina di manuale e gli zentry sono citati solo sotto i parametri -z e -p. Nessuno dei due dice niente su come togliere gli zentry. È uno di questi o qui mi sfugge qualcosa?"

Trattare con la scortesia

Molta di quella che sembra scortesia negli ambienti hacker non è intesa ad offendere. Piuttosto, è il prodotto dello stile di comunicazione diretto, che-taglia-attraverso-le-stupidaggini che è naturale per le persone che sono più interessate a risolvere problemi che a far sentire gli altri a proprio agio.

Quando percepisci scortesia, prova a reagire con calma. Se qualcuno la sta veramente usando, è molto probabile che una persona più autorevole sulla list o newsgroup o forum la richiamerà. Se ciò non avviene e tu perdi le staffe, è probabile che la persona con cui le perdi si stava comportando secondo le norme della comunità degli hacker e tu sarai considerato in errore. Questo nuocerà alle tue possibilità di ricevere le informazioni o l'aiuto che vuoi.

D'altra parte, ogni tanto incorrerai in scortesia e capricci che sono piuttosto gratuiti. Il rovescio della medaglia è che è una forma accettabile di colpire i veri offensori piuttosto duramente, analizzando il loro comportamento scorretto con affilato bisturi verbale. Sii molto, molto sicuro delle tue ragioni prima di provare questo, comunque. La linea tra correggere un'inciviltà e iniziare un'inutile guerra di "flames" (offese) è abbastanza sottile che gli hacker stessi non infrequentemente la superano; se sei un principiante o un estraneo, le tue possibilità di evitare una tale cantonata sono basse. Se sei in cerca di informazioni piuttosto che d'intrattenimento, è meglio tenere le tue dita via dalla tastiera che rischiare questo.

(Alcune persone asseriscono che molti hacker hanno una forma lieve di autismo o sindrome di Asperger, e mancano effettivamente di qualche circuito del cervello che lubrifica l'interazione sociale umana 'normale'. Questo può essere o non essere vero. Se non sei tu stesso un hacker, ti può aiutare a superare le nostre eccentricita se pensi di noi come dei cerebrolesi. Fai pure. Non ce ne importa; ci piace essere qualunque cosa siamo, e generalmente abbiamo un sano scetticismo sulle etichette cliniche.)

Nella prossima sezione, parleremo di una differente questione; il tipo di 'scortesia' che vedrai quando tu ti comporterai male.

Per Non Reagire Come Un Perdente

Ci sono possibilità che la faccia un po' di volte fuori dal vaso sui forum di comunità hacker — nei modi elencati in questo articolo, o simili. E ti verrà detto esattamente come l'hai fatta fuori dal vaso, forse con espressioni colorite. In pubblico.

Quando questo accade, la peggior cosa tu possa fare è piagnucolare dell'esperienza, reclamare di essere stato assalito verbalmente, chiedere scuse, gridare, trattenere il respiro, minacciare cause, lamentarsi con i datori di lavoro delle persone, lasciare il coperchio del WC alzato, ecc. Invece, ecco cosa fare:

Riprenditi. È normale. Di fatto, è salutare ed appropriato.

Gli standard delle comunità non si mantengono da soli: Sono mantenuti da persone che li applicano attivamente, visibilmente, in pubblico. Non piagnucolare che tutte le critiche sarebbero dovute essere condotte via mail privata: Non è così che funziona. Nè è utile insistere che sei stato personalmente insultato quando qualcuno commenta che una delle tue pretese era sbagliata, o che il suo punto di vista differisce. Questi sono atteggiamenti da perdente.

Ci sono stati forum di hacker dove, per qualche mal applicato senso di iper-cortesia, i partecipanti sono banditi dal pubblicare alcun ritrovamento di errore con gli articoli altrui, e viene detto "Non dire niente se non sei disposto ad aiutare l'utente." La risultante partenza di partecipanti che avrebbero potuto dare indizi verso altrove fa sì che si abbassino a balbettio senza senso e diventino inutili come forum tecnici.

Esageratamente "amichevole" (in quel senso) o utile: Scegline uno.

Ricorda: Quando quell'hacker dice che l'hai fatta fuori dal vaso, e (non importa quanto rozzamente) ti dice di non farlo di nuovo, si sta comportando per puro interessamento (1) tuo e (2) della sua comunità. Sarebbe molto più facile per lui ignorarti e filtrarti fuori dalla tua vita. Se non riesci ad essere grato, almeno abbi un po' di dignità, non piagnucolare, e non aspettarti di essere trattato come una bambola fragile solo perché sei un novizio con un anima ipersensibile in modo teatrale e illusione di diritto acquisito.

A volte le persone ti attaccheranno personalmente, offenderanno senza motivo, ecc., anche se non la fai fuori dal vaso (o l'hai fatta solo nella loro immaginazione). In questo caso, lamentarti è il modo di farla davvero fuori dal vaso.

Questi offensori sono o "lamers" [persone che si considerano hacker ma non lo sono, e spesso sono cracker] che non hanno la minima idea ma si credono di essere esperti, o aspiranti psicologi che provano se la farai fuori dal vaso. Gli altri lettori o li ignorano, o trovano modi per trattare con loro per conto loro. Il comportamento degli offensori crea problemi per loro stessi, che non ti devono concernere.

Non lasciarti nemmeno trascinare in una guerra di offese. La maggior parte delle offese fannno meglio ad essere ignorate — dopo che hai controllato se sono veramente offese, non puntatori ai modi in cui l'hai fatta fuori dal vaso, e non risposte abilmente cifrate alla tua vera domanda (anche questo accade).

Domande Da Non Porre

Ecco alcune classiche domande stupide, e ciò che gli hacker stanno pensando quando non rispondono ad esse.

D: Dove posso trovare il programma o la risorsa X?
D: Come posso usare X per fare Y?
D: Come posso configurare il mio prompt dei comandi?
D: Posso convertire un documento AcmeCorp in un file Tex usando il convertitore di file Bass-o-matic?
D: Il mio {programma, configurazione, comando SQL} non funziona
D: Sto avendo problemi con la mia macchina Windows. Potete aiutarmi?
D: Il mio programma non funziona. Penso che l'istallazione di sistema X sia rotta.
D: Sto avendo problemi istallando Linux o X. Puoi aiutarmi?
D: Come posso forzare la root/rubare i privilegi degli operatori dei canali/leggere le email di qualcuno?
D:.

Dove posso trovare il programma o la risorsa X?

R:.

Allo stesso posto dove lo troverei io, sciocco — dall'altra parte di una ricerca sul web. Oddio, non sanno ancora tutti usare Google?

D:.

Come posso usare X per fare Y?

R:.

Se quello che vuoi è fare Y, dovresti porre codesta domanda senza presupporre l'uso di un metodo che può darsi non sia appropriato. Domande di questa forma spesso indicano una persona che non è soltanto ignorante riguardo X, ma confusa su quale problema Y stanno risolvendo e troppo fissata sui dettagli della loro particolare situazione. È generalmente meglio ignorare tali persone finché non definiscono il loro problema meglio.

D:.

Come posso configurare il mio prompt dei comandi?

R:.

Se sei intelligente abbastanza per porre questa domanda, sei intelligente abbbastanza per RTFM e scoprirlo tu stesso.

D:.

Posso convertire un documento AcmeCorp in un file Tex usando il convertitore di file Bass-o-matic?

R:.

Provaci e vedi. Se lo facessi, tu (a) impareresti la risposta, e (b) smetteresti di sprecare il mio tempo.

D:.

Il mio {programma, configurazione, commando SQL} non funziona

R:.

Questa non è una domanda, e non sono interessato a giocare a Venti Domande per cavare la tua vera domanda da te — ho cose migliori da fare. Vedendo qualcosa del genere, la mia reazione è normalmente una delle seguenti:

  • hai niente da aggiungere a ciò?

  • oh, è troppo male, spero che tu riesca a farlo sistemare

  • e questo ha esattamente che cosa a che fare con me?

D:.

Sto avendo problemi con la mia macchina Windows. Potete aiutarmi?

R:.

Sì. Butta via quella spazzatura Microsoft ed istalla un sistema operativo open-source come Linux o BSD.

D:.

Il mio programma non funziona. Penso che l'istallazione di sistema X sia rotta.

R:.

Mentre è possibile che tu sia la prima persona a notare una ovvia deficienza in chiamate e librerie di sistema pesantemente usate da centinaia o migliaia di persone, è piuttosto più probabile che tu sia assolutamente senza indizi. Reclami straordinari richiedono prove straordinarie; quando fai un reclamo come questo, devi supportarla con chiara ed esaustiva documentazione del caso di guasto.

D:.

Sto avendo problemi istallando Linux o X. Puoi aiutarmi?

R:.

No, avrei bisogno di mettere le mani sulla tua macchina per risolvere questo. Va' a chiedere al tuo Linux user group locale per aiuto pratico. (Puoi trovare una lista di user groups qui.)

D:.

Come posso forzare la root/rubare i privilegi degli operatori dei canali/leggere le email di qualcuno?

R:. Sei un meschino per voler fare tali cose e un deficiente per chiedere ad un hacker di aiutarti. [NdT: Il termine 'hacker' è spesso usato impropriamente; cerca 'hacker' e poi 'cracker' su Garzanti Linguistica o, meglio ancora leggi questa definizione.]

Domande Buone e Cattive

Finalmente, sto per illustrare come porre domande in un modo intelligente con esempi; coppie di domande sullo stesso problema, una posta in un modo stupido ed una in un modo intelligente.

Stupida: Dove posso trovare roba riguardo il Foonly Flurbamatic?

Questa domanda elemosina soltanto "STFW" come risposta.

Intelligente: Ho usato Google per provare a trovare "Foonly Flurbamatic 2600" sul Web, ma non ho ottenuto risultati utili. Qualcuno sa dove posso trovare informazioni di programmazioni su questo dispositivo?

Questo qui ha già STFWato, e suona come se potesse avere un vero problema.

Stupida: Non riesco a far compilare il codice del progetto foo. Perché è rotto?

Presuppone che qualcun'altro l'abbia fatta fuori dal vaso. Arrogante nei suoi confronti.

Intelligente: Il codice del progetto foo non si compila sotto Nulix versione 6.2. Ho letto la FAQ, ma non dice nulla riguardo ai problemi relativi a Nulix. Ecco una trascrizione del mio tentativo di compilazione; è qualcosa che ho fatto?

Ha specificato l'ambiente, ha letto la FAQ, sta mostrando l'errore, e non sta presupponendo che i suoi problemi siano l'errore di qualcun'altro. Questo tipo potrebbe valere la pena di qualche attenzione.

Stupido: Sto avendo problemi con la mia scheda madre. Qualcuno può aiutare?

La risposta di J. Hacker Qualsiasi sarà probabilmente "Bene. Hai bisogno anche di fare il ruttino e di un pannolino?" seguita da un pugno sul tasto Canc.

Intelligente: Ho provato X, Y, e Z sulla scheda madre S2464. Quando ciò non ha funzionato, ho provato A, B, e C. Notate il curioso sintomo quando ho provato C. Ovviamente il florbish sta grommickando, [Sono termini nonsense, inventati da ESR per indicare un problema senza specificare quale. La traduzione spagnola ha lasciato l'intera frase in inglese :-D NdT] ma i risultati non sono quelli che ci si potrebbe aspettare. Quali sono le solite cause di grommicking sulle schede madre Athlon MP? Qualcuno ha idee su altri test che potrei effettuare per definire chiaramente il problema?

Questa persona, d'altra parte, sembra valere la pena di una risposta. Ha esibito intelligenza nella risoluzione dei problemi piuttosto che attendere passivamente che una risposta cadesse dall'alto.

Nell'ultima domanda, nota la sottile ma importanre differenza tra chiedere "Datemi una risposta" e "Per favore aiutatemi a scoprire quali altri diagnostici posso eseguire per ottenere la spiegazione."

In realtà, la forma dell'ultima domanda è strettamente basata su un vero caso che avvenne in agosto 2001 sulla linux-kernel mailing list (lkml). Io (Eric) ero quello che pose la domanda quella volta. Stavo vedendo misteriosi blocchi su una scheda madre Tyan S2462. I membri della lista fornirono le informazioni critiche che mi servivano per risolverli.

Ponendo la domanda come feci, diedi alle persone qualcosa su cui rimuginare; resi facile e attraente che fossero coinvolte. Dimostrai rispetto per l'abilità dei miei pari e li invitai a consultarsi con me come un pari. Dimostrai anche rispetto per il valore del loro tempo dicendo loro i vicoli ciechi che avevo già percorso.

Dopo, quando ringraziai tutti e notai quanto bene avesse funzionato il processo, un membro lkml osservò che pensava avesse funzionato non perché io sia un "nome" in quella lista, ma perché posi la domanda nella forma appropriata.

Gli hacker sono in qualche modo una meritocrazia molto spietata; sono sicuro che egli avesse ragione, e che se mi fossi comportato come una spugna sarei stato offeso o ignorato chiunque io fossi. Il suo suggerimento di scrivere l'intero caso come istruzioni ad altri portò direttamente alla composizione di questa guida.

Se Non Riesci Ad Ottenere Una Risposta

Se non riesci ad ottenere una risposta, per favore non prendertela personalmente che non ci sentiamo di poterti aiutare. A volte i membri del gruppo a cui hai chiesto può darsi semplicemente non sappiano la risposta. Nessuna risposta non è lo stesso che essere ignorati, benché sia indubbiamente difficile individuare la differenza dall'esterno.

In generale, ripubblicare semplicemente la tua domanda è una cattiva idea. Questo verrà visto come inutilmente irritante.

Ci sono altre fonti di aiuto a cui puoi andare, spesso fonti meglio adatte ai bisogni di un novizio.

Ci sono molti gruppi di utenti online e locali che sono entusiasti riguardo il software, anche se può darsi non abbiano mai scritto alcun software loro stessi. Questi gruppi spesso si formano così che le persone possono aiutarsi a vicenda ed aiutare i nuovi utenti.

Ci sono anche moltissime compagnie commerciali con cui puoi stipulare un contratto per aiuto, sia grandi che piccole (Red Hat e Linuxcare sono due delle meglio conosciute; ce ne sono molte altre). Non essere sgomentato all'idea di dover pagare per un po' di aiuto! Dopo tutto, se il motore della tua macchina farà saltare una guarnizione, ci sono possibilità che la porteresti ad un'officina e pagheresti per farlo aggiustare. Anche se il software non ti è costato nulla, non ti puoi aspettare che il supporto sia sempre gratuito.

Per software popolari come Linux, ci sono almeno 10000 utenti per sviluppatore. Non è possibile che una persona tratti le chiamate per supporto di oltre 10000 utenti. Ricorda che anche se devi pagare il supporto, stai ancora pagando molto meno che se dovessi comprare anche il software (e il supporto per software closed-source [software, solitamente a pagamento, il cui codice sorgente è segreto NdT] è solitamente più costoso e meno competente del supporto per software open-source).

Come Rispondere alle Domande in Modo Utile

Sii gentile. Lo stress relativo ai problemi può far sembrare le persone maleducare o stupide anche quando non lo sono.

Rispondi ai non recidivi in privato. Non c'è bisogno di umiliazione pubblica per qualcuno che può darsi abbia fatto uno sbaglio onesto. Un vero principiante potrebbe non sapere come cercare negli archivi o dove la FAQ è conservata o pubblicata.

Se non sai per certo, dillo! Una risposta sbagliata ma che sembra autorevole è peggio che del tutto nessuna. Non indicare a nessuno un percorso sbagliato semplicemente perché è divertente sembrare un esperto. Sii umile e onesto; dai un buon esempio sia per il richiedente che per i tuoi pari.

Se non puoi aiutare, non intralciare. Non fare battute riguardo procedure che potrebbero devastare il setup dell'utente — il povero sciocco potrebbe interpretare queste come istruzioni.

Poni domande indaganti per ottenere più dettagli. Se sei bravo in questo, il richiedente imparerà qualcosa — e anche tu potresti. Prova a trasformare la cattiva domanda in una buona; ricorda che tutti eravamo principianti una volta.

Mentre mormorare solo RTFM è a volte giustificato quando si risponde a qualcuno che è solo uno sciattone pigro, un consiglio a della documentazione (anche se è solo un suggerimento a Google per una chiave di ricerca) è meglio.

Se proprio hai intenzione di rispondere alla domanda, da' una risposta che valga. Non suggerire rimedi improvvisati quando qualcuno sta usando lo strumento o approccio sbagliato. Suggerisci buoni strumenti. Rincornicia la domanda.

Aiuta la tua comunità ad imparare dalla domanda. Quando rispondi abilmente ad una buona domanda, chiediti "Come dovrebbe la relativa documentazione o FAQ così che nessuno debba chiedere questo di nuovo?" Quindi manda una patch al mantenitore del documento.

Se hai fatto della ricerca per rispondere alla domanda, dimostra le tue abilità piuttosto che scrivere come se avessi cacciato la risposta dal tuo sedere. Rispondere ad una buona domanda è come dare da mangiare ad una persona affamata un pasto, ma insegnargli abilità di ricerca con l'esempio è come insegnargli a coltivare cibo per tutta la vita.

Risorse Correlate

Se ti servono istruzioni sulle basi di come i personal computer, Unix e Internet funzionano, vedi The Unix and Internet Fundamentals HOWTO.

Quando rilasci software o scrivi patch per software, prova a seguire le linee guida nella Software Release Practice HOWTO.

Riconoscimenti

Evelyn Mitchell ha contribuito ad alcuni esempi di domande stupide ed ispiraro la sezione "Come Dare Una Buona Risposta". Mikhail Ramendik ha contribuito sia ad alcuni suggerimenti particolarmente utili per miglioramenti.