http://army1987.890m.com/domande.html
Disclaimer
Molti siti web di progetti linkano questo documento nelle loro sezioni 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 mostra ben in vista vicino al link nota che noi non siamo un help desk per il tuo progetto!
Abbiamo imparato sulla nostra pelle che senza una tale nota, noi saremo ripetutamente importunati da idioti che pensano che aver pubblicato questo documento renda nostro lavoro risolvere tutti i problemi tecnici del mondo.
Se stai leggendo questo documento perché ti serve aiuto, e ti allontani con l'impressione che non lo puoi ricevere direttamente dagli autori di questo documento, sei tu uno degli idioti in questione. Non porre domande a noi. Noi ti ignoreremo e basta. 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,9% delle volte non saremo noi. A meno che tu non sappia per certo che uno degli autori è un esperto di ciò di cui ti stai occupando, lasciaci stare e saranno tutti più contenti.
Introduzione
Nel mondo degli hacker, [traduzione italiana] 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 un modo che ti farà ricevere più probabilmente una risposta soddisfacente.
Adesso che l'uso di open source [software, solitamente gratuito, il cui codice sorgente è liberamente ottenibile] è diventato diffuso, puoi spesso ricevere risposte tanto buone da altri utenti, più esperti, quanto da hacker. Questa è una Cosa Buona; gli utenti tendono ad essere solo un pochettino più tolleranti al tipo di fallimenti che i principianti spesso hanno. Tuttavia, 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 piacciono veramente problemi difficili e buone domande che fanno pensare 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 avremmo potuto non notare o pensarci sopra altrimenti. Tra gli hacker, “Buona domanda!” è un complimento forte e sincero.
Nonostante questo, gli hacker hanno la reputazione di incontrare domande semplici con quella che sembra ostilità o arroganza. Talvolta sembra che siamo riflessivamente scortesi 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, e 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”).
Ci rendiamo conto che ci sono molte persone che vogliono solo usare il software che scriviamo, e che non hanno alcun interesse nell'imparare dettagli tecnici. Per la maggior parte delle persone, un computer è solamente uno strumento, un mezzo per un fine; hanno cose più importanti da fare e vite da vivere. Noi riconosciamo ciò, e non ci aspettiamo che tutti abbiano un interesse nelle questioni tecniche che ci affascinano. Tuttavia, la nostra maniera di rispondere alle domande è sintonizzata 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 efficaci nelle cose che facciamo meglio.
Siamo (in gran parte) volontari. Sottraiamo tempo dalle nostre vite impegnate per rispondere alle domande, e a volte ne siamo sopraffatti. 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 riprovevole, condiscendente, o arrogante, controlla le tue assunzioni. Non ti stiamo chiedendo di genufletterti a noi — in realtà, la maggior parte di noi non amerebbe nulla più che trattare con te come un eguale e accoglierti nella nostra cultura, se ci metti lo sforzo richiesto per rendere ciò possibile. Ma è semplicemente non efficiente 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 — attento, premuroso, dotato di spirito di osservazione, disposto ad essere un partner attivo nello sviluppare una soluzione. Se non puoi accettare 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 sembrarne uno. Il miglior modo per ricevere una risposta rapida e comprensiva è chiederla come una persona con intelligenza, fiducia in te stesso, ed idee a cui capita solo che serva aiuto su un particolare problema.
(Miglioramenti a questa guida sono benvenuti. Puoi inviare suggerimenti ad
[email protected] o
[email protected]. [NdT: Non so se Eric S. Raymond e Rick Moen capiscono l'italiano, perciò scrivete in inglese. L'email mia è
[email protected].] Nota comunque che questo documento non è inteso per essere una guida generale alla netiquette, e generalmente rifiuteremo suggerimenti che non sono specificamente relativi al ricavare risposte utili in un forum tecnico.)
Prima di chiedere
Prima di porre una domanda tecnica via e-mail, o in un newsgroup, o sulla chat di un sito web, fai ciò che segue:
Prova a trovare una risposta cercando negli archivi del forum dove hai intenzione di pubblicare.
Prova a trovare una risposta cercando sul Web.
Prova a trovare una risposta leggendo il manuale.
Prova a trovare una risposta leggendo una FAQ [Frequently Asked Questions, domande frequentemente poste].
Prova a trovare una risposta con un ispezione o sperimentazione.
Prova a trovare una risposta chiedendo ad un amico esperto.
Se sei un programmatore, prova a trovare una risposta leggendo il codice sorgente.
Quando poni la tua domanda, mostra 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 (cercando nei Google Gruppi [versione italiana] così come nelle pagine Web). Questo potrebbe ben portarti direttamente alla documentazione del pasticcio o ad una discussione di mailing list che risponderà alla tua domanda. Anche in caso contrario, dire “Ho cercato su Google la seguente frase ma non ho trovato nulla che sembrava promettente” è una cosa buona da fare in spedizioni e-mail o news che richiedono aiuto, se non altro perché registra ciò che le ricerche non aiuteranno. Aiuterà anche a dirigere altre persone con problemi simili alla tua discussione collegando i termini di ricerca a quella che sarà speranzosamente la discussione del tuo problema e della soluzione.
Prenditela comoda. Non aspettarti di poter risolvere un problema complicato con pochi secondi di ricerche su Google. Leggi e capisci le FAQ, distenditi, rilassati e prendi un po' in considerazione il problema prima di rivolgerti agli esperti. Credici, potranno riconoscere dalle tue domande quanta lettura e riflessione hai fatto, e saranno più disposti ad aiutare se vieni preparato. Non sparare istantaneamente il tuo intero arsenale di domande solo perchè la tua prima ricerca non ha trovato risposte (o troppe).
Prepara la tua domanda. Riflettici a fondo. Domande che suonano affrettate ricevono risposte affrettate, o proprio nessuna. Quanto più fai per dimostrare ciò avendoci messo attenzione e sforzo per risolvere il tuo problema, tanto più probabilmente riceverai realmente aiuto.
Guardati dal porre la domanda sbagliata. Se ne poni una che è basata su assunzioni fallaci, 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 presumere mai di avere diritto ad una risposta. Non ne hai; non stai, dopo tutto, pagando il servizio. Guadagnerai una risposta, se la guadagnerai, ponendo una domanda considerevole, interessante, e che faccia pensare — una che implicitamente contribuisce all'esperienza della comunità piuttosto che solamente chiedere passivamente conoscenza dagli altri.
D'altra parte, chiarire di essere in grado e disposto ad aiutare nel processo di sviluppare la soluzione è un ottimo inizio. “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 solo qualcuno può rivolgerti nella direzione giusta.
Quando chiedi
Scegli il tuo forum con cura
Sii sensibile nello scegliere dove porre la tua domanda. Probabilmente sarai ignorato, o liquidato come un perdente, se:
invii la tua domanda ad un forum dove è fuori tema
invii una domanda molto elementare ad un forum dove ci si aspettano domande tecniche avanzate, o viceversa
invii lo stesso messaggio a troppi newsgroups diversi
invii un'e-mail personale a qualcuno che non è né un tuo conoscente né personalmente responsabile per risolvere il tuo problema
Gli hacker scartano domande che sono inappropriatamente indirizzate allo scopo di provare a proteggere i loro canali di comunicazione dall'essere soffocati in irrilevanza. Tu non vuoi che questo accada a te.
Il primo passo, quindi, è trovare il forum giusto. Di nuovo, Google e gli metodi per cercare sul Web 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 poste di frequente]), 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 stessi sforzi (incluso leggere quelle FAQ che hai trovato) non trovano una soluzione. La pagina di progetto potrebbe anche descrivere una procedura di segnalazione bug, o avere un link ad una tale procedura: in tal caso, seguilo.
Mandare un'e-mail ad una persona o forum con cui non sei familiare è nella migliore delle ipotesi rischioso. Per esempio, non presumere che l'autore di una pagina web informativa voglia essere il tuo consulente gratuito. Non fare supposizioni ottimistiche su se la tua domanda sarà benvenuta — se non sei sicuro, mandala altrove, o trattieniti proprio dal mandarla.
Quando selezioni un forum Web, newsgroup o mailing list, non confidare nel nome da solo troppo in fondo; cerca una FAQ o regolamento per verificare che la tua domanda sia in tema. Leggi un po' del traffico precedente prima di inviare così avrai un'idea per come si fanno le cose lì. Di fatto, è un'ottima idea fare una ricerca con parole chiave su parole che si riferiscono al tuo problema negli archivi del newsgroup o della mailing list prima di pubblicare. Può darsi che ti trovi una risposta, e in caso contrario ti aiuterà a formulare una domanda migliore.
Non sparare a raffica su tutti i canali di aiuto disponibili in una sola volta, è come urlare e irrita le persone. Usane uno alla volta con calma.
Sappi qual è il tuo argomento! Uno degli sbagli classici è porre domande sull'interfaccia di programmazione di Unix o Windows su un forum dedicato a un linguaggio o libreria o strumento trasportabile a entrambi. Se non capisci perché questa è una cantonata, faresti meglio a non porre 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 molteplici motivi per questo. Uno è semplicemente la dimensione dell'insieme di chi potrebbe potenzialmente rispondere. 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 stanno già ricevendo più della loro giusta parte di messaggi mal indirizzati. Aggiungendoti 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 diventava insopportabile.
I forum Web e IRC diretti verso i principianti spesso danno la risposta più veloce
Il tuo gruppi di utenti locale, o la tua distribuzione Linux, potrebbero pubblicizzare un forum Web o canale IRC dove i principianti possono ricevere aiuto. (In nazioni non di lingua inglese è ancora più probabile che i forum per principianti siano mailing list.) Questi sono buoni primi posti dove 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 Linux (com'è comune oggi), può darsi sia meglio chiedere nel forum/list della distro prima di provare il forum/list di progetto del programma. Gli hacker del progetto protrebbero dire solo: "usa il nostro build".
Prima di inviare a qualsiasi forum Web, controlla se ha una funzione Cerca. Se ce l'ha, prova un paio di ricerche di parole chiave per qualcosa come il tuo problema; potrebbe solo 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 di recente.
C'è una tendenza in aumento che i progetti facciano supporto utenti su un forum Web o canale IRC, con l'e-mail riservata più 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 meglio può rispondere 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 vari buoni motivi per questa politica:
Qualsiasi domanda abbastanza buona da essere posta ad uno sviluppatore sarà di valore anche per l'intero gruppo. Al contrario, se sospetti che la tua domanda è troppo sciocca per una mailing list, non è una scusa per molestare i singoli sviluppatori.
Porre domande sulla lista distribuisce il carico tra gli sviluppatori. Il singolo sviluppatore (specialmente se è il capo del progetto) potrebbe essere troppo impegnato per rispondere alle tue domande.
La maggior parte delle mailing list sono archiviate e gli archivi sono indicizzati da motori di ricerca. Se poni la tua domanda sulla lista e viene risposta, un futuro richiedente potrebbe trovare la tua domanda e la risposta sul Web invece di ripeterla.
Se certe domande sembrano essere poste spesso, gli sviluppatori possono usare quelle informazioni per migliorare la documentazione o il software stesso affinché confonda di meno. Ma se quelle domande sono poste in privato, nessuno ha il quadro completo di quali domande sono poste più spesso.
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 lista/forum degli "utenti". Non presumere che sarai benvenuto sulla list degli sviluppatori, dove probabilmente vivranno 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 appostarti per un po' di giorni prima di pubblicare per imparare gli usi e costumi locali (in realtà questo è un buon suggerimento su qualsiasi lista 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 hai niente in contrario a far inoltrare il tuo messaggio ad altre persone. (Molte persone credono che le e-mail private dovrebbero 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 significativi e specifici
Sulle mailing list, newsgroups o forum Web, l'oggetto è la tua occasione d'oro per attrarre l'attenzione di esperti qualificati in circa 50 caratteri o meno. Non sprecarlo in ciance come "Per favore aiutatemi" (per non parlare di "PER FAVORE AIUTATEMI!!!!"; messaggi con oggetti così si scartano di riflesso). 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:
Puntatore del mouse di X.org 6.8.1 deformato, chipset vid. Fooware MV1005
Più intelligente:
Puntatore del mouse di X.org 6.8.1 sul chipset vid. 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? Questo è specifico a alla versione di X di X.org? Alla versione 6.8.1? Questo è 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 le linee dell'oggetto mostrate. 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 la discussione fino a una risposta piuttosto che inviare la domanda di nuovo.
Se poni una domanda in una risposta, assicurati di cambiare l'oggetto per indicare che stai ponendo una domanda. Un linea 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 una discussione completamente nuova. Questo limiterà il tuo pubblico. Alcuni programmi di mail, come mutt, permettono all'utente di ordinare per discussione e quindi nascondere i messaggi in una discussione comprimendo la discussione. La gente che fa ciò non vedrà 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 ad una discussione, non l'oggetto. Invece apri un'email completamente nuova.
Sui forum Web le regole di buona pratica sono leggermente diverse, perchè i messaggi sono di solito molto più strettamente legati alle discussioni specifiche e spesso invisibili al di fuori di quelle discussioni. 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 questa discussione. Così, a meno che non sei sicuro di voler chiedere solo alle persone correntemente attive nella discussione, iniziane una nuova.
Rendi facile rispondere
Finire la tua richiesta con "Per favore inviate la vostra risposta a…" rende piuttosto improbabile che otterrai una risposta. Se non puoi disturbarti per impiegare anche i pochi secondi richiesti per impostare un campo Reply-to [Rispondi a] corretto nel tuo programma di mail, noi non possiamo disturbarci per impiegare anche 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 programmi di e-mail che permettano questo, procurati un sistema operativo migliore.
Nei forum Web, chiedere una risposta via e-mail è francamente scortese, a meno che non pensi che le informazioni potrebbero essere sensibili (e qualcuno, per qualche motivo sconosciuto, le farà sapere a te ma non all'intero forum). Se vuoi ricevere una copia e-mail quando qualcuno risponde nella discussione, richiedi che il forum Web te la invii; questa funzione è supportata quasi ovunque sotto opzioni come "segui questa discussione", "avvisami delle risposte", ecc.
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 da scommetterci, comunque). Rispondere a domande per pensatori sbadati e trascurati non è gratificante; piuttosto spenderemmo il nostro tempo altrove.
Così esprimere la tua domanda chiaramente e bene è importante. Se non puoi disturbarti per fare ciò, noi non possiamo disturbarci per prestare attenzione. Spendi lo sforzo aggiuntivo per affinare il tuo linguaggio. Non deve essere compassato 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 scortese. (Tutte-minuscole è solo un po' meno irritante, essendo difficile da leggere. Alan Cox può farla franca, ma tu no.)
Più generalmente, se scrivi come un babbeo semi-analfabeta molto probabilmente sarai ignorato. Perciò non usare scorciatoie da messaggistica istantanea. Scrivere "you" come "u" [o, in italiano, "chi" come "ki" o "ti" come "t"] ti fa sembrare un babbeo semi-analfabeta per risparmiare ben due battute. Peggio: scrivere come un l33t script kiddie hax0r [cioè, come viene spiegato in questa pagina NdT] è il bacio della morte assoluto 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 di chi risponderà, scrivi in inglese. Gli hacker impegnati 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 accessibili e standard
Se rendi la tua domanda artificialmente difficile da leggere, sarà più probabilmente ignorata a favore di una che non lo è. Così:
Invia mail in testo semplice, non HTML. (Non è difficile disattivare l'HTML.)
Gli allegati MIME di solito sono OK, ma solo se sono vero contenuto (come un file sorgente o patch allegato), e non solamente un testo standard generato dal tuo programma di mail (come un'altra copia del tuo messaggio).
Non inviare mail in cui interi paragrafi sono singole righe mandate a capo molteplicemente. (Questo rende troppo difficile rispondere solo a parte del messaggio.) Presumi che coloro che risponderanno leggeranno la mail su schermi di testo larghi 80 caratteri e imposta il tuo ritorno a capo di conseguenza, a un po' meno di 80.
Comunque, non mandare a capo dati (come scaricamenti di file di registro o trascrizioni di sessione) ad alcuna larghezza di colonna fissa. I dati dovrebbero essere inclusi così come sono, così coloro che rispondono possono aver sicurezza di star vedendo ciò che hai visto tu.
Non inviare codifica MIME Quoted-Printable ad un forum di lingua inglese. Questa codifica può essere necessaria quando stai pubblicando in una lingua che l'ASCII non copre [come l'italiano, se si usano le vocali accentate NdT], ma molti programmi di e-mail non la supportano. Quando non funzionano, tutti quei segni =20 sparsi per il testo sono brutti e distraenti — oppure potrebbero attivamente sabotare la semantica del tuo testo.
Non aspettarti mai, mai che gli hacker possano leggere formati proprietari di documenti come Microsoft Word o Excel. La maggior parte degli hacker reagiscono a questi all'incirca così come faresti tu se venisse scaricato un mucchio di fumante letame di maiale fuori dalla tua porta. Anche quando possono fronteggiare, si risentono di dover fare così.
Se stai mandando e-mail da una macchina Windows, disattiva la stupida funzione di Microsoft "Sostituisci virgolette semplici con virgolette inglesi". Così eviterai di cospargere la tua mail di caratteri spazzatura.
Nei forum Web, non abusare delle funzioni "smiley" e "HTML" (quando sono presenti). Uno smiley o due sono solitamente OK, ma del testo colorato estroso tende a far pensare alla gente che sei scemo. Usare sul serio troppi smileys e colore e font ti farà sembrare una adolescente allegra, che non è generalmente una buona idea a meno che non sei più interessato al sesso che non a delle risposte.
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 di posta inviata per controllare di star inviando testo semplice senza superflua robaccia attaccata.
Sii preciso ed istruttivo riguardo al tuo problema
Descrivi i sintomi del tuo problema o bug con cura e chiaramente.
Descrivi l'ambiente in cui esso si verifica (macchina, sistema operativo, applicazione, qualunque cosa). Fornisci la distribuzione del tuo fornitore ed il numero di versione (p.e.: "Fedora Core 7", "Slackware 9.1" ecc.).
Descrivi l'indagine che hai fatto per provare a capire il problema da solo prima di porre la domanda.
Descrivi i passi diagnostici che hai fatto per provare da solo a definire chiaramente il problema prima di porre la domanda.
Descrivi qualunque cambiamento recente nel tuo computer o configurazione software possa essere rilevante.
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 segnalare bugs efficacemente]. Ti raccomando fortemente di leggerlo.
Il volume non è precisione
Devi essere preciso e istruttivo. A questo fine non serve semplicemente scaricare 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, potresti sviluppare un rimedio o un workaround [modo per aggirare il problema] tu stesso.
Non sostenere di aver trovato un bug
Quando stai avendo problemi con un software, non sostenere che hai 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. Questo vale anche per pagine web e documentazione; se hai trovato un "bug" nella documentazione, dovresti fornire testo di ricambio e su quali pagine dovrebbe andare.
Ricorda, ci sono molti altri utenti che non stanno sperimentando il tuo problema. Altrimenti ne avresti appreso 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.
Le persone che hanno scritto il software lavorano molto duramente per farlo funzionare meglio possibile. Se sostieni di aver trovato un bug, starai mettendo in dubbio la loro competenza, che potrebbe offenderne alcune anche se hai ragione. È specialmente privo di tatto gridare "bug" nella linea Oggetto.
Ponendo la domanda, è meglio scrivere come se presumi 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 hai fatto casini.
Umiliarsi 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 umiliarsi. "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 di posizionarti migliore che umiliarsi.
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 umiliarti 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 SIG11 in continuazione 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 SIG11 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 di una trascrizione di una sessione di compilazione tipica.
Siccome il punto precedente sembra essere uno arduo da afferrare per molte persone, ecco un'espressione per ricordarti: "Tutti i diagnostici sono del Missouri." Il motto ufficiale di quello stato US è "Show me" [mostrami] (meritato nel 1899, quando il membro del Congresso Willard D. Vandiver disse "Vengo da una nazione che alleva granturco e cotone e lappole e Democratici, e la vaporosa eloquenza né mi convince né mi soddisfa. Sono del Missouri. Devi mostrarmi.") Nel caso dei diagnostici, non è una questione di scetticismo, ma piuttosto un preciso bisogno funzionale di vedere qualunque cosa sia più vicina possibile alla stessa cruda evidenza che vedi tu, piuttosto che le tue congetture e riassunti. Mostraci.
Descrivi i sintomi del tuo problema in ordine cronologico
Gli indizi più utili nel capire qualcosa che è andato storto spesso si trovano negli eventi immediatamente precedenti. Così, la tua descrizione dovrebbe descrivere precisamente cosa hai fatto, e cosa ha fatto la macchina, fino ad arrivare al disastro. Nel caso di processi in linea di comando, avere una trascrizione della sessione (p.e., usando la script utility) e citare una ventina di righe relative è molto utile.
Se il progamma che ha provocato il disastro ha opzioni diagnostiche (come -v per verboso), prova a selezionare opzioni che aggiungeranno utili informazioni di debug alla trascrizione. Ricordati che di più non è necessariamente meglio; prova a scegliere un livello di debug che informerà piuttosto che soffocare il lettore in spazzatura.
Se la tua descrizione finisce per essere lunga (più di circa 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 (invece di riferire un bug), inizia descrivendo l'obiettivo. Solo allora descrivi il particolare passaggio verso ciò su cui 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. Vengono per aiuto con il passo, ma non si rendono conto che il percorso è sbagliato. Può richiedere uno sforzo considerevole 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 riesco a far prendere un valore RGB esadecimale al color picker di FooDraw.
La seconda versione della domanda è intelligente. Permette una risposta che suggerisce uno strumento più adatto al compito.
Non chiedere alle persone di rispondere via e-mail 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, gli aiutanti ricevono parte del loro rispetto per rispondere 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 di chi risponde 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'e-mail 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 coloro che risponderanno facciano (fornire indicazioni, inviare codice, controllare la tua patch, qualunque cosa). Questo metterà a fuoco i loro sforzi e implicitamente metterà un limite superiore al tempo e all'energia che uno che risponde deve concedere 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 impegnato.
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 malfunzionante, è di solito più intelligente chiedere a qualcuno di spiegare cos'ha che non va che chiedere a qualcuno di sistemarlo.
Quando fai domande sul codice
Non chiedere ad altri di fare il debug del tuo codice che non funziona senza dare un accenno su che sorta di problema dovrebbero cercare. Postare poche centinaia di linee di codice, dicendo "non funziona", ti farà ignorare. Postare una dozzina di linee di codice, dicendo "dopo la linea 7 mi aspettavo di vedere <x>, ma invece si è verificato <y>" ti farà ottenere un responso molto più probabilmente.
Se vuoi semplicemente una critica del codice, dillo apertamente, e assicurati di menzionare quali aree pensi che possano particolarmente necessitare di analisi e perché.
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 potrebbero almeno darti un consiglio.
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 sbrigative 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 alcunché.
La cortesia non fa mai male, e a volte aiuta
Sii cortese. Usa "Per favore" e "Grazie per la vostra attenzione" o "Grazie per la vostra considerazione". Rendi chiaro che apprezzi il tempo che le persone spendono aiutandoti gratis.
Ad essere sinceri, questo non è tanto importante quanto (e non è un'alternativa a) essere grammaticalmente corretti, 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 precedente 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 coloro che rispondono dopo, o forse esprimere la cortesia in un modo diverso, come dicendo "Grazie per la vostra attenzione" o "Grazie per la vostra 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 ringraziali di nuovo per il loro aiuto. Se il problema ha attirato interesse generale in una mailing list o newsgroup, è appropriato pubblicare il seguito lì.
Ottimamente, la risposta dovrebbe essere alla discussione iniziata col messaggio della domanda originale, e dovrebbe avere 'SISTEMATO' 'RISOLTO' o un'espressione ugualmente ovvia nell'oggetto. Nelle mailing list veloci, uno che potenzialmente potrebbe rispondere che vede una discussione riguardo "Problema X" terminante con "Problema X - SISTEMATO" sa di non dover sprecare il suo tempo senza nemmeno leggere la discussione (a meno che non trovi personalmente il Problema X interessante) e può quindi usare quel tempo risolvendo un problema diverso.
Il tuo seguito non deve essere lungo e involuto; un semplice "Salve — era un cavo di rete guasto! 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 reale 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 il 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 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 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. La reputazione che calmare quel fremito meriterà ti sarà molto, molto utile la prossima volta che ti servirà di 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ì manda tale patch al mantenitore.
Tra gli hacker, questo tipo di comportamento di seguito è 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 alla discussione 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 te le fai imboccare col cucchiaio.
Non dovresti essere offeso da questo; per gli standard hacker, chi ti risponde 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 di seguito: "Che cos'è uno zentry?" Ed ecco una buona domanda di seguito: "OK, ho letto la pagina di manuale e gli zentry sono citati solo sotto le opzioni -z e -p. Nessuno dei due dice niente su come togliere gli zentry. È uno di questi o qui mi sfugge qualcosa?"
Trattare con la maleducazione
Molta di quella che sembra maleducazione negli ambienti hacker non è intesa ad offendere. Piuttosto, è il prodotto dello stile di comunicazione diretto, che-taglia-attraverso-le-stronzate che è naturale per le persone che sono più interessate a risolvere problemi che a far sentire gli altri a proprio agio.
Quando percepisci maleducazione, 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 maleducazione 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 un 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 flamewar [guerra di insulti] è 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 eccentricità se pensi di noi come dei cerebrolesi. Fai pure. Non ce ne importa; ci piace essere qualunque cosa siamo, e generalmente abbiamo un salutare scetticismo sulle etichette cliniche.)
Nella prossima sezione, parleremo di una diversa questione; il tipo di "maleducazione" 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, sostenere di essere stato assalito verbalmente, pretendere delle scuse, gridare, trattenere il respiro, minacciare cause legali, lamentarsi con i datori di lavoro delle persone, lasciare il coperchio del WC alzato, ecc. Invece, ecco cosa fare:
Fattene una ragione. È 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 e-mail privata: Non è così che funziona. Né è utile insistere che sei stato personalmente insultato quando qualcuno commenta che una delle tue asserzioni 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 modo) 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 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 flamewar. La maggior parte delle offese fannno meglio ad essere ignorate — dopo che hai controllato se sono veramente offese, non indicazioni 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, istruzione 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 quella domanda senza presupporre l'uso di un metodo che può darsi non sia appropriato. Domande di questa forma spesso indicano una persona che non è solamente 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 meglio il loro problema.
D:
Come posso configurare il mio prompt dei comandi?
R:
Se sei abbastanza intelligente per porre questa domanda, sei abbbastanza intelligente per RTFM e scoprirlo da solo.
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, istruzione 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 di meglio da fare. Vedendo qualcosa del genere, la mia reazione è normalmente una delle seguenti:
hai nient'altro da aggiungere a ciò?
oh, che peccato, spero che tu riesca a farlo sistemare
e esattamente io che c'entro?
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.
Nota: puoi porre domande relative a macchine Windows se riguardano un programma che ha un Windows build ufficiale, o interagisce con macchine Windows (cioè, Samba). Solo non stupirti della risposta che il problema è con Windows e non con il programma, perché Windows funziona così male in generale che questo è molto spesso il caso.
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 non capisca assolutamente un'acca. Reclami straordinari richiedono evidenza straordinaria; 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.)
Nota: domande sull'istallare Linux potrebbero essere appropriate se sei su un forum o mailing list su una particolare distribuzione, e il problema è con quella distro; oppure su forum degli user groups locali. In questo caso, assicurati di descrivere gli esatti dettagli del fallimento. Ma prima fai un'attenta ricerca, con "linux" e tutti i componenti hardware sospetti.
D:
Come posso forzare la root/rubare i privilegi degli operatori dei canali/leggere l'e-mail di qualcuno?
R:
Sei un malvivente per voler fare cose del genere e un idiota per chiedere ad un hacker di aiutarti.
Domande Buone e Cattive
Infine, 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 solo "STFW" come risposta.
Intelligente: Ho usato Google per provare a trovare "Foonly Flurbamatic 2600" sul Web, ma non ho ottenuto risultati utili. Posso ricevere un'indicazione per informazioni di programmazione 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 pippo. Perché è rotto?
Il richiedente presume che qualcun'altro l'abbia fatta fuori dal vaso. Idiota arrogante…
Intelligente: Il codice del progetto pippo non si compila sotto Nulix versione 6.2. Ho letto la FAQ, ma non c'è nulla riguardo ai problemi relativi a Nulix. Ecco una trascrizione del mio tentativo di compilazione; è qualcosa che ho fatto?
Il richiedente ha specificato l'ambiente, letto la FAQ, sta mostrando l'errore, e non sta presupponendo che i suoi problemi siano colpa di qualcun'altro. Questo qui potrebbe essere degno di qualche attenzione.
Stupida: Sto avendo problemi con la mia scheda madre. Qualcuno può aiutare?
La risposta di J. Hacker Qualsiasi a questo 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 ciò 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 eseguire per definire chiaramente il problema?
Questa persona, d'altra parte, sembra degna 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 importante differenza tra chiedere "Datemi una risposta" e "Per favore aiutatemi a scoprire quali altri diagnostici posso eseguire per raggiungere l'illuminazione."
In realtà, la forma dell'ultima domanda è strettamente basata su un vero caso che avvenne nell'agosto 2001 sulla linux-kernel mailing list (lkml). Io (Eric) ero quello che poneva 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 per loro essere 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 avesse funzionato bene 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. Abbi pazienza: la persona con la tua risposta potrebbe essere in un altro fuso orario e star dormendo. Oppure potrebbe essere che la tua domanda non era ben formata per iniziarci.
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 SpikeSource 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 10.000 utenti per sviluppatore. Non è possibile e basta che una persona tratti le chiamate per supporto di oltre 10.000 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 maleducate 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 proprio nessuna. Non indicare a nessuno un percorso sbagliato semplicemente perché è divertente sembrare un esperto. Sii umile e sincero; 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 solo mormorare RTFM è a volte giustificato quando si risponde a qualcuno che è solo uno sciattone pigro, un consiglio a della documentazione (anche se è solo un suggerimento di cercare con Google 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. Reinquadra 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 ricerche per rispondere alla domanda, dimostra le tue abilità piuttosto che scrivere come se avessi tirato fuori 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 è 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 alcune domande stupide di esempio ed ispirato la sezione "Come Dare Una Buona Risposta". Mikhail Ramendik ha contribuito sia ad alcuni suggerimenti particolarmente utili per miglioramenti.
