da samiel » gio feb 03, 2005 15:03
Anch´io penso che limitarsi a tradurre sia un tantino limitativo.
<BR>Lo Slackware Handbook del progetto sarà senz´altro un lavoro notevole,
<BR>ma trovo discutibile impegnarsi a tradurre un testo che non esiste ancora
<BR>e che nessuno può perciò aver visto. Inolte tutti sappiamo che
<BR>l´utilità di manuali di questo tipo si traduce nell´applicazione pratica.
<BR>Non si tratta di testi "da leggere", ma che sono tanto più riusciti
<BR>quanto più, seguendo le loro indicazioni, risolviamo i nostri problemi.
<BR>Per cui provare, verificare e quindi dar conto delle nostre soluzioni,
<BR>il tutto in prima persona, è davvero l´unica via di apprendimento.
<BR>Certo, come scrivevo, un lavoro collettivo richiede continuità di impegno
<BR>da parte di tutti o rischia facilmente di restare inattuato. Inoltre,
<BR>è necessario un lavoro di pianificazione preciso: individuare gli argomenti.
<BR>trovare chi li può svolgere, darsi scadenze chiare e imperative.
<BR>So quanto sia difficile, essendo io in questo periodo impegnato
<BR>proprio nella direzione di un´opera collettiva (tutt´altro che informatica)
<BR>che coinvolge una decina di collaboratori e una grossa casa editrice.
<BR>Il carattere libero e "da appassionati" del nostro lavoro rappresenta
<BR>al tempo stesso una garanzia e un rischio. Se vogliamo che l´entusiasmo
<BR>del momento non resti solo tale, bisognerebbe che qualcuno
<BR>avviasse l´elaborazione di un progetto da sottoporre poi alla discussione.
<BR>Io continuo col mio "assolo" di Slack4dummies 3° ed., che però potrebbe
<BR>costituire un primo brogliaccio da ampliare di un lavoro diverso e più ampio.
<BR>Credo che partire dalla *nostre* esigenze e dai *nostri* problemi
<BR>potrebbe essere più stimolante e costruttivo di seguire un lavoro altrui.
<BR>
<BR>M.<br>