untitled


 

 

Filosofia - funzionamento di un progetto OpenTheory  19-01-2004

Bozzetti del Progetto OpenTheory

Fondazione di progetti a teoria aperta

1)     Vorrei presentare la mia idea per un nuovo progetto. Deriva da discussioni su diversi mailing lists, conversazioni riguardo al Linux Day in Kaiserlautern, reazioni a miei testi e discorsi e molto altro. Vorrei dare un carattere più mirato a tali discussioni e provvedere alla reperibilità dei risultati. Vorrei vedere se lo sviluppo collettivo di teorie funziona.

2)     Mi immagino progetti Open Theory (OT) in analogia ai progetti di software Open Source. Un progetto OT ha:

- un tema, espresso da un testo base nel Web;
- un Maintainer;
- dei Membri;
- un Forum di discussione interattivo;
- una licenza che lo protegge e ne garantisce la libertà.

Esempi di queste licenze sono la licenza OpenContent, Open-Publication e la licenza GNU Free Documentation.

(2.1) 07.03.2000 Stefan Meretz: ho deciso per la licenza GNU. Si riferisce a software, ma accenna all’utilizzo per altri documenti.

3)     Il testo base viene discusso con lo scopo di migliorare, cambiare o completarne alcune parti Le discussioni si svolgono sul forum apposito, in cui ogni riferimento dovrebbe essere esplicitato attraverso citazioni. Gli interventi si distinguono con una diversa indentazione e vengono inseriti al posto giusto dal Maintainer. Discussioni riguardo a discussioni sono possibili e vengono indentate più a destra. Questo sistema è ripreso dagli archivi delle mailing lists, dove l’indentazione riguarda non solo il soggetto, ma anche il paragrafo di riferimento. Se poi diventa troppo e illeggibile, dobbiamo ancora vederlo. Dopo i recenti interventi sul tema Linux direi che può funzionare. Dopo un certo periodo di discussione, il Maintainer riassume gli interventi in una nuova release del testo base – e la discussione ricomincia. Le versioni precedenti rimango disponibilie consultabili.
     (3.1) 17.01.2000 Stefan Meretz: Questo è un esempio di commento ad un paragrafo. Ogni commento può venire nuovamente commentato, e possiede come i paragrafi principali un link “Commenta”.
           (3.1.1) 10.03.2000 Johannes Busse: Ciò significa che si viene a creare un albero di commenti ai commenti. I membri hanno anche la possibilità di rielaborare il testo, cioè di cambiare anche strutturalmente quanto è già stato scritto? O può farlo solo il Maintainer?
                     (3.1.1.1) 11.03.2000 Stefan Meretz: Intendo “commentare” come parte del lavoro in comune. “Commentare” suona forse troppo poco importante. Si possono consigliare i cambiamenti strutturali attraverso un commento, allo stesso modo in cui si discute il contenuto di un paragrafo. Dovrebbe forse esserci un link tipo “Cambiamenti generali al testo”? Ho paura dei metadibattiti, ma forse ci si può provare. E’ vero il fatto che il Maintainer decide struttura e nuove versioni.  Chiunque può però diventare Maintainer, e dare allo stesso tema una discussione strutturalmente diversa. Quindi si crea una sorta di competizione: chi ha le discussioni più interessanti, chi riesce a portare le idee migliori, ecc... – una competizione senza incentivi monetari, ma a livello di contenuti. Ho  già ricevuto la proposta di abilitare Maintainer multipli. Lavoro da programmatori...
      (3.2) 27.03.2000 Stefan Merten: Ciò che mi disturba alla realizzazione tecnica (fino adesso) è che i commentatori/trici sono obbigati ad adattarsi alla granularità del testo.  troverei desiderabile il potersi riferire direttamente ai passaggi di interesse – per esempio alle singole frasi. Dovrebbe funzionare, almeno sulla pagina Web. D’altra parte, ciò renderebbe obsoleta la numerazione dei paragrafi, cosa che trovo un poco preoccupante e problematica.
              (3.2.1) 30.03.2000 Stefan Meretz: Disturba anche me, ma hai un’altra idea? E come la si può realizzare tecnicamente- anche come superficie web? Lo dici con tanta tranquillità... bisognerebbe salvare ogni singola frase per renderla poi commentabile. Ma come si mette a disposizione, poi? Dovrei inserire dopo ogni frase un link “Commenta”.
                    (3.2.1.1) 16.12.2000 Marc Lustig: Il problema si potrebbe proseguire: non vorremmo a volta commentare una singola espressione e riferirci direttamente a questa? Quindi: perchè non inserire ogni elemento del tetsto nel database? Paragrafo, frase, parola. Dovrebbe essere inoltre possibile inserire oggetti web, tipo grafici e immagini interattive. In particolare quest’ultimo mi sembra necessario per una costruzione teorica collettiva.
                   (3.2.1.2.) 15:18, Stefan Meretz: Stefan Meretz ha scritto sulla mailing list:
> Ho un’idea per il link “Commenti”: lo potresti inserire sempre dopo un punto o uno >spazio vuoto. Non disturba ma si nota a sufficienza da essere praticabile.

Ci avevo pensato anch’io, ma esistono numerosi esempi in cui il punto si può usare in altri casi in mezzo alla frase: ad esempio in p.e. (per esempio) o ecc... Ricorrere a liste di eccezioni non è molto praticabile, perchè ad esempio u.s.w. (und so weiter, così via) alla fine di una frase significa davvero la fine della frase (il punto ha, diciamo, una doppia funzione). E l’idea di Marc si spinge persino oltre (Intervento 3.2.1.1.)...

4)     Chiunque può iniziare un testo base OT e iniziare quindi un nuovo progetto OT. Può succedere per esempio quando un altro testo base viene radicalmente messo in discussione (analogia con l’open source software: code fork, ovvero quando il codice prende due direzioni diverse). Un progetto OT funziona se vi partecipano un numero sufficiente di persone, come avrete modo di vedere. Il Maintainer ha i seguenti compiti:
- Moderazione della discussione;
- release di nuovi testi base;
- decisioni sull’assunzione di nuove strutture del testo (nuovi subtemi)

5)     Il moderare non è una funzione formale, ma contenutistica. Formale lo è nel caso, ad esempio, di una mailing list dove ogni intervento viene considerato dal moderatore e passato, o meno. Non voglio questo. Moderazione contenutistica significa:
- riconoscere e distinguere nuove idee;
- lasciare spazio a diverse opinioni;
- contribuire ad un clima costruttivo;
- lasciare spazioll’interesse al risultato;
- creare trasparenza intorno alle decisioni.

6)     Ciò lo può fare chiunque, di fatto, che sia Maintainer o meno. Il Maintainer ha una certa responsibilità per il progetto, e dovrebbe anche quindi prendere la posizione di moderatore. Se non lo fa, allora il progetto è destinato al fallimento. A differenza di altri ruoli di moderazione, un moderatore OT non è neutrale. Ha una posizione di contenuto ed interesse a risultati. Non partecipa per “avere ragione” al costo di altri. In un progetto OT i Maintainer e i Membri sono in una situazione di Win-win. Caratterizzare il testo  può essere semplicemente una questione di qualità, e non deve per forza succedere a costo di altri. O il progetto ha una sua personalità, o no. La moderazione sui contenuti è quindi un compito molto importante e difficile.
     (6.1) 20.03.2000 Torsten Wöllert: Capito. Il moderatore conosce tutti i Membri, anche quelli che non hanno mai partecipato direttamente alla discussione?
           (6.1.1) 21.03.2000 Stefan Meretz: No. Ci si può avvicinare con una “lista dei desideri”: un modo per informarsi sui desideri dei Membri. Ma dovrebbe essere aperta a tutti i Membri.
                  (6.1.1.1) 27.03.2000 Stefan Merten: Concludo correttamente dall’intervento precedente che voi non usate nessun software per Mailing list – tipo majordomo?
                         (6.1.1.1.1) 30.03.2000 Stefan Meretz: Corretto. Tutto fatto in casa. Era molto più facile da realizzare, in quanto tutti i Membri sono tutti registrati nel database e ricevono quindi mail facilmente.
                  (6.1.1.2) 11.07.2000 Karl Dietz: Troverei positivo se ci si potesse conoscere. Ridurrebbe l’anonimità.

Release di nuovi testi base

7)     Come la correzioni del codice nel Progeto OSS, così gli interventi in un Progetto OT migliorano il testo base. Non esiste però nel Progetto OT un criterio concreto per la Qualità, come la velocità di un programma. D’altro canto, il fatto che un programma sia veloce non significa che esso sia elegante, utile, flessibile, ecc... Se una discussione si è “stabilizzata”, dopo un certo perioso di tempo, può avere significato raccogliere i cambiamenti e pubblicarli come nuovo testo base. Nuovi commenti ecc..., si riferiranno al nuovo testo base. Nuove release sono affare del Maintainer.
 

Decisioni sull’adozione di nuove strutture del testo

8)     Ogni discussione si ramifica in numerosi aspetti dimensioni, ecc... Nuove analogie e metafore gettano nuovi dubbi sulla validità delle metafore ecc... Non tutti i rami di una discussione sono interessanti. Ma se risulta che un particolare aspetto del tema principale deve essere meglio discusso, allora è compito del Maintainer riconoscere il fatto e sottoporre il sottotema a discussione. L’obiettivo di questi sottotemi è la loro reintegrazione nel testo alla prossima release. Nel caso questo non fosse possibile, perchè magari il sottotema cresce troppo e diventa un tema a se stante, allora sarebbe indicato dividere il progetto. Ma dovrebbe capitare raramente. Sarebbe meglio lasciar sviluppare i sottotemi all’interno del progetto, eventualmente sotto la supervisione di altri appositi Maintainer. In questo modo progetti anche molto grossi dovrebbero rimanere amministrabili.
(8.1) 20.03.2000 Torsten Wöllert: Come ce lo si deve immaginare in termini tecnici e di organizzazione? Il Moderatore può dividere il Progetto in parti diverse e indipendenti, che risultano quindi più facili da amministrare, o bisogna creare per ogni parte un progetto indipendente, col rischio di perdere lo sguardo d’insieme? C’è una limitazione al numero di sottotemi?
     (8.1.1) 21.03.2000 Stefan Meretz: La divisione di  progetti in sottoprogetti ha senso solo se una grandissima quantità di fili di discussione corrono paralleli (non è ancora capitato ;-)). Per il tuo Progetto-Enciclopedia mi potrei immaginare che esistano tanti temi indipendenti quanti sono i termini. Per lo sguardo di insieme mi posso ben immaginare l’esistenza di cose come “Temi” o “Campi” o qualcosa di più generale sotto cui si dibattono i diversi Progetti (o parti di progetti) – ma deve ancora essere sviluppato. Altre idee? Per il momento non sono molto vulcanico. Una limitazione al numero di componenti del testo non esiste, a livello logico, ma a quello fisico sì! :-)

9)     Un progetto OT si costruisce sotto la licenza OpenContent-Public o la licenza Open-Publication. Non mi sono ancora deciso. Entrambe assomigliano alla GNU GPL e garantiscono che:
- il testo può essere copiato liberamente, distribuito e modificato
- i cambiamenti vengono documentati
- la licenza non può essere modificata (non molto chiaro su questo punto)
Anche se non sono interamente paragonabili al software, le Licenze sono adatte a incoraggiare un processo di sviluppo apero di teorie . Chi ha voglia, può guadagnare soldi con la distribuzione dei testi. E’ importante che il testo originale e gli autori originali rimangano riconoscibili e che le variazioni vengano espresse e datate. La licenza Open-Publication è più chiara su questo punto, ma non proibisce espressamente il cambio di licenza. Al momento  la gente di Richard Stallman (grande guru di Internet, del paradgma della rete e del software libero, NdT) e la Free Software Foundation stanno lavorando ad un DGPL: Document Genral Public License. La scelta della giusta licenza durerà ancora un po’.
(9.1) 13.03.2000 Heike Schwarze: qui scrivi che un progetto OT dovrebbe essere coperto da una licenza OCPL o OPL. Sopra scrivevi che volevi una GNU. Sono molto simili, ma ci sono già diferrenze. Quale vale per questo progetto? E cosa succede quando il DPGL viene pronto? La appiccichiamo sopra al Progetto? Allora il terzo punto sarebbe in contraddizione (la licenza non si può cambiare). Inoltre mi verrebbe utile (e non solo a me) una traduzione della GNU FDL.
      (9.1.1) 13.03.2000 Stefan Meretz: hai ragione, paragrafo (2) e (9) sono incontraddizione. Sorry. Il mio paragrafo (2) dovrebbe essere inserito anche sotto il (9). Sono svivolato in una diversa versione del testo base. Sì, una traduzione della licenza in tedesco sarebbe molto utile. C’è qualcuno là fuori, del Progetto?

10)  Ogni Progetto OT ha un proprio forum di discussione e una mailing list propria. Consiglierei, però, una mailing list comune a tutti i progetti per scambiarsi informazioni ed esperienze. Progetti di nuova fondazione vengono generati automaticamente dopo il riempimento di un apposito formulario.
(10.1) 20.03.2000 Torsten Wöllert: Si viene inseriti automaticamente nella mailing list specifica e in quella generale dopo essersi iscritti ad un progetto?
     (10.1.1.) 21.03.2000 Stefan Meretz: No, al momento creerebbesolo confusione. Secondo il principio della destrutturazione (era una mail nel dibattito su OT – ecco, adesso non so più chi ce l’ha e chi no) lasciare tutte le pagine e tutte le liste come progetti. Per questo ci sarà appunto un progetto – forse più avanti – riguardo a OT in generale. In questo modo è tutto un po’ un doppio balbettare...

11)  Cercasi: Hacker che scriva un generatore di pagine HTML basato su una banca dati. Questo programma produce, a partire da un sistassi predefinita, blocchi di testo indentati in posizioni determinate da nuove numerazioni dei paragrafi.  (ecc.. molto tecnico, chissenefrega. Fine del testo)

Maintainer: Stefan Meretz, Version 2, 08.01.2004
Tipo: aperto
Status: attivo

 

 

 

Filosofia - Altri Link
Potete trovare altro sulla filosofia di Tränenburg a questi link interni:
 

  Rahmenbedingungen

  OpenTheory - versione italiana
  Funzionamento di un Progetto OpenTheory

e su questi link esterni:

 

  Rekombinant

  Ökonux

  OpenTheory