[PLUTO-ildp] Linee guida - ILDP
Ferdinando
zappagalattica a inwind.it
Lun 12 Maggio 2003 19:36:26 CEST
Salve !!!
Ho scritto un documento che, opportunamente affinato da voi tutti
potrebbe rappresentare le future linee guida del progetto.
Spero riesca a dare uno spunto per una discussione costruttiva.
Naturalmente ho il sorgente, se volete vi spedisco anche quello così
potrete riutilizzarlo.
Gli ex-coordinatori dovrebbero poi rispondere alla sezione 4.1.1
"Problemi" ...
Ciao
Ferdinando
-------------- parte successiva --------------
Linee guida del progetto ILDP
Ferdinando Ferranti, zappagalattica a inwind.it
v0.1, 13 maggio 2003
Questo documento, elaborato con il contributo di tutti i partecipanti
al progetto ILDP presso il Pluto individuerà delle linee guida che in
futuro dovranno essere seguite per gestire il progetto.
______________________________________________________________________
Indice Generale
1. Premessa
2. Introduzione
2.1 Scopi di ILDP
2.2 Problemi
3. Organizzazione
3.1 Riferimenti web
3.2 La form
4. Descrizione dei ruoli in dettaglio
4.1 Il coordinatore del progetto
4.1.1 Problemi
4.2 Il revisore
4.3 Il tecnico
4.4 Il traduttore
______________________________________________________________________
11.. PPrreemmeessssaa
Tutte le sezioni intitolate "Problemi" andranno rimosse se si converrà
di adottare questo documento per identificare le linee guida di ILDP.
22.. IInnttrroodduuzziioonnee
Nessun progetto serio può prescindere da un'organizzazione che abbia
delle regole a cui attenersi. La libertà non è data dalla forza con la
quale esse esercitano una coercizione sull'organizzazione, ma da come
siano state elaborate e da quanto siano flessibili ed aperte al
cambiamento.
Prima di esporre le linee guida, occorre fare delle considerazioni che
potranno servire ad interpretarle meglio.
È passato molto tempo da quando è stato fondato il progetto ildp,
molte persone hanno partecipato e se ne sono andate, altre ne sono
arrivate. Sicuramente tutte queste persone hanno avuto in comune la
passione per il software libero e la voglia di restituire in qualche
modo tutto ciò che hanno ricevuto da GNU/Linux. Però ci sono delle
differenze, il tempo passa, l'utilizzo di GNU/Linux è progressivamente
divenuto molto più semplice e la "qualità media" degli utilizzatori si
è conseguentemente abbassata. Potrebbe non sembrare un problema ma
invece si dimostra tale perché mentre un utilizzatore esperto del
sistema non ha alcun problema a tradurre direttamente dal codice SGM o
XML mentre un _n_e_w_b_i_e alcune volte si e si scoraggia. La gestione di
ildp, diversamente dal passato, si deve occupare di queste
problematiche ed occorrono quindi profonde modifiche alla gestione del
gruppo. Quando tutto sommato non c'erano problemi di sorta, ogni
singolo partecipante si sceglieva il proprio documento senza problemi.
Con queste linee guida si cercherà quindi di dare una risposta a
questi problemi, cercando di creare delle figure che affianchino il
_c_o_o_r_d_i_n_a_t_o_r_e, con lo scopo di alleggerire notevolmente il suo lavoro,
permettere l'ingresso nel gruppo dei _n_e_w_b_i_e, cercando di farli sentire
veramente partecipi all'evoluzione del progetto, divertendoli, senza
fargli sembrare la traduzione di un documento un lavoro troppo
pesante. Il "problema" è fondare un gruppo di "figure" più
professionali, che siano in grado di seguire i nuovi entrati, una
sorta di "tutor" per ognuno di loro.
Oltretutto finora c'era anche il problema derivante dalla traduzione
di documenti piuttosto voluminosi. Con queste linee guida il problema
si dovrebbe risolvere da solo, in quanto il _c_o_o_r_d_i_n_a_t_o_r_e in caso di
documenti di una certa dimensione potrà decidere di spezzarli ed
assegnarli a più traduttori.
Naturalmente le nostre regole, prima di essere adottate, saranno
discusse pubblicamente sulla mailing list di ILDP e saranno sempre
aperte a cambiamenti che possano portare vantaggi all'organizzazione.
22..11.. SSccooppii ddii IILLDDPP
ILDP si propone lo scopo ambizioso di essere il punto di riferimento
per la documentazione italiana su GNU/Linux ed in generale sul
software libero. Il progetto, visti gli scopi, è legato a doppio filo
a tldp <http://www.tldp.org> e quindi è necessario che sia in grado di
tradurre e rendere disponibili i documenti ivi reperibili.
22..22.. PPrroobblleemmii
Tanti ...
· Aggiornare il documento reperibile presso
http://www.pluto.linux.it/ildp/HOWTO/statoTraduzioni.html
<http://www.pluto.linux.it/ildp/HOWTO/statoTraduzioni.html> che
rappresenta una fotografia delle differenze tra ildp e tldp.
· Per rendere più semplice la gestione del documento di cui al
precedente punto è necessario dare priorità all'aggiornamento dei
documenti già tradotti.
· Fare in modo che la gestione dei documenti da tradurre o aggiornare
sia obbligatoriamente pubblica e quindi evitare post privati al
_c_o_o_r_d_i_n_a_t_o_r_e del progetto.
· Creare una sorta di _f_o_r_m standard che indichi l'assegnazione di un
documento, la sua revisione ecc. ecc. comprensiva di data di
assegnazione e dei soggetti interessati.
· Provvedere all'upload dei documenti finiti in tempi rapidi.
· Chiarire bene il formato da adottare, su tldp adesso usano DocBook
con XML, qui ancora si usa LinuxDoc ... convertire i documenti e
aprire due directory, sgml e docbook come su tldp e poi, con calma,
provvedere alla conversione? è anche questo un punto da chiarire
subito perché per i nuovi documenti il problema si pone
immediatamente ...
33.. OOrrggaanniizzzzaazziioonnee
L'organizzazione del progetto dovrebbe essere il più lineare, semplice
ed efficiente possibile, dovrebbe impegnare relativamente poco il
_c_o_o_r_d_i_n_a_t_o_r_e ed attrarre il maggior numero possibile di _n_e_w_b_i_e
A questo scopo, differentemente che in passato, il _c_o_o_r_d_i_n_a_t_o_r_e verrà
affiancato da varie figure, aventi ``ruoli'' differenti, che lo
aiuteranno nella gestione del progetto. La gestione del progetto sarà
quindi interamente pubblica ed il _c_o_o_r_d_i_n_a_t_o_r_e non dovrebbe essere
contattato privatamente se non in casi eccezionali e solamente dai
suoi più stretti aiutanti e cioè _r_e_v_i_s_o_r_i e _t_e_c_n_i_c_i.
Solamente il _c_o_o_r_d_i_n_a_t_o_r_e ha il potere di assegnare una traduzione o
un'aggiornamento. Potrà certamente, contrariamente a queste linee
guida, discostarsene per accettare un documento che sia stato
realizzato per intero da un "esterno" o da un membro del gruppo di cui
ha fiducia, che avrà svolto tutti i passi che ci accingeremo a
descrivere da solo, in autonomia.
Il _c_o_o_r_d_i_n_a_t_o_r_e dovrebbe, in maniera pubblica, attraverso la mailing
list di ildp, organizzare le traduzioni, informando dell'inizio di una
traduzione tramite un post di tipo prestabilito, una _f_o_r_m contenente i
dati necessari ed aggiornarla personalmente o delegando il _r_e_v_i_s_o_r_e
incaricato, di aggiornarla per la parte di propria competenza.
Il sistema permetterà una traduzione o l'aggiornamento in maniera
semplice di un documento perché il _t_r_a_d_u_t_t_o_r_e lavorerà direttamente su
testo puro che rispedirà al _c_o_o_r_d_i_n_a_t_o_r_e o direttamente al _r_e_v_i_s_o_r_e se
già individuato. (************* DECIDERE I PASSAGGI, SE PASSARE DAL
COORDINATORE O DELEGARE A REVISORE E TECNICO **************) A questo
punto, aggiornato il post, con tanto di data e passaggio di mano del
documento, lo stesso verrà poi trasferito ad un _t_e_c_n_i_c_o, nella più
comoda versione in testo puro. Quest'ultimo controllerà la traduzione
dell'originale e a lavoro ultimato, lo spedirà nuovamente al
_r_e_v_i_s_o_r_e. Per meglio chiarire, il documento che riceverà il _t_e_c_n_i_c_o,
sarà stato realizzato dal _r_e_v_i_s_o_r_e, che lascerà nel testo entrambe le
lingue, ovvero l'inglese originale e la traduzione. Successivamente
il _r_e_v_i_s_o_r_e, dopo aver ricevuto il testo, toglierà la parte in lingua
madre e revisionerà la restante parte in italiano. Il documento sarà
così pronto per l'upload.
È utile segnalare che questo tipo di organizzazione consentirà di
liberare da vari compiti il _c_o_o_r_d_i_n_a_t_o_r_e, che potrà così dedicarsi con
maggiore efficienza all'organizzazione delle priorità a cui fare
fronte.
33..11.. RRiiffeerriimmeennttii wweebb
Occorre inserire in questo spazio i riferimenti web di dove sono i
documenti da tradurre, quelli tradotti e quelli da aggiornare, questa
è la partenza, http://ftp.pluto.linux.it/pub/pluto/ildp/
<http://ftp.pluto.linux.it/pub/pluto/ildp/>, se non ho capito male poi
ci dovrebbero essere ./HOWTO/sgml per i sorgenti degli HOWTO "pronti",
./HOWTO/mini/sgml per i mini-HOWTO e ./Nuovi per i sorgenti "in
lavorazione", di cui fare successivamente l'upload.
33..22.. LLaa ffoorrmm
La _f_o_r_m avvisa i partecipanti al progetto che il _c_o_o_r_d_i_n_a_t_o_r_e ha
assegnato un documento ad un _t_r_a_d_u_t_t_o_r_e, riporta il _r_e_v_i_s_o_r_e/_r_e_v_i_s_o_r_i
a cui verrà poi spedito per la lavorazione. Documenta anche, con tanto
di data, tutti i passaggi tra i vari soggetti interessati. Il Subject
avrà uno specifico TAG e cioè [HOWTO], [mini-HOWTO] o [guida]. A
seguito un esempio di _f_o_r_m:
Subject: [HOWTO] DocBook-OpenJade-SGML-XML
From: email_coordinatore a linux.it
Reply-To: Italian Linux Documentation Project <pluto-ildp a lists.pluto.linux.it>
Date: xxx, xxxxxx
To: pluto-ildp a lists.pluto.linux.it
Traduttore: Nome traduttore - e-mail_traduttore
assegnato in data: xx/xx/xxxx
il documento DocBook-OpenJade-SGML-XML.txt
Revisore: Nome revisore - e-mail revisore
assegnato in data:
Tecnico: Nome revisore - e-mail revisore
assegnato in data:
Revisore: Nome revisore - e-mail revisore
Il documento DocBook-OpenJade-SGML-XML.xml
è pronto per l'upload - data:
44.. DDeessccrriizziioonnee ddeeii rruuoollii iinn ddeettttaagglliioo
In questa sezione verranno analizzate le varie figure che
costituiranno l'ossatura dell'organizzazione.
44..11.. IIll ccoooorrddiinnaattoorree ddeell pprrooggeettttoo
La figura del _c_o_o_r_d_i_n_a_t_o_r_e naturalmente è la più importante del
progetto.
I suoi compiti sono molteplici, i più importanti si possono così
sintetizzare:
· Tenere aggiornato il documento:
http://www.pluto.linux.it/ildp/HOWTO/statoTraduzioni.html
<http://www.pluto.linux.it/ildp/HOWTO/statoTraduzioni.html>
· Conseguentemente all'aggiornamento, procurarsi i vari diff
(preferibilmente in formato diff -u ...) per aggiornare i
documenti.
· Decidere a quali documenti dare priorità e richiederne la
traduzione o l'aggiornamento in lista. (***************** DARE
PRIORITA' AGLI AGGIORNAMENTI!!! ***********)
· Avere un elenco dei suoi collaboratori più stretti e cioè _r_e_v_i_s_o_r_i
e _t_e_c_n_i_c_i.
· Quando necessario fare una campagna di reclutamento tra le mailing
list ed i vari news group dove potrebbero esserci persone
interessate, in pratica in ML e ng dedicate a GNU/Linux.
44..11..11.. PPrroobblleemmii
Beh, ragazzi, chi ha fatto il coordinatore tiri fuori gli altarini!!!
Io ho dato per scontato che i problemi maggiori siano state le e-mail
private che riceveva il coordinatore perché altrimenti serve a poco
discutere sul niente...
Sicuramente il _c_o_o_r_d_i_n_a_t_o_r_e dovrebbe aggiornare il "documento" che
"sincronizza" ildp con tldp, assegnare personalmente i documenti da
aggiornare prima e da tradurre poi. Spero di avere individuato il
problema perché se non fosse questo allora c'è ben poco da fare.
Seguendo queste linee guida che ho abbozzato il coordinatore non mi
sembra che avrebbe chissà quale gran da fare, dovrebbe semplicemente
avere banda, un elenco di collaboratori più o meno fidati (all'inizio
può anche prendere un volontario alla volta ed assegnargli i "galloni"
sul campo ...) ed un elenco di priorità da seguire ...
Il lavoro da fare più grosso è ora, perché, anche per avere una
manutenzione più semplice del "documento" è necessario fermarsi, fare
il punto ed aggiornare tutti i documenti già tradotti. So che è una
palla però questa dovrebbe essere la priorità più urgente, dopo
dovrebbe diventare tutto più semplice.
Spero che questo documento vi serva ...
44..22.. IIll rreevviissoorree
Per ricoprire la figura del _r_e_v_i_s_o_r_e è obbligatorio avere almeno
queste due caratteristiche:
· Conoscenza di DocBook e LinuxDoc, niente di trascendentale, è
sufficiente che i documenti che rilascia possano essere compilati
senza errori in tutti i formati previsti.
· Conoscenza dell'italiano ... per questa figura non è necessario
conoscere l'inglese ma almeno l'italiano si ...
A margine delle competenze necessarie è compito del _r_e_v_i_s_o_r_e, nel
corso di una traduzione, aiutare, sostenere ed indirizzare il
_t_r_a_d_u_t_t_o_r_e, ove si trovasse in difficoltà e avesse bisogno di
suggerimenti o consigli. In pratica sarà il suo "tutor".
44..33.. IIll tteeccnniiccoo
Per ricoprire la figura del _t_e_c_n_i_c_o è obbligatorio avere almeno queste
due caratteristiche:
· Conoscenza dell'inglese, perché dovrà controllare che la traduzione
effettuata dal _n_e_w_b_i_e sia aderente alla realtà.
· Conoscenza del sistema GNU/Linux, i concetti base della
programmazione, delle reti e quant'altro utile a correggere
eventuali inesattezze o termini non tradotti nel testo.
44..44.. IIll ttrraadduuttttoorree
Sostanzialmente la figura più semplice ma forse la più importante è
quella del _t_r_a_d_u_t_t_o_r_e, può essere tranquillamente un _n_e_w_b_i_e, (meglio
se lo fa presente ...), non vi sono problemi di sorta, l'unica
competenza richiesta è la volontà e la conoscenza dell'inglese. Con il
passare del tempo, a sua discrezione potrà anche richiedere di essere
impiegato in ruoli più "professionali", ovvero quelli citati in
precedenza. A discrezione del _c_o_o_r_d_i_n_a_t_o_r_e e sentiti i _r_e_v_i_s_o_r_i con i
quali ha collaborato.
Maggiori informazioni sulla lista
pluto-ildp