[bglug] How To Ask Questions The Smart Way
Jimmi
bglug@lists.linux.it
Sun, 28 Apr 2002 21:44:15 +0200
--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Io la traduzione l'ho completata grazie ai consigli di Raymond. Non so
come ci si comporta in questi casi (nel senso se e` opportuno
pubblicarla lo stesso); io comunque l'allego, se intendete usarla per il
sito fatemi sapere ;)
Ciao
--
_ _ ---------------------------------------
__(_)__ __ __ __ (_) | ... sembra di sentirlo ancora dire al |
/ / / _ `_ \/ _ `_ \/ / | mercante di liquori: "tu che lo vendi |
_/ /_/_//_//_/_//_//_/_/ | cosa ci compri di migliore?" FdA |
|__/ ==# bglug.linux.it #== ---------------------------------------
--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: attachment; filename=come-porre-domande
Content-Transfer-Encoding: 8bit
Come fare domande in modo intelligente
Copyright© 2001 di Eric S. Raymond
Tradotto da R. Franceschini nell'aprile del 2002.
La versione originale può essere trovata presso il sito:
http://www.tuxedo.org/~esr/faqs/hacker-howto.html
-----------------------------------------------------------------------
Indice
Traduzioni
Introduzione
Prima Di Domandare
Quando Domandi
Come Interpretare Le Risposte
Sulle Reazioni Da Perdente
Domande Da Non Porre
Domande Giuste E Domande Sbagliate
Se Non Ottenete Alcuna Risposta
Risorse
-----------------------------------------------------------------------
Traduzioni
La traduzione di questo documento è disponibile anche in francese .
-----------------------------------------------------------------------
Introduzione
Nel mondo degli hackers , la risposta che ottieni alle tue domande
tecniche dipende più dal modo di formulare la domanda che dalla
difficoltà della risposta stessa. Questa guida ti insegnerà a porre
le questioni in modo che ti sia più probabile ottenere risposte
soddisfacenti.
La prima cosa da capire è che agli hackers piacciono realmente i
problemi complicati e le domande che, poste giustamente, provochino il
ragionamento. Se noi non la pensassimo così, non saremmo qui. Se ci dai
problemi interessanti da masticare, noi te ne saremo grati; le buone
domande sono uno stimolo e un regalo. Le buone domande ci aiutano
a sviluppare la nostra conoscenza e spesso rivelano problemi che
altrimenti non potremmo individuare od immaginare. Fra gli hackers,
"bella domanda!" è un sincero complimento.
Malgrado questo, gli hackers hanno la reputazione di rispondere alle
domande semplici in un modo che può sembrare ostile o arrogante. A
volte può sembrare che abbiamo degli atteggiamenti scortesi verso i
"newbies" e gli ignoranti. Ma non è la verità.
Noi siamo, senza remore, ostili a quanti sembrano essere poco disposti
a pensare o fare la propria parte prima di porre domande. Gente come
questa sono una perdita di tempo, prendono senza dare niente in cambio,
ci fanno perdere tempo; tempo che potremmo impegnare con domande più
interessanti o con persone più degne di una risposta. Noi chiamiamo
queste persone "losers", perdenti (e per i motivi storici a volte
scriviamo "lusers").
Noi ci rendiamo conto che molta gente vuole solo usare il software che
scriviamo e non è interessata ad imparare i dettagli tecnici. Per la
maggior parte della gente, un computer è soltanto un attrezzo, un mezzo
per raggiungere un fine; essi hanno cose più importanti da fare e per
cui vivere. Noi lo riconosciamo e non ci aspettiamo che tutti siano
interessati agli argomenti tecnici che ci affascinano. Tuttavia, il
nostro modo di rispondere alle domande è tarato per gente che ha questo
interesse ed è disposta a partecipare attivamente alla risoluzione di
problemi. Questo atteggiamento non cambierà. Né dovrebbe; se così
fosse, saremmo meno efficaci nelle cose che sappiamo fare meglio.
Siamo (in gran parte) volontari. Noi impieghiamo tempo prezioso per
rispondere alle domande, e talvolta veniamo sommersi da esse. Perciò
filtriamo senza pietà. In particolare, scartiamo le domande della gente
che sembra essere perdente per impiegare in modo più efficiente il
nostro tempo con i vincenti.
Se trovi questo atteggiamento antipatico, pomposo, od arrogante,
verifica i tuoi presupposti. Non stiamo chiedendoti di genufletterti di
fronte a noi - infatti, la maggior parte di noi non vorrebbe altro che
trattare con te da pari ed accoglierti nella nostra cultura, se solo ti
sforzassi per renderlo possibile. Ma aiutare gente che non è disposta
ad aiutarsi da sola è semplicemente poco efficiente. Se non puoi
convivere con questa discriminazione, ti suggeriamo di pagare per un
contratto di assistenza anzichè chiedere agli hackers di donarti il
loro aiuto.
Se decidi di chiedere aiuto a noi, significa che non vuoi appartenere
ai perdenti. Non vuoi nemmeno assomigliarvi. La maniera migliore di
ottenere una risposta rapida ed efficace è di porre la domanda da
vincitore/trice, domandare come una persona intelligente e sicura, a
cui serve un aiuto su un problema in particolare.
(miglioramenti a questa guida sono bene accolti. Potete spedire i vostri
suggerimenti per posta a esr@thyrsus.com . Nota tuttavia che questo
documento non è inteso per essere una guida generale alla netiquette
e che rifiuterò i suggerimenti non specificamente in relazione
all'ottenimento di risposte utili in un forum tecnico.)
------------------------------------------------------------------------
Prima di domandare
Prima di porre una domanda tecnica via email, ad un newsgroup, o su una
chat, fai le seguenti cose:
1. Cerca la risposta sul manuale.
2. Cerca la risposta nelle FAQ.
3. Cerca la risposta in rete.
4. Chiedi ad un amico esperto.
Quando poni una domanda mostra di aver prima eseguito queste
azioni; questo aiuterà a dimostrare che non sei soltanto un pigro
approfittatore/trice e non stai sprecando il tempo altrui. Meglio
ancora, dimostra cosa hai imparato facendo questo. Ci piace rispondere
alle domande di gente di gente che dimostra di poter imparare dalle
risposte.
Prepara la domanda. Pensaci sopra. Domande affrettate ottengono solo
risposte affrettate, o nessuna del tutto. Più fai per dimostrare che ti
sei sforzato/a per risolvere il tuo problema prima di chiedere aiuto,
più probabilità hai di ottenere aiuto.
Evita di porre domade sbagliate. Se tu fai una domanda insensata, il
Sig. Hacker Qualsiasi probailmente ti risponderà con una altrettanto
insensata risposta mentre pensa "Che domanda stupida" e sperando che il
fatto di ottenere quello che hai domandato anzichè quello di cui hai
bisogno ti insegni qualcosa.
Non pensare che una risposta ti sia dovuta. Non è così; dopo
tutto tu non stai pagando per l'assistenza. Ti guadagnerai una
risposta, se te la guadagnerai, ponendo delle domande interessanti
e che stimolino il ragionamento; delle domande che contribuiscano
a migliorare l'esperienza della comunità, piuttosto di quelle che
richiedono semplicemente nozioni.
D'altra parte, far capire che vuoi e puoi aiutare a raggiungere la
soluzione è un buon punto di partenza. Domande come "Qualcuno può darmi
un'indicazione?", "Cosa manca al mio esempio?" e "C'è un sito che
dovrei consultare?" hanno più probabilità di ottenere una risposta che
"Prego inviarmi la procedura esatta da utilizzare." perchè dimostrano
chiaramente che tu vuoi raggiungere la soluzione, se solo qualcuno ti
mette sulla strada giusta.
-----------------------------------------------------------------------
Quando domandi
Scegli con attenzione il forum
Poni attenzione nello scegliere dove indirizzare la domanda. E'
probabile che tu venga ignorato o segnato come perdente se:
* indirizzi la domanda su un forum dove sei fuori tema
* poni una domanda elementare in un forum per problemi avanzati o
viceversa
* indirizzi la domanda a troppi forum contemporaneamente
Gli hacker scartano le domande considerate fuori tema per cercare di
proteggere i loro canali di comunicazione dall'essere trascinati fuori
tema. Tu non vorresti che succedesse a te
In generale, le domande poste ad un forum pubblico ben selzionato hanno
più probabilità di ottenere risposte utili rispetto a quelle poste ad
un forum riservato. Ci sono molte ragioni per questo. Una ragione è
semplicemente la quantità dei potenziali corrispondenti. Un'altra è la
dimensione dell'utenza; gli hacker preferiscono fornire risposte che
educhino molta gente piuttosto che servire solo a pochi.
-----------------------------------------------------------------------
Quando possibile utilizza le mailing-list del progetto
Quando un progetto è provvisto di mailing-list di sviluppo, scrivi a
questa piuttosto che ai diversi sviluppatori, anche se credi di
conoscere chi può rispondere meglio alla tua domanda. Controlla la
documentazione del progetto e la relativa homepage per vedere se esiste
l'indirizzo di una mailing-list, ed usala. Ci sono parecchi buoni
motivi per questo:
* Ogni domanda buona per uno sviluppatore sarà preziosa per il gruppo
intero. D'altra parte, se pensi che la tua domanda sia troppo stupida
per la mailing-list, questo non costituirà una scusa per disturbare i
diversi sviluppatori.
* Porre le domande in mailing-list permette di distribuire il carico
fra i vari sviluppatori. Lo sviluppatore specifico (particolarmente
se è il coordinatore di progetto) può essere troppo occupato per
rispondere alle tue domande.
* La maggior parte delle mailing-list sono archiviate, e gli archivi
sono indicizzati dai motori di ricerca. Qualcuno potrebbe trovare la
vostra domanda e la risposta in rete invece di porla di nuovo.
* Se determinate domande sono poste spesso, gli sviluppatori possono
usare questa informazione per migliorare la documentazione o il
software e renderlo più chiaro. Ma se le domande sono poste
privatamente, nessuno ha la visione d'assieme di cosa viene chiesto
più spesso.
Se non trovi l'indirizzo della mailing-list di progetto, ma soltanto
l'indirizzo del responsabile, scrivi pure a lui. Ma anche in questo
caso, non dare per scontato che la mailing-list non esista. Menziona
nel messaggio che hai provato ma non hai potuto trovare la mailing-list
appropriata. Inoltre indica che accetti che il tuo messaggio venga
reindirizzato ad altri. (Molta gente pensa che i messaggi privati
debbano rimanere riservati, anche se non contengono niente di segreto.
Permettendo che il vostro messaggio sia reindirizzato dà al vostro
corrispondente la possibilità di scegliere come trattarlo)
-----------------------------------------------------------------------
Scrivi in un linguaggio chiaro e grammaticalmente corretto.
L'esperienza ci insegna che le persone che scrivono in modo negligente
e trasandato sono solitamente negligenti e trasandate nel pensare e nel
programmare (ci puoi scommetere sopra). Rispondere alle domande di chi
pensa in modo negligente e trasandato non ricompensa; preferiremmo
spendere in altro modo il nostro tempo.
E' quindi importante esporre la tua domanda in modo chiaro. Se non fai
attenzione a questo, noi non faremmo attenzione a te. Sforzati in tutti
i modi di rendere pulito il tuo linguaggio. Non deve essere per forza
rigido o formale; la cultura hacker valorizza l'informalità, il
linguaggio colorito ed emotivo, se usato correttamente. Ma deve essere
preciso; si deve capire che stai pensando e sei attento.
Usa i periodi, la punteggiatura e le maiuscole correttamente. Non
confondere "hanno" con "anno" o "avessi" con "avrei". Non SCRIVERE
TUTTO IN MAIUSCOLO, questo significa urlare ed è considerato scortese.
(tutto in minuscolo è solo un pò meno noioso, poichè è difficile da
leggere. Alan Cox può farlo, tu no.)
Generalmente se scrivi come un semi-analfabeta sarai molto
probabilmente ignorato. Scrivere in linguaggio per "iniziati" decreterà
la tua morte sul forum, ed è il miglior modo per non ricevere risposte
(o, nel migliore dei casi, di ricevere commenti pesanti e sarcastici).
Se stai indirizzando le domande ad un forum che non usa la tua lingua
madre, saranno tollerati alcuni errori di grammatica e di ortografia,
ma non la pigrizia nel cercare di evitarli (e solitamente si nota la
differenza). Inoltre, a meno che tu non conosca la lingua del tuo
corrispondente, scrivi in inglese. Gli hackers impegnati tendono
semplicemente ad ignorare le domande in linguaggi che non capiscono, e
l'inglese è la lingua di lavoro in Internet. Scrivendo in inglese
minimizzi la possibilità che la tua domanda venga scartata senza essere
letta.
-----------------------------------------------------------------------
Invia le domande in formati facili da comprendere
Se artificiosamente rendete la vostra domanda difficile da leggere, è
molto probabile che essa venga scavalcata da una che non lo è. Quindi:
* Invia la posta come testo normale, non HTML. (è facile disattivare
l'HTML.)
* Gli allegati MIME sono solitamente ammessi ma soltanto se il
contenuto lo giustifica (come file sorgente o patch) e non se sono
soltanto scatole generate dal vostro client di posta (come un'altra
copia del vostro messaggio).
* Non inviare messaggi in cui interi paragrafi siano singole righe.
(questo rende difficile rispondere ad una parte del messaggio.)
Supponi sempre che il tuoi corrispondenti leggano la posta su uno
schermo da 80 caratteri e regola il ritorno a capo di conseguenza,
preferibilmente a qualcosa di meno di 80 caratteri.
* Non spezzare righe di dati (come file log o trascrizioni da
terminale). I dati dovrebbero essere allegati come sono, così che il
tuo corrispondente sia sicuro di vedere quello che tu hai visto.
* Non inviare messaggi in codice MIME a forum in lingua inglese. Questa
codifica è necessaria quando scrivi in linguaggi che non sono
supportati in ASCII, ma parecchi agenti di posta non lo supportano.
Se questi falliscono, tutti quegli =20 sparsi nel testo sono brutti e
distraggono.
* Mai aspettarsi che un hacker sia in grado di leggere documenti in
formati proprietari come Microsoft Word. Molti hacker, ricevendo
questi documenti, reagiscono più o meno come voi reagireste trovando
un mucchio di sterco di maiale fumante sugli scalini di casa.
* Se state spedendo posta da una macchina Windows, disattivate
quella stupida opzione "Smart Quotes". In questo modo eviterete di
cospargere il vostro messaggio di spazzatura.
* Se stai usando un agente di posta con interfaccia grafica (come
Netscape Messenger, MS Outlook e simili) ricordarsi che può violare
queste regole se utilizzato con le opzioni di default. La maggior
parte di questi client hanno un comando a menu tipo "Vedi sorgente".
Ogni tanto utilizza questo comando sui messaggi da te inviati per
verificare che tu stia inviando solo testo, senza inutili orpelli.
-----------------------------------------------------------------------
Usa intestazioni significative e specifiche
Scrivendo a mailing-lists o newsgroups, l'oggetto è l'occasione d'oro
per attirare l'attenzione di esperti qualificati in 50 caratteri o
meno. Non sprecarla con frasi a vanvera come "Per favore aiutatemi"
(evitate "PER FAVORE AIUTATEMI!!!!; messaggi con questo oggetto
vengono automaticamente scartati). Non provate ad impressionarci con
l'intensità del vostro tormento; usate invece lo spazio per una
descrizione super-coincisa del vostro problema.
Una buona convenzione per le intestazioni, usata da molte
organizzazioni di assistenza tecnica, è "oggetto-deviazione". La parte
dell'oggetto specifica quale parte o gruppo di parti sta avendo
un problema e la parte di deviazione descrive la deviazione dal
comportamento previsto.
Stupido:
AIUTO! Il video non funziona correttamente sul mio laptop!
Intelligente:
Malfunzionamento del puntatore del mouse in XFree86 4,1, chipset video
MFooware V1005
Più intelligente:
Puntatore del mouse in XFree86 4,1 con Fooware MV1005 video chipset -
malfunzionamento
Lo scrivere la descrizione secondo lo schema "oggetto-deviazione" ti
aiuterà a ragionare sul problema più in dettaglio. Quali sono gli
effetti? Solo il puntatore del mouse o anche altri oggetti grafici?
Succede solo con XFree86? Solo nella versione 4.1? Succede solo con
chipset video Fooware? Solo con il modello MV1005? Un hacker che legge
il risultato può capire immediatamente qual'è l'oggetto del messaggio
ed il tipo di problema che hai.
Se in una replica includi una domanda, assicurati di cambiare l'oggetto
del messaggio per indicare che stai ponendo una domanda. Un'oggetto
come "Re: test" o "Re: nuovo bug" è poco probabile che attragga
l'attenzione di cui hai bisogno. Inoltre cita i messaggi precedenti il
minimo indispensabile per farti capire da nuovi lettori.
-----------------------------------------------------------------------
Sii preciso ed esauriente descrivendo il problema
* Descrivi con attenzione e chiaramente i sintomi del tuo problema o
bug.
* Descrivi l'ambiente in cui si presenta (macchina, OS, applicativo e
quant'altro).
* Descrivi le ricerche che hai fatto per provare a comprendere il
problema prima di porre la domanda.
* Descrivi i passi compiuti per diagnosticare e provare ad individuare
il problema prima di porre la domanda.
* Descrivi tutti i recenti cambiamenti nella configurazione del
software o del computer che potrebbero averne influenzato il
funzionamento.
Fai del tuo meglio per anticipare le domande che un hacker ti potrebbe
porre, e rispondi in anticipo nella tua richiesta di aiuto.
Simon Tatham ha scritto un saggio eccellente intitolato "How to Report
Bugs Effectively". Ti suggerisco caldamente di leggerlo.
-----------------------------------------------------------------------
Quantità non è precisione
Devi essere preciso ed esauriente. Ma non raggiungi questo obbiettivo
semplicemente inserendo enormi quantità di codice o dati nella
richiesta di aiuto. Se riporti un test lungo e complicato che manda in
crisi il programma, prova a tagliarlo e renderlo più contenuto
possibile.
Questo è utile per almeno tre motivi. Uno: se mostri di sforzarti per
semplificare la domanda hai più probabilità di ottenere una risposta.
Due: semplificando la domanda è più probabile che tu ottenga la
risposta giusta. Tre: mentre lavori per migliorare la descrizione del
bug, potresti trovare la soluzione da solo/a.
-----------------------------------------------------------------------
Descrivi i sintomi del problema, le non tue congetture
Non aiuta dire all'hacker cosa tu pensi stia causando il problema. (se
le tue teorie di diagnosi fossero così buone, chiederesti aiuto ad
altri?) Quindi assicurati di scrivere i puri sintomi di quello che non
funziona, piuttosto che le tue interpretazioni o teorie. Lascia che
siano gli altri ad interpretare e diagnosticare.
Stupido:
Mentre compilo il kernel ottengo degli errori di interfaccia SIG11, e
sospetto che una traccia della scheda madre sia fessurata. Qual'è la
via migliore per verificare?
Intelligente:
Il mio computer assemblato con K6/233, motherboard FIC-PA2007 (chipset
VIA Apollo VP2) e 256MB Corsair PC133 SDRAM mi dà spesso errori SIG11
circa 20 minuti dopo averlo acceso e durante la compilazione del
kernel, ma mai nei primi 20 minuti. Quando riavvio subito l'orologio di
sistema non riparte , ma se lo lascio fermo una notte si. Swappare la
RAM non aiuta. Allego la sezione interessata del log di compilazione.
-----------------------------------------------------------------------
Descrivi i sintomi del problema in ordine cronologico
Gli indizi più utili per capire perchè qualcosa è andato male stanno
spesso negli eventi precedenti. Quindi la vostra richiesta dovrebbe
descrivere esattamente cosa hai fatto, e cosa ha fatto la macchina fino
al momento dell'errore. In caso di processi da linea di comando, avere
un log della sessione (ad esempio utilizzando un'utilità dello script)
e citare una ventina di righe è molto utile.
Se il programma che è saltato ha delle opzioni di diagnostica (quale -v
per verbose), prova ad analizzare con attenzione a quali opzioni
possono aggiungere informazioni utili ai log.
Se la vostra richiesta diventa lunga (più di quattro paragrafi), può
essere utile descrivere brevemente il problema all'inizio, quindi far
seguire la descrizione cronologica. In questo modo gli hackers sapranno
a cosa fare attenzione nella vostra richiesta.
-----------------------------------------------------------------------
Non chiedere risposte in privato
Gli hackers pensano che il processo di risoluzione dei problemi deve
essere pubblico e trasparente, in modo che un primo tentativo di
risposta possa e debba essere corretto se qualcuno con maggiori
conoscenze si accorge che è incompleta o non corretta. Inoltre, essi
si sentono ricompensati per la loro risposta dal fatto di essere
riconosciuti come competenti da chi li ascolta.
Quando chiedi una risposta privata, voi interrompete sia il processo
che la ricompensa. Non farlo. Sarà il corrispondente a scegliere se
rispondere privatamente; e se lo fa è solitamente perché pensa che la
domanda sia troppo mal posta o ovvia per essere interessante per altri.
Esiste un'eccezione circoscritta a questa regola. Se pensi che la tua
domanda provocherà molte risposte tutte molto simili, allora le parole
magiche sono "scrivete a me ed io ricapitolerò le risposte per il
gruppo". E' cortese tentare di impedire che la lista o il newsgroup
vengano sommersi da una pletora di messaggi sostanzialmente identici,
ma devi mantenere la promessa di ricapitolare.
-----------------------------------------------------------------------
Esprimi la tua domanda esplicitamente
Domande "aperte" sono percepite come perdite di tempo senza fine. Le
persone che possono darvi una risposta utile sono anche le più
impegnate (se non altro perchè fanno quasi tutto il lavoro). Queste
persone sono allergiche a perdite di tempo, così tendono ad
essere allergiche alle domande senza un oggetto preciso.
E' più probabile che tu ottenga una risposta se esprimi esplicitamente
cosa vuoi ottenere dal tuo corrispondente (invio di puntatori, codice,
verifica della patch o altro) Questo concentra il suo sforzo e pone
implicitamente un limite al tempo e all'energia che il cosrrispondente
impegnerà per aiutarti. Questa è una buona cosa.
Per capire il mondo in cui vivono gli esperti, pensa all'esperienza
come ad una risorsa abbondante e al tempo come ad una limitata. Minore
è l'impegno di tempo che tu implicitamente chiedi e maggiore è
la probabilità che tu ottenga una risposta da qualcuno realmente
impegnato.
Quindi è utile circoscrivere la domanda, per per diminuire lo sforzo
richiesto per inquadrarne il contesto; ma questo non sempre la rende
più facile. Quindi, ad esempio "puoi dirmi dove trovo una buona
spiegazione a X?" è solitamente più intelligente di "mi spieghi X, per
favore?". Se avete del codice che non funziona, è di solito più
intelligente chiedere di spiegarti cosa è sbagliato piuttosto che
chiedere di ripararlo.
-----------------------------------------------------------------------
Non porre domande per i tuoi compiti a casa
Gli hacker capiscono subito se stai cercando di risolvere i tuoi
compiti; la maggior parte di noi li hanno già dovuti fare a loro volta.
Queste domande servono per far lavorare te, così che tu possa
imparare dall'esperienza. Puoi chiedere qualche spunto, ma non l'intera
soluzione.
-----------------------------------------------------------------------
Domande superflue
Resisti alla tentazione di chiudere la tua richiesta di aiuto con
domande inutili come "Qualcuno mi può aiutare?" o "Esiste una
risposta?". Primo: se tu hai descritto il problema in modo appena
competente, queste domande sono nel migliore dei casi superflue.
Secondo: siccome sono superflue, gli hackers le troveranno noiose; e ci
sono buone probabilità che ti arrivi la logica risposta "Si, qualcuno
ti può aiutare" o "No, non possiamo aiutarti".
-----------------------------------------------------------------------
Non marcare la tua richiesta come "Urgente", anche se lo è.
Questo è un tuo problema, non il nostro. Richiedere urgenza è quasi
sempre controproducente: la maggior parte degli hacker semplicemente
cancellerà il tuo messaggio perchè è un tentativo scortese ed egoista
di ottenere un'attenzione immediata e speciale.
-----------------------------------------------------------------------
La cortesia non è mai dannosa, e qualche volta aiuta
Sii cortese. Usa "per favore" e "ringrazio anticipatamente". Evidenzia
il fatto che tu apprezzi il tempo che la gente ti regala per aiutarti.
Ad essere onesti, questo punto non è importante quanto (e non
può sostituire) essere grammaticalmente corretti, chiari, precisi
ed esaurienti, non usare linguaggi proprietari ecc.; gli hacker
generalmente preferiscono rapporti scarni ma tecnicamente precisi sui
bug piuttosto che gentili vaghezze. (Se questo ti confonde, ricordati
che noi valutiamo una domanda da quello che ci insegna.)
Comunque, se hai spiegato i tuoi argomenti tecnici in una riga, la
cortesia aumenta le probabilità di ottenere una buona risposta.
(Dobbiamo annotare che l'unica seria obiezione che abbiamo ricevuto
da hacker veterani è sulla raccomandazione di usare "ringrazio
anticipatamente". A qualche hacker questo sembra un'intenzione di non
ringraziare nessuno dopo. Noi raccomandiamo di fare entrambe le cose.)
-----------------------------------------------------------------------
Invia un breve riscontro alla soluzione
Dopo che il problema è stato risolto invia un messaggio a quanti ti
hanno aiutato; spiega a loro come ne sei uscito/a e ringraziali ancora
per l'aiuto. Se il problema ha attratto l'attenzione in una mailing
list o su un newsgroup, è meglio inviare lì il messaggio.
Il tuo rapporto non deve essere lungo e dettagliato; un semplice
"Ciao, era un cavo di rete difettoso! Grazie a tutti. Jimmi" è
meglio di niente. In effetti un breve riassunto è meglio di una
lunga dissertazione, a meno che la soluzione non abbia un reale
spessore tecnico. Indica quale azione ha risolto il problema, ma senza
riassumere l'intero processo di soluzione.
Oltre ad essere cortese e ad informare, questa sorta di followup
aiuterà quanti cercano nell'archivio della mailing-list/newsgroup/forum
aconoscere esattamente la soluzione che ti ha aiutato, e che quindi può
aiutare loro.
In ultimo, ma non meno importante, questa nota conclusiva fa percepire
a quanti hanno partecipato un piacevole senso di soddisfazione per aver
raggiunto la meta. Se non sei un tecnico o un hacker credi a noi:
questa sensazione è veramente importante per i guru e gli esperti che
hai coinvolto per aiutarti. Discutere su problemi senza concludere
nulla è frustrante; gli hacker fremono per il desiderio di vedere la
soluzione. La buona reputazione che ti guadagni soddisfando questo
desiderio ti sarà di grande aiuto la prossima volta che hai bisogno di
aiuto.
-----------------------------------------------------------------------
Come interpretare le risposte
RTFM e STFW: come dire che hai seriamente rotto
Esiste un'antica e venerabile tradizione: se ti viene inviata una
risposta contenente "RTFM" (Read The Fucking Manual), la persona che te
la invia pensa che tu avresti dovuto leggere il fottuto manuale. Quasi
sicuramente ha ragione. Vai a leggerlo.
RTFM ha un parente più giovane. Se ti arriva una risposta contenente
"STFW" (Search The Fucking Web), la persona che te la invia pensa che
tu avresti dovuto cercare nella fottuta rete. Quasi sicuramente ha
ragione. Comincia a cercare.
Spesso, la persona che invia queste risposte ha aperto il manuale o la
pagina Web con le informazioni di cui hai bisogno, e le sta guardando
mentre ti scrive. Questa risposta significa che egli pensa (a) che le
informazioni di cui hai bisogno sono facili da trovare e (b) che
imparerai di più se cerchi le informazioni da solo che se ti fai
imboccare da altri.
Non ti devi offendere per questo: secondo lo standard hacker, lui ti
sta mostrando una ruvida forma di rispetto non ignorandoti. Dovresti
invece essergli grato per la sua premura materna.
-----------------------------------------------------------------------
Se non capisci...
Se non capisci subito la risposta, non replicare immediatamente con una
richiesta di chiarimenti. Usa gli stessi mezzi che hai usato per
cercare di risolvere il tuo problema all'inizio (manuali, FAQs, la
rete, amici esperti) per tentare di capire la risposta. Quindi, se hai
ancora bisogno di chiarimenti, esponi prima quello che hai imparato.
Ad esempio, supponi che ti dica: "sembrerebbe che tu abbia uno zentry
che ti blocca, dovresti eliminarlo" Allora:
Questa è una replica sbagliata: "che cosa è uno zentry?"
Questa è una buona replica: "Ho letto il manuale ma zentry è menzionato
solamente a nel capitolo degli switches -z e -p. In nessuno di essi
viene indicato come eliminare gli zentries. Devo usare questi o mi
sfugge qualcosa?"
-----------------------------------------------------------------------
Convivere con la scortesia
Molta di quella che sembra scortesia nei circoli hacker non ha lo scopo
di offendere. Piuttosto è il prodotto dello stile di comunicazione,
rivolto direttamente allo scopo, che è naturale per gente più abituata
a risolvere i problemi che a far sentire gli altri tra due guanciali.
Quando qualcuno ti sembra scortese, prova da reagire con calma. Se
qualcuno realmente si sta comportando male, è molto probabile che
qualcuno tra gli "anziani" della mailing list, del newsgroup o del
forum lo richiamerà. Se questo non accade e tu perdi le staffe, è
probabile che la persona con cui ti stai arrabbiando stia comportandosi
normalmente secondo le norme della comunità hacker e tu sia considerato
in errore. Questo lederà le possibilità che tu ottenga le informazioni
o l'aiuto di cui hai bisogno.
D'altra parte, ti potrà capitare di incontrare scortesie o prese di
posizione gratuite. Il rovescio della medaglia è che è accettabile
reagire duramente contro persone veramente offensive, demolendo la loro
maleducazione con discorsi taglienti. Prima di intraprendere questa
strada, ad ogni modo, verifica molto bene i tuoi argomenti. Il confine
tra correggere l'inciviltà ed avviare una guerra senza scopo è così
sottile che spesso anche gli hackers lo varcano senza accorgersene; se
sei novizo/a od esterno/a all'ambiente le probabilità che tu riesca ad
evitare questo confine sono poche. Se sei meno che sicuro dei tuoi
mezzi, è meglio che tieni le mani lontane dalla tastiera piuttosto che
rischiare.
(Qualcuno dice che molti hacker hanno una leggera forma di autismo o
sindrome di Asperger, e che sono privi di alcuni dei circuiti cerebrali
che favoriscono le normali interazioni sociali. Questo può essere vero
o meno. Se non sei un hacker, pensare che noi siamo cerebro lesi può
aiutarti a comprendere la nostra eccentricità. Non preoccuparti di
pensarlo. Noi non vi facciamo caso; a noi piace essere quello che
siamo, qualunque cosa sia, e generalmente abbiamo un sano scetticismo
verso le analisi cliniche.)
Nella prossima sezione parleremo di un'altro argomento: la scortesia
che incontri quando tu sei maleducato/a.
-----------------------------------------------------------------------
Sulle reazioni da perdente
E' possibile che qualche volta tu faccia arrabbiare gli altri del
forum, nei modi descritti in questo articolo o simili. E che qualcuno
ti dica esattamente dove hai sbagliato, probabilmente in maniera
colorita. In pubblico.
Quando questo accade, la cosa peggiore che puoi fare è piangere la tua
inesperienza, lamentarti che sei stato insultato, richiedere scuse,
gridare, trattenere il respiro, minacciare azioni legali, denunciare la
cosa ai responsabili, lasciare la tavoletta del cesso alzata ecc.
Questo invece è quello che devi fare:
Fai finta di niente. E' normale. Di fatto è giusto ed appropriato.
Gli usi della comunità non si mantengono da soli: sono mantenuti dalla
gente che li applica pubblicamente ed in modo visibile. Non lamentarti
che le critiche avrebbero dovuto essere inviate privatamente: non è
così che funziona. E non ti aiuta insistere che sei stato personalmente
insultato quando qualcuno commenta che le tue lamentele erano
sbagliate, o che lui la pensa diversamente. Questi sono atteggiamenti
da perdente.
Ci sono stati forum in cui, per un malposto senso di iper-cortesia, ai
partecipanti era vietato l'invio di messaggi di critica verso messaggi
altrui, dicendo di "non dire nulla se non vuoi aiutare gli utenti". La
conseguente defezione dei partecipanti più significativi ha di fatto
trasformato le discussioni in chiacchiere senza senso e reso il forum
tecnicamente inutile.
Sii esageratamente "amichevole" o utile: Scegli tu.
Ricorda: quando quell'hacker ti dice che hai sbagliato, e (non importa
quanto rozzamente) ti raccomanda di non farlo più, si sta preoccupando
per: (1) te e (2) la sua comunità. Sarebbe molto più facile per lui
ignorarti e filtrarti fuori dalla sua vita. Se non riesci ad essere
riconoscente, abbi almeno un pò di dignità, non piagniucolare e non
pensare che tu debba essere trattato/a come una bambolina solo perchè
sei un nuovo arrivato/a con un'anima teatralmente ipersensibile e crisi
di identità.
-----------------------------------------------------------------------
Domande da non porre
Qui di seguito trovate alcune classiche domande stupide e cosa pensano
gli hackers quando non rispondono.
D: Dove posso trovare il programma X?
D: Il mio { programma, configurazione, dichiarazione SQL } non funziona
D: Ho problemi con la mia macchina Windows. Potete aiutarmi?
D: Ho problemi ad installare Linux o X. Potete aiutarmi?
D: Come posso crackare l'utente root/rubare privilegi in rete/leggere
la posta di qualcuno?
D: Dove posso trovare il programma X?
R: Lo stesso posto lo troverei io, stupido; cercandolo in rete. Zio
buono, ma c'è ancora qualcuno che non sa come utilizzare Google?
D: Il mio { programma, configurazione, dichiarazione SQL } non funziona
A: Questa non è una domanda, e non mi interessa giocare a Rischiatutto
per cercare di capire cosa non funziona. Ho di meglio da fare. Se
ricevo qualcosa di simile di solito invio risposte tipo:
* devi aggiungere altro?
* che peccato; spero chce riuscirai a farlo funzionare.
* ed io esattamente cosa c'entro?
D: Ho problemi con la mia macchina Windows. Potete aiutarmi?
A: Sì. Butta via quella spazzatura della Microsoft ed installa un
sistema operativo open-source come Linux o BSD.
D: Ho problemi ad installare Linux o X. Potete aiutarmi?
A: No. Avrei bisogno di accedere alla tua macchina per analizzare il
guasto. Chiedi al LUG (Linux User Group) più vicino di aiutarti (Puoi
trovare una lista dei LUG italiani all'indirizzo www.linux.it/LUG/)
D: Come posso crackare l'utente root/rubare privilegi in rete/leggere
la posta di qualcuno?
A: Siete uno stupido/a per voler fare cose simili ed un deficiente per
chiedere ad un hacker di aiutarti.
-----------------------------------------------------------------------
Domande giuste e domande sbagliate
Per concludere, farò qualche esempio per illustrare meglio come porre
in modo domande intelligente; accoppierò due domande sullo stesso
in modo argomento, una posta stupido ed una in modo intelligente.
Stupida: Dove posso trovare informazioni su Foonly Flurbamatic?
Questo otterrà solo "STFW" come risposta.
Intelligente: Ho usato Google per cercare "Foonly Flurbamatic 2600" in
rete ma non ho trovato spunti utili. Qualcuno sa dove posso trovare
informazioni per la programmazione di questa periferica?
Questo ha già cercato in rete, e sembra avere un vero problema.
Stupida: Non riesco a compilare il codice di foo. Perchè non funziona?
Questo pensa che qualcun'altro ha sbagliato. Un atteggiamento
arrogante.
Intelligente: Non riesco a compilare il codice di foo sotto Nulix
versione 6.2. Ho letto le FAQ, ma non ho trovato niente a proposito di
problemi con Nulix. Allego la trascrizione dei miei tentativi di
compilazione; ho sbagliato qualcosa?
Questo ha specificato l'ambiente, ha letto le FAQ, mostra
l'errore e non pensa che il problema derivi dallo sbaglio di
qualcun'altro Costui è degno di attenzione.
Stupido: Ho problemi con la mia motherboard. Qualcuno mi può aiutare?
Il signor Hacker Qualsiasi risponderà probabilmente "Si, e
hai anche bisogno di fare il ruttino o di cambiare il
pannolino?" e premerà il tasto Canc.
Astuto: Ho provato X, Y e Z sulla motherboard S2464. Visto che non
funzionava, ho provato A, B e C. Notate il curioso sintomo durante la
prova C. La partenza sembra normale ma i risultati non sono quelli che
uno si aspetta. Cosa può causare questi effetti su una motherboard
Athlon MP? Quanlcuno conosce quale altro test potrei provare per capire
dove sta il problema?
Questa persona, invece, sembra degna di una risposta. Ha
mostrato intelligenza nel cercare uan soluzione al problema
piuttosto che attendere passivamente una risposta caduta
dall'alto
Nell'ultima domanda, nota la sottile ma importante differenza fra
chiedere "datemi una risposta" e "aiutatemi a capire quali programmi
diagnostici posso far girare per chiarire il problema".
Infatti, l'argomento dell'ultima domanda è basato su un caso realmente
accaduto nell'Agosto 2001 sulla mailing list del kernel di Linux. Io
(Eric) ero quello che quella volta poneva la domanda. Stavo osservando
dei misteriosi lookups su una motherboard Tyan S2464. I membri della
lista mi fornirono le informazioni critiche per risolvere il problema.
Ponendo la domanda a quel modo, ho dato alla gente qualcosa su cui
lavorare; ho reso più facile ed attraente il coinvolgimento. Ho
dimostrato rispetto per l'abilità degli altri e li ho invitati a
confrontarsi con me da pari. Ho anche dimostrato rispetto per il loro
tempo informandoli dei vicoli ciechi in cui mi ero già imbattuto.
In seguito, quando ho ringraziato tutti e fatto notare come tutto
avesse funzionato bene, un membro della lista osservò che secondo lui
il tutto ha funzionato non perchè sono "un nome" su quella lista, ma
perché ho posto la domanda nella forma giusta.
Gli hackers hanno un forma di meritocrazia spietata. Sono sicuro che
lui aveva ragione, e che se io mi fossi comportato passivamente come
una spugna, sarei stato oggetto di ostilità o ignorato, non importa chi
io fossi. Il suo suggerimento, di riassumere l'intero incidente come
istruzione per gli altri ha posto le basi per la redazione di questa
guida.
-----------------------------------------------------------------------
Se non ottenete alcuna risposta
Se non riuscite ad ottenere una risposta, non fatene un caso personale
se pensiamo di non potervi aiutare. Qualche volta i membri del gruppo a
cui chiedete possono semplicemente ignorare la risposta. Non ottenere
risposte non è lo stesso che essere ignorati, anche se dall'esterno è
difficile cogliere la differenza.
In generale, inviare nuovamente la domanda non è una buona idea. Questo
sarà visto come un'inutile fastidio.
Ci sono altre fonti di aiuto che potete consultare, spesso fonti più
adattate ai bisogni di un novizio/a.
Esistono molti gruppi di utenti appassionati di software in rete, anche
se magari i membri non hanno mai scritto del codice essi stessi. Questi
gruppi sono formati in modo che gli utenti possono aiutarsi a vicenda
ed aiutare i nuovi arrivati.
Esistono anche molte società commerciali, grandi e piccole da cui puoi
ottenere dei contratti di assistenza (Red Hat e Linuxcare sono due
delle più conosciute, ma ne esistono molte altre). Non spaventarti
all'idea di dovere pagare per un po'di aiuto! Dopo tutto, se al motore
della tua automobile salta la guarnizione della testa, è probabile che
tu la porti in un'officina per ripararla a pagamento. Anche se il
software non ti è costato niente, non puoi pensare che l'assistenza
venga sempre offerta gratis.
Software popolari come Linux hanno circa 10.000 utenti per ogni
sviluppatore. E' semplicamente impossibile per una persona curare le
chiamate di oltre 10.000 persone. Ricorda che anche se devi pagare per
il supporto, stai sempre risparmiando il costo del software (ed il
supporto per il software proprietario è solitamente più costoso e meno
competente del supporto che puoi ottenere con l'open-source).
-----------------------------------------------------------------------
Risorse
Se avete bisogno di istruzioni sui principi fondamentali
di come funzioanano i personal computer, UNIX ed Internet,
consultate "The Unix and Internet Fundamentals HOWTO"
(http://linuxdoc.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/).
Se rilasciate del software o scrivete patches per software, provate a
seguire le istruzioni contenute in "Software Release Practice HOWTO".
(http://linuxdoc.org/HOWTO/Software-Release-Practice-HOWTO/).
--FCuugMFkClbJLl1L--