Copyright © 2001 Eric Steven Raymond
Per la versione italiana, Copyright © 2004 Alessandro Carichini
| Cronologia Della Versione Italiana | ||
|---|---|---|
| 1.00 | 03-02-2004 | ac |
Putroppo ci siamo resi conto che, senza questo richiamo, continueremo ad essere infastitidi da idioti che pensano che l'aver pubblicato questo documento ci trasformi automaticamente nei risolutori dei problemi tecnici di tutto il mondo.
Se stai leggendo questo documento perchè hai bisogno di aiuto, e guardandoti attorno credi di poterlo ottenere direttamente dagli autori, allora sei uno degli idioti in questione. Non farci domande. Ti ignoreremmo e basta. Siamo qui per mostrarti come farti aiutare dalle persone che conoscono il software o l'hardware con cui stai lavorando. A meno che tu non sia certo che uno degli autori è un esperto di quello che ti serve, lasciaci in pace e tutti saranno felici.
La prima cosa da capire è che agli hackers piacciono i problemi difficili ed i buoni e stimolanti concetti che ne derivano. Se così non fosse, non saremmo qui. Se ci fai una domanda interessante, su cui rimuginare, te ne siamo grati, le buone domande sono uno stimolo e un regalo. Le buone domande ci aiutano a sviluppare la nostra comprensione e, spesso, rappresentano l’unica via per rivelare problemi a cui non avevi pensato. Tra hackers "Good question!" ("Bella domanda!") è un forte e sincero complimento.
Malgrado ciò, gli hackers hanno la reputazione di approcciare alle domande semplici in modo apparentemente ostile o arrogante. A volte sembriamo avere una maleducazione riflessiva nei confronti dei principianti e degli ignoranti. Ma non è proprio così.
Quello di cui non ci scusiamo, è di essere ostili nei confronti di chi sembra non avere voglia di pensare o volersi ben documentare prima di fare domande. Persone come queste sono dei perditempo — prendono senza restituire, sprecano tempo che noi potremmo spendere in altri e più interessanti problemi, con altre persone più meritevoli di una risposta. Noi li chiamiamo losers (falliti o perdenti, NdT) (e per ragioni storiche a volte lo pronunciamo lusers)
Ci rendiamo conto che ci sono tante persone che vogliono solamente usare il software che noi scriviamo senza avere il minimo interesse per i dettagli tecnici. Per molte persone un computer è soltanto uno strumento, un mezzo per un fine; ed hanno cose più importanti da fare e una vita da vivere. Noi comprendiamo tutto ciò e non ci aspettiamo che ognuno presti interesse alle cose tecniche che ci affascinano. Tuttavia il nostro modo di rispondere alle domande dipende dal grado di interesse che le persone mostrano per essere parte attiva nella soluzione del problema. E questo approccio non cambierà. Non dovrebbe, ma se accadesse, ci farebbe diventare meno efficaci nelle cose che ci riescono meglio.
Siamo (in gran parte) volontari. Dobbiamo interrompere le nostre laboriose giornate, per rispondere alle domande, e a volte ne veniamo sommersi. E' uno spietato filtraggio. In particolare, cestiniamo ogni domanda da parte di quelle persone che appaiono come "perdenti" per occuparci più efficentemente dei "vincenti".
Se lo ritieni un atteggiamento odioso, indulgente o arrogante, rifletti sulle tue posizioni. Non chiediamo che tu ti genufletta dinnanzi a noi — infatti, la maggiorparte di noi non amerebbe altro che avere un rapporto paritetico per darti il benvenuto nella nostra "cultura", basta solo che tu ci metta il giusto impegno per renderlo possibile. Ma è più semplice che efficiente per noi cercare di aiutare le persone che non hanno alcuna voglia di aiutare se stesse. Va bene essere ignoranti (su un certo argomento, NdT) ma non tolleriamo chi vuole fare lo stupido.
Così, mentre non è necessario avere già delle compentenze tecniche per avere la nostra attenzione, è invece necessario dimostrare un certo atteggiamento che conduce alla competenza — attenzione, riflessione, osservazione, desiderio di essere una componente attiva nello sviluppo di una soluzione. Se non sopporti questo tipo di discriminazione allora ti consigliamo di pagare qualcuno per un contratto di supporto commerciale invece di chiederlo a degli hackers che ti donano personalmente un aiuto.
Se decidi di venire da noi per un aiuto, non devi voler essere un "perdente". Non devi nemmeno sembrarlo. Il miglior modo per ottenere una rapida e pronta risposta è domandare come lo farebbe una persona con intelligenza, sicurezza e con a disposizione tutte le informazioni raccolte sul caso che necessitano di un aiuto.
(Le migliorie a questa guida sono benvenute. Puoi inviarmi suggerimenti collegandoti al mio sito - se li vuoi mandare ad Eric Raymond devi leggerti la versione originale e scriverli in inglese - Ricorda tuttavia che questo documento non è inteso come una guida generale alla netiquette, verranno perciò rigettati tutti quei suggerimenti che non sono relativi specificatamente dall'ottenere risposte utili dai forum tecnici.)
Usa tattiche come il fare ricerche su Google usando per testo un qualsiasi messaggio di errore che ti capita di incontrare oppure, sempre su Google, cliccando su "Gruppi". Questo ti porta diritto alla documentazione sui fix (tecniche di correzione di bugs, NdT) o ai topics (argomenti) delle mailing list che risponderanno alla tua domanda. Se non ci riesci puoi sembre dire "Ho cercato su Google la seguente frase ma non ho trovato nulla di utile" che è sempre una buona cosa da mettere in una email o news che posta richieste di aiuto.
Prepara la tua domanda. Pensaci a fondo. Domande che suonano frettolose ottengono risposte frettolose, oppure non vengono neppure considerate. Maggiore è lo sforzo che fai per dimostrare il passaggio di tutte le tappe per risolvere il tuo problema, prima di chiedere aiuto, e massima sarà la probabilità di ottenerlo.
Bada di non fare la domanda sbagliata. Se chiedi un qualcosa che si basa su una supposizione fallace, è molto probabile che un J.Random Hacker (l'archetipo dell'hacker secondo Raymond, NdT) replichi con un'inutile risposta letterale mentre sta pensando "Che domanda stupida....", per sperare che l'esperienza di ottenere quello che hai chiesto piuttosto di quello di cui hai bisogno ti serva da lezione.
Non partire dall'assunto che devi avere una risposta. Non l'avrai, dopotutto non stai pagando per un servizio. Una risposta riuscirai ad ottenerla facendo una domanda che sia concreta, interessante e mentalmente stimolante — una che implicitamente contribuisca all' esperienza della comunità anziché una semplice e passiva richiesta di conoscenza da parte di altri.
D'altro canto, rendere chiaro di essere in grado e desideroso di aiutare il processo di sviluppo della soluzione è una buonissima partenza. "Potrebbe qualcuno fornirmi un'indicazione?", "Che cosa manca al mio esempio?" ed anche "Che sito dovrei controllare?", hanno molte più chances di ottenere una risposta piuttosto di un "Per piacere inviatemi l'esatta procedura che devo usare". Perchè il semplice indicare la giusta direzione da parte di qualcuno ha reso chiara la tua volontà di completare l'intero processo.
Ma sparare email ad una persona o forum con cui non si ha familiarità, può comportare seri rischi. Ad esempio, non dare per scontato che l'autore di una pagina web informativa voglia essere il tuo consulente gratuito. Non fare ipotesi ottimistiche dal semplice fatto che la tua domanda sarà ben accetta - se non sei sicuro, spediscila da qualche altra parte ma trattieniti dal spedirla a tutti.
Quando selezioni un newsgroup o una mailing list, non fidarti se il nome non sembra avere nulla a che fare; cerca nelle FAQ o nelle pagine per verificare che la tua domanda sia in argomento. Prima di postare qualcosa, leggiti un po' degli altri messaggi pubblicati per farti un'idea di come funzionano le cose da quelle parti. Magari usando l'argomento del tuo problema come chiave di ricerca per scoprire se a qualcun'altro hanno già dato una risposta. Anche se non trovi nulla di tuo interesse, tutto questo può aiutarti nel formulare la domanda nel modo migliore.
Conoscere qual è il proprio argomento! Uno dei classici errori è fare domande sull'interfaccia di programmazione di Unix o Windows sul forum dedicato ai linguaggi o alle librerie o ai tool che si occupano di fare il porting su entrambi. Se non capisci il perchè si tratta di uno strafalcione allora faresti meglio a smettere di tempestare gli altri con ogni tipo di domanda.
In generale, è molto più probabile ottenere risposte utili a domande fatte al pubblico ben selezionato di un forum piuttosto che a quelle fatte privatamente. Le ragioni sono molteplici. Una è l'ampiezza del potenziale pool di soggetti pronti a rispondere. Un'altro è la cassa di risonanza; gli hackers preferiscono rispondere a domande che educhino più persone possibili anziché a quelle solo per pochi.
Per intenderci, i bravi hacker e gli autori di software popolari stanno già ricevendo, molto oltre il giusto lecito, messaggi male indirizzati. In casi estremi potresti divenire la goccia che fa traboccare il vaso – Molte volte, l'inutile traffico di email, fa si che i collaboratori di progetti popolari ritirino la propria disponibilità per gli inaccettabili danni collaterali provocati ai loro account personali.
Una buona norma per l'intestazione del Subject, usata da molte organizzazioni di supporto tecnico, è "Subject – deviazione". La parte "Subject" specifica su che cosa o gruppo di cose stai avendo un problema mentre la parte "deviazione" ne descrive l'anomalia dal comportamento abituale.
Stupido:
AIUTO! Il Video non funziona correttamente sul mio portatile!
Intelligente:
XFree86 4.1 cursore del mouse deforme, scheda MV1005 chipset video
Intelligentissimo:
XFree86 4.1 cursore del mouse sul chipset video sulla scheda
MV1005 – è deforme
Il processo di scrittura della descrizione "Subject - deviazione" ti aiuterà ad organizzare il tuo pensiero riguardo i maggiori dettagli del problema. Da cosa è affetto? E' solo il cursore del mouse o anche qualcos'altro della grafica? E' specifico per la Xfree86? Per la versione 4.1? E'specifico per il chipset di quella scheda video? Per il modello MV1005? Un hacker che vede il risultato può immediatamente capire, al primo sguardo, il tuo tipo di problema e con che cosa lo stai avendo.
Se fai una domanda in una replica, assicurati di cambiare la linea del subject per indicare che stai facendo una domanda. La linea del subject che appare con "Re: test" oppure "Re: new bug" è meno probabile che attragga una quantità utile di attenzione. Anche il ridurre al minimo il precedente messaggio quotato rende armoniosa la collaborazione di nuovi lettori.
Non dare il semplice reply ad un messaggio di una lista per iniziare un nuovo thread (argomento di discussione di una mailinglist o newsgroup, dal quale si estende una gerarchia di messaggi affini, NdT). Questo limiterà la tua audience. Alcuni lettori di mail, come Mutt, permettono agli utenti di ordinare per thread e poi di nascondere i messaggi in esso contenuti raggruppando il thread stesso. Quelli che lo fanno non vedranno mai il vostro messaggio.
Cambiare il subject non è sufficiente. Mutt, e probabilmente altri lettori di mail, cercano altre informazioni nell'intestazione delle mail per assegnarle al thread, non la semplice riga del subject. Per cui comincia un'intera nuova email.
E' dunque importante esprimere le proprie problematiche in modo chiaro e giusto. Se non t'importa farlo, a noi non interessa prestare attenzione. Fai uno sforzo extra per ripulire il tuo linguaggio. Non è per essere severi o formali — infatti la cultura hacker apprezza un linguaggio informale, gergale e umoristico usato con precisione. L'essere precisi è significa che stai pensando e presti attenzione.
Usa correttamente lo spelling, la punteggiatura ed il maiuscolo. Non confondere "its" con "it's", "loose" con "lose", o "discrete" with "discreet" (NdT, sono esempi di parole in inglese con pronuncia simile ma con significato diverso, molti scrivono come pronunciano). Non DIGITARE TUTTO IN MAIUSCOLO, viene letto come se stessi urlando e si passa per maleducati. (tutto minuscolo è solo un po' meno seccante ma difficile da leggere. Alan Cox può passare, ma non tu.)
Più in generale, se scrivi come uno sciocco semi-letterato sarai chiaramente ignorato. Scrivere come un script kiddie che usa il Leet Speak (NdT, Tipo di scrittura che sostituisce le lettere con i numeri ovvero L33t 5p34k, molto usato tra gli script kiddie, coloro che usano i tools dei cracker per fare danni in rete) è il colpo di grazia assoluto per ricevere come risposta null'altro che un silenzio tombale (o, al massimo, si viene subissati di insulti e sarcasmo)
Se fai domande in un forum che non usa la tua lingua, avrai un ammontare limitato di bonus per errori grammaticali e di spelling - ma nessun bonus extra dovuto alla pigrizia (eh sì, solitamente notiamo la differenza).
Anche se conosci la lingua di chi risponde al messaggio, scrivi in inglese. Gli hackers occupati tendono semplicemente a svuotare le domande fatte in un linguaggio che non capiscono, e l'inglese è il linguaggio con cui si lavora su internet. Scrivendo in inglese ridurrai le possibilità che la tua domanda venga scartata senza essere letta.
Se stai usando un client di posta a interfaccia-utente-grafica (come Netscape Messenger, Ms Outlook, o simili) fai attenzione che non violi queste regole quando lo usi con una configurazione di default. Molti di questi client hanno un comando "View Source" da menu. Usalo per verificare che stai spedendo solo testo in chiaro senza un'inutile sporcizia accodata.
Simon Tatham ha scritto un eccellente saggio intitolato How to Report Bugs Effectively (NdT, "Come Relazionare i Bug in modo Efficente"). Ti consiglio fortemente di leggerlo.
Questo è utile per almeno tre ragioni: Uno: essere visti ad investire sforzi nello semplificare la domanda rende più probabile l'ottenere una risposta. Due: semplificare la domanda rende più probabile l'ottenere una risposta utile. Tre: nel processo di perfezionamento della tua relazione sul bug, potresti tu stesso sviluppare un rimedio per correggerlo o per bypassarlo.
Ricorda, ci sono un sacco di altri utenti che non hanno riscontrato il tuo problema. Altrimenti l'avresti saputo mentre leggevi la documentazione o cercavi nel Web (cosa che hai fatto prima di reclamare, non è vero?). Questo significa che molto probabilmente sei stato tu a fare qualcosa di sbagliato, non il software.
Le persone che hanno scritto il software lavorano duramente per farlo funzionare al meglio. Se sostieni di aver trovato un bug, stai insinuando che loro hanno fatto qualcosa di sbagliato, ed è come se li stessi offendendo – anche se hai ragione. E' poco diplomatico urlare "bug" nel Subject.
Quando fai una domanda, è meglio scrivere facendo credere di pensare di aver fatto qualcosa di sbagliato anche se in coscienza siamo piuttosto sicuri di aver trovato un nuovo bug. Se è veramente un bug, lo sentirai nella risposta. Prendila in questo modo, è meglio che siano i mantainers a porgerti le scuse se il bug è reale piuttosto che sia tu a dovergliele per aver fatto confusione.
Stupido:
Sto
ricevendo continui errori SIG11 durante la compilazione del kernel, e
sospetto una sottile fenditura in una delle tracce della motherboard.
Qual è il miglior modo per verificarlo?
Intelligente:
Il mio assemblato K6/233
su motherboard FIC-PA2007 (VIA Apollo VP2 chipset) con 256Mb Corsair
PC133 SDRAM comincia a dare frequenti errori SIG11, circa 20 minuti
dopo averlo acceso e durante la compilazione del kernel, ma mai nei
primi 20 minuti. Riavviarlo non azzera il minutaggio della durata
(ovvero non rimane attivo per altri 20 minuti, NdT), ma tenerlo
spento durante la notte si. Scambiare la RAM non aiuta. Segue il log
delle parti rilevanti di una tipica sessione di compilazione.
Se il programma che ti è esploso ha opzioni diagnostiche (come la -v per verbose), prova a pensare attentamente sulla selezione delle opzioni che possono aumentare le informazioni utili di debugging per la trascrizione.
Se però questo comporta ad un allungamento della lista (almeno più di quattro paragrafi) è più utile dare un succinto stato del problema all'inizio per poi proseguire col racconto cronologico. In questo modo gli hackers sapranno a cosa far attenzione nel leggere il tuo papiro.
Spesso le persone che hanno bisogno di un aiuto tecnico, hanno uno scopo di alto livello in testa e si bloccano in quello che credono sia uno dei percorsi particolari verso lo scopo stesso. Cercano aiuto per quel passo, ma non si rendono conto che è il percorso ad essere sbagliato. E per passare tutto questo ci vuole molta fatica.
Stupido:
Come faccio ad ottenere il color picker (è uno strumento per
ottenere il codice RGB di un colore semplicemente puntandolo
col mouse, NdT) dal programma FooDraw per prendere il valore
RGB esadecimale?
Intelligente:
Sto cercando di rimpiazzare la tavola dei colori su di una immagine
con valori scelti da me. Attualmente l'unica maniera per farlo
è editare ogni slot della tabella, ma non riesco ad ottenere
il color picker dal programma FooDraw per prendere il valore RGB
esadecimale.
La seconda versione, se la domanda è intelligente, permette una risposta che suggerisce un tool che meglio si addice al compito richiesto.
Avrai molte più possibilità nel ricevere una risposta utile se sei esplicito riguardo quello che vorresti che facesse colui che ti risponde (fornire indicazioni, inviare codice, verificare una patch, ec...)
Questo ne focalizzerà lo sforzo ed implicitamente farà aumentare il limite di tempo ed energia concesso per aiutarti. E questo è buona cosa.
Per capire in che mondo vivono gli esperti, pensa alla conoscenza come ad una risorsa abbondante mentre al tempo che si ha per rispondere, come ad una scarsa. Il poco tempo che ti viene implicitamente richiesto (nell'applicare queste regole, NdT) aumenterà le probabilità di ottenere una risposta da qualcuno che è tanto in gamba quanto occupato.
Questo permette di inquadrare la tua domanda, minimizzando così il tempo concesso dall'esperto per rispondere con abilità – anche se non è la stessa cosa come il semplificare la domanda. Così, ad esempio, "Mi si può indicare una buona spiegazione per X?" è solitamente una domanda più intelligente di "Mi spiegate X, per favore?". Se hai del codice che non funziona è molto più intelligente chiedere che qualcuno spieghi cosa non va, piuttosto che chiedere di farlo funzionare.
Primo: se hai scritto in
maniera abbastanza competente la descrizione del tuo problema,
appiccicare tali domande risulta essere, nel caso ottimistico,
superfluo.
Secondo: per il fatto che
sono superflue, gli hackers le trovano seccanti – e quasi
certamente riceveranno come risposta conclusiva
un'impeccabile: "Si, puoi essere aiutato" oppure
un: "No, non c'è aiuto per te".
In generale, fare domande si-o-no è un buon modo per evitarle a meno che tu non voglia una risposta si-o-no.
Per essere onesti, questo non è importante come (e non lo può certo sostituire) l'essere chiaro, preciso, descrittivo, corretto dal punto di vista grammaticale, scevro da formati proprietari ecc..; gli hackers in generale preferiscono un approccio brusco ma con intelligenti dettagli tecnici di un bug piuttosto che una gentile vaghezza. (Se questo ti confonde, ricorda che noi valutiamo una domanda da quello che ci insegna)
Tuttavia, se hai dispiegato tutti i tuoi dettagli tecnici, la gentilezza incrementerà le tue chances di ottenere una risposta utile.
(Facciamo notare che le sole obiezioni serie che abbiamo ricevuto da hackers veterani a questa guida ed in rispetto alle nostre raccomandazioni è di usare "Grazie in anticipo". Alcuni hackers sentono questo connotato come un'intenzione a non ringraziare in seguito. La nostra raccomandazione è anche dire, inizialmente "Grazie in anticipo" ma poi ringraziare successivamente , o anche esprimere cortesia in un modo diverso, dicendo qualcosa del tipo "Grazie per la considerazione")
L'ideale è che la replica sia nel thread di partenza nella posizione originale della domanda, e come subject arrechi la dicitura "FIXED" o "RESOLVED" (Sistemato o Risolto). Sulle mailing list con rapidi scambi di risposte, chi vedesse un thread riguardante "Problema X" ed alla fine un "Problema X – FIXED" saprebbe che non ci dovrebbe perdere tempo (a meno che non sia interessato alla questione) per impiegarlo nel risolvere qualcosa di differente.
Il tuo seguito non deve essere troppo lungo e complicato; un semplice "Salve! era un cavo di rete fallato! Un grazie a tutti. - Bill" è meglio di niente. Infatti un breve e piacevole sommario è meglio di una lunga dissertazione, amenochè la soluzione non necessiti di un reale approfondimento tecnico. Basta dire l'azione che ha risolto il problema senza dover replicare l'intera sequenza di risoluzione.
Per problemi con maggiore approfondimento, è appropriato postare il sommario dell' history (cronologia degli eventi, NdT) della risoluzione. Descrivi le tue istruzioni finali del problema. Descrivi cosa ha funzionato come soluzione ed indica come evitare i vicoli ciechi. Il nome o i nomi delle persone che ti hanno aiutato; è un modo per farsi degli amici.
Oltre al fatto di essere cortese ed informativo, questo tipo di seguito aiuterà la ricerca di altri nell'archivio della mailing-list/newsgroup/forum per sapere quale soluzione ha aiutato te e loro di riflesso.
Per ultimo ma non per questo meno importante, queste note servono a far in modo che tutte le persone coinvolte godano di un soddisfacente senso di "fine del problema". Se non sei nè un tecnico nè un hacker, fidati di noi se ti diciamo che questa sensazione è molto importante per i guru e gli esperti che hai tampinato per un aiuto. La narrativa riguardante i problemi che si trascinano verso un nulla di fatto è un qualcosa di frustrante; gli hackers hanno una grande voglia di vederli risolti. E questo perchè, un'eventuale soluzione, creerebbe una sorta di karma positivo alla prossima proposta di domanda.
Considera anche come puoi essere in grado, in futuro, di evitare ad altri lo stesso problema. Chiediti se una patch (pezza, NdT) alla documentazione o FAQ può essere d'aiuto, se sì inviala al manutentore.
Tra hackers questo tipo di comportamento è più importante della cortesia di rito. Il sapertela giostrare con gli altri ti permette di farti una reputazione che è poi il patrimonio più prezioso.
RTFM è relativamente giovane. Se ottieni una replica che recita STFW (Searched The Fucking Web), la persona che te l'ha spedita pensa che tu debba "Cercartelo In Quel Cazzo di Web". Ha quasi certamente ragione. Avanti cercalo.
Spesso chi invia queste repliche ha davanti a sè il manuale o la pagina web con le informazioni che stai cercando, leggendole mentre ti sta rispondendo
Colui che ti ha mandato queste repliche pensa (a) le informazioni di cui hai bisogno sono facili da trovare e (b) imparerai molto di più nel cercarle piuttosto che riceverle su di un piatto d'argento.
Non ti devi offedere per questo; per gli stardard di un hacker è il suo modo rude per mostrarti il suo rispetto anzichè ignorarti. Per questo dovresti ringraziarlo per la sua benevola gentilezza.
Se poi continui ad avere bisogno di un chiarimento, esibisci quello che hai imparato.
Per esempio, supponi che ti dico: "Sembra che tu abbia avuto un blocco zentry; dovrai ripulirlo.";
Ecco un pessimo seguito di domanda: "Che cos'è uno zentry?"
Ed ecco un buon seguito di domanda: "Ok, ho letto le pagine del manuale e zentry viene solo menzionato sotto gli swicth -z e -p. Nessuno dei due parla di pulizia zentry. E' uno di questi o mi sono perso qualcosa".
Quando percepisci scortesia, cerca di restare calmo. Se qualcuno la sta realmente manifestando, è molto probabile che una persona della lista o del newsgroup o del forum con più esperienza la calmerà. Ma se ciò non accadesse e tu dovessi perdere la calma, è probabile che la persona che te l'ha fatta perdere si stava comportando secondo le norme della comunità hacker e quindi saresti tu ad essere considerato in torto. Questo minerà le possibilità di avere informazioni o l'aiuto che volevi.
D'altro canto, ti capiterà altre volte di imbatterti nella maleducazione e nella sua gratuita perpetuazione. Il rovescio della medaglia è che tutto questo è una forma accettabile di stroncare duramente i veri colpevoli di offese, sezionando i loro misfatti con un affilato bisturi verbale. Comunque sii molto (e sottolineo molto) sicuro del fatto tuo prima di provare tutto questo. La linea tra correttezza ed inciviltà e l'inziare un'inutile guerra a colpi di post infuocati è abbastanza sottile che gli stessi hackers non di rado fanno l'errore di attraversarla; che tu sia un novizio o un estraneo (di quella comunità, NdT) hai basse chances di scampare ad un tale errore. Se preferisci raccogliere informazioni piuttosto che divertirti allora è meglio che tiene lontane le tue mani dalla tastiera, onde evitare rischi di sorta.
(Alcune persone sostengono che molti hackers hanno una forma lieve di autismo o Sindrome di Asperger, sono mancanti di una circuiteria cerebrale che lubrifichi le interazioni sociali umane normali. Questo può essere o non essere vero. Se non sei tu stesso un hacker, questo può aiutarti a far fronte alle nostre eccentricità se pensi a noi come ad esseri dal cervello bacato. Avanti, forza! Non ci facciamo caso; ci piace essere qualsiasi cosa siamo, e solitamente abbiamo un elevato scetticismo per le etichette cliniche.)
Nella prossima sezione parleremo di una questione differente, il tipo di maleducazione che vedrai quando ti comporterai male.
Quando questo accade, la peggior cosa che puoi fare è piagnucolare sulla tua esperienza, affermare di essere stato assalito verbalmente, chiedere le scuse, urlare, trattenere il fiato, minacciare cause legali, protestare con gli impiegati, lasciare alzato il coperchio del wc, ec... Invece, ecco quello che devi fare:
Lasciar perdere. E' normale. E' perfettamente sano ed appropriato.
Gli standard della comunità non si automantengono: Vengono matenuti dall'attività delle persone che li applicano, con visibilità, in pubblico. Non lagnatevi sostenendo che tutte le critiche dovrebbero convergere attraverso la posta privata: Non è così che funziona. Neppure insistere di essere stati personalmente insultati quando qualcuno commenta che uno dei vostri reclami sia sbagliato, oppure differisca il punto di vista. Questi sono atteggiamenti da perdente.
Ci sono stati forum di hacker dove, al di fuori di qualche fuorviante senso dell'iper-cortesia, i partecipanti sono stati esclusi (banned) dal postare un qualsiasi trova-falla con i post di un'altro con diciture del tipo: "Non dite nulla se non siete disposti ad aiutare l'utente". Il risultante allontanamento dei partecipanti più capaci da qualche altra parte lo hanno retrocesso in un inutile ed insignificante cicaleccio di forum tecnico.
Esageratamente amichevoli (che è di moda) o utili: Sceglietene uno.
Ricordate: Quando quell'hacker vi dice che avete scazzato alla grande (non importa quanto scortese) vi dice di non farlo più, manifestando il concetto per voi e la sua comunità. Sarebbe molto più facile per lui ignorarvi e filtrarvi dalla sua vita. Se non riuscite a capire questo ed essergli grati, almeno abbiate un po' di dignità, non piagnucolate, e non aspettatevi di essere trattati come una bambolina fraglie solo perchè siete un nuovo venuto con un'anima teatralmente ipersensibile e delusioni di diritto.
| D: | Dove posso trovare il programma o la risorsa X ? | ||||||||
| R: | Nello stesso posto dove l'ho trovata io, scemo – al termine di una ricerca sul web. Mio dio c'è ancora qualcuno che non sa usare Google? | ||||||||
| D: | Come posso usare X per fare Y ? | ||||||||
| R: | Se quello che vuoi è fare Y, dovresti fare la domanda senza presupporre l'uso di un metodo che potrebbe non essere appropriato. Domande in questi termini indicano spesso persone che non sono semplicemente ignoranti su X, ma confuse su cosa il problema Y risolva effettivamente fissandosi troppo sui dettagli di una particolare situazione. In generale è meglio ignorare tali persone finchè non definiscono meglio il loro problema. | ||||||||
| D: | Come posso configurare il prompt della mia shell ? | ||||||||
| R: | Se se intelligente abbastanza per fare questa domanda, lo sarai anche per RTFM e trovartelo da solo. | ||||||||
| D: | Posso convertire un documento AcmeCorp in un file TeX usando il convertitore Bass-o-matic ? | ||||||||
| R: | Prova e vedi. Se l'hai fatto, otterrai (a) la risposta e (b) smettere di farmi perdere tempo. | ||||||||
| D: | Il mio {programma, configurazione, comando SQL} non funziona | ||||||||
| R: | Questa non è una domanda, e non sono interessato nel giocare a farti venti domande per tirarti
fuori la domanda giusta – Ho cose migliori da fare. Nel vedere una cosa
simile, la mia reazione è normalmente una delle seguenti: - hai qualcos'altro da aggiungere a questo? - Oh, ma che brutta cosa, spero che tu riesca a risolverla. | ||||||||
| D: | Sto avendo problemi con una mia macchina Windows. Puoi aiutarmi? | ||||||||
| R: | Si. Butta nella spazzatura Microsoft ed installa un sistema operativo open-source come Linux o BSD. | ||||||||
| D: | Il mio programma non funziona. Penso che l'utility di sistema X sia danneggiata. | ||||||||
| R: | Mentre è possibile che tu sia la prima persona a rendere noto di un'ovvia deficienza di una chiamata
di sistema e libreria pesantemente usata da centinaia se non migliaia
di persone, è molto più probabile che tu non abbia alcuna prova a
riguardo. Un'affermazione straordinaria richiede una prova
straordinaria; quando fai un'affermazione del genere,
devi dimostrare la prova dell'errore con una chiara ed
esautiva documentazione.
| D: | Sto avendo problemi nell'installazione di Linux o X. Puoi aiutarmi? | R: | No. | Per il tipo di problematica avrei bisogno di un accesso manuale sulla tua macchina. Rivolgiti al tuo Linux User Group locale (LUG). (Puoi trovare una lista qui) D: | Come posso craccare l'utente root/rubare i privilegi per i channel-options/leggere l'email di qualcuno? | R: | Sei uno che vive di espedienti per volere una cosa simile e un'idiota per chiedere ad un hacker che ti aiuti. | |
Stupido: "Dove posso trovare cose riguardo al Foonly Flurbamatic?"
Questa domanda otterrà solo un STFW come risposta.
Intelligente: "Ho usato Google per cercare di trovare 'Foonly Flurbamatic 2600' sul Web, ma non ho trovato nulla di utile. Qualcuno sà dove trovare informazioni di programmazione su questo dispositivo?"
Questo significa che le ricerche che doveva le ha fatte per cui sembra avere un vero problema.
Stupido: "Non riesco a compilare il codice del progetto foo.
Perchè si blocca?"
Presume che qualcun'altro abbia "cannato". La sua arroganza.
Intelligente: "Il codice del progetto foo non si compila sotto Nulix versione 6.2. Ho letto le FAQ, ma non dice nulla sui problemi relativi al Nulix. Ecco la trascrizione dei miei tentativi di compilazione; è per qualcosa che ho fatto?"
Specifica l'ambiente e ha letto le FAQ, ha mostrato l'errore e non presume che dipenda dalla colpa di qualcun'altro. Questo tizio può essere meritevole di un po' di attenzione.
Stupido: "Sto avendo problemi con la mia motherboard. Qualcuno può aiutarmi?" L'hacker di turno (J.Random Hacker, NdT) potrebbe rispondere in questo modo: "Giusto! Vuoi anche che qualcuno ti faccia fare il ruttino?" seguito da una manciata di tasti Canc (Delete Key, del tipo [Delete][Delete][Delete], NdT)
Intelligente: "Ho provato X, Y e Z sulla motherboard S2464. Quando non ha funzionato, ho provato A, B e C. Noto un curioso sintomo quanto ho provato C. Ovviamente il trabiccolo continua a cosare (the florbish is grommicking, è abbastanza intraducibile, NdT), ma i risultati non sono quelli che uno si potrebbe aspettare. Quali sono i motivi comuni di questo comportamento (grommicking, come sopra, NdT) sulle motherboard degli Athlon MP? Qualcuno ha altre idee per nuovi test da effettuare in modo da definire con precisione il problema?"
Questa persona, d'altro canto, sembra meritevole di una risposta. Ha mostrato un'intelligenza nel risolvere problemi a differenza di chi, passivamente, attende che la risposta gli cada dall'alto.
Nell'ultima domanda, notate la sottile ma importante differenza tra il domandare "Dammi una risposta" ed il "Per favore aiutatemi a capire quale altro diagnostico posso lanciare per avere un'illuminazione".
Infatti, la forma dell'ultima domanda è abbastanza simile ad un fatto realmente accaduto nell' Agosto del 2001, sulla mailing list di linux-kernel (lkml). Io (Eric) ero quello che ha fatto la domanda in quel modo. Stavo assistendo a misteriosi blocchi sulla motherboard Tyan S2462. I membri della lista mi hanno fornito le informazioni critiche di cui avevo bisogno per risolvere il problema.
Fare una domanda in questo modo da alle persona un qualcosa su cui rimuginare; li ho coinvolti perchè ho reso il tutto facile ed affascinante. Ho dimostrato rispetto verso i miei "colleghi", invitandoli a consultarmi come se fossi uno di loro. Ho anche dimostrato rispetto per il valore del loro tempo parlandogli dei vicoli ciechi i cui mi ero imbattuto.
Infine, quando ho ringraziato tutti rimarcando come il tutto sia stato ben svolto, un membro della lista ha sottolineato come il tutto abbia funzionato non perchè fossi un "nome" di quella lista, ma perchè ho posto la domanda in una forma corretta.
Gli Hackers sono, in alcuni casi, spietatissimi riguardo alla meritocrazia; ed è giusto, di questo ne sono sicuro, infatti se mi fossi comportato come uno scroccone sarei stato insultato (flamed, ovvero coperto di flame, messaggi infuocati di insulti, NdT) o ignorato, non importa chi realmente fossi. Il suggerimento di scrivere l'intero incidente come istruzioni per altri mi hanno portato alla creazione di questa guida.
Solitamente il semplice ri-postare la domanda è una pessima idea. Verrebbe visto come un'inutile seccatura.
Ci sono altre fonti dove cercare aiuto, magari migliori per le necessità di un novizio.
Ci sono molti gruppi di utenti online e locali che sarebbero entusiasti di parlare di software, sebbene nessuno di loro ne abbia mai scritto uno. Questi gruppi spesso si formano in modo da potere aiutare sè stessi ed i nuovi utenti.
C'è anche una grande abbondanza di aziende commerciali che si possono contattare per un aiuto, sia grandi che piccole (Red Hat e Linuxcare sono due tra le più conosciute; ma ce ne sono molte altre). Non spaventarti dall'idea di dover pagare per un po'di aiuto! Dopotutto se ti si rompe un pezzo del motore della macchina le tue uniche chanches sono quelle di ricomprartelo e pagare qualcuno che te lo monti.
Anche se il software non costa nulla non puoi aspettarti che sia gratis anche il supporto.Per un software popolare, come Linux, ci sono almeno 10.000 di utenti per sviluppatore. Non è possibile per un'unica persone gestire chiamate per l'assistenza di 10.000 utenti. Ricorda che, anche se devi pagare per il supporto, la tua spesa sarebbe di gran lunga inferiore a quella che avresti potuto sostenere col congiunto acquisto di software. (ed il supporto per il software proprietario è solitamente più caro e meno competente di quello open-source)
Se non lo sai per certo, dillo! Una risposta sbagliata che suona come autoritaria è peggio del non rispondere. Non dare false piste semplicemente perchè è divertente apparire come un esperto. Sii umile ed onesto, dando il medesimo buon esempio sia ai tuoi pari che a tutti gli altri. Se non puoi essere d'aiuto, non essere di ostacolo. Non farti beffe delle procedure per incasinare il setup dell'utente – il poveraccio di turno le deve interpretarle come istruzioni.
Chiedi di scandagliare la domanda per ottenere più dettagli. Se sei bravo in questo, colui che ti ha fatto la domanda imparerà qualcosa – come tu del resto. Cerca di trasformare una pessima domanda in una buona; ricorda che novizi lo siamo stati tutti una volta.
Se il brontolare RTFM è talvolta giustificato quando si replica ad un pigro parassita, accennare alla documentazione (anche come solo suggerimento ad usare una chiave di ricerca su Google) è meglio.
Se ti accingi a dare una risposta, dai buone argomentazioni. Non suggerire rimedi improvvisati quando qualcuno sta usando lo strumento o l'approccio sbagliato. Suggerisci gli strumenti giusti. Riformula la domanda.
Aiuta la tua comunità ad imparare delle domande. Quando rispondi abilmente ad una, chiediti "Come si può modificare in maniera rilevante la documentazione o FAQ per evitare che altri debbano nuovamente rispondere?" Di seguito basterà inviare una patch al manutentore della documentazione.
Se hai fatto ricerche per rispondere alla domanda, dimostra il tuo talento e non scrivere la prima cosa che ti esce dal sedere. Dare una buona risposte è come nutrire un affamato con un pasto, ma insegnargli con esempi a come fare bene le ricerche lo aiuterà a sfamarsi per il resto della vita.
Quando rilasci software o scrivi patch per software, cerca di seguire l'orientamento di: Software Release Practice HOWTO