Comunità e gruppi

[Silvan]

Riporto sul forum una mail che ho scritto nella mailing list openmamba-users-it riguardante la prossima organizzazione della comunità di openmamba.

Ciao a tutti,

come già avevo annunciato mi occuperò di potenziare il supporto alla comunità

di openmamba a partire da dopo il rilascio della versione stabile milestone

1.

Intanto, visto l’interesse e la disponibilità di alcuni di voi a discutere ed

a partecipare comincio a scrivere due parole sull’argomento.

Per me la cosa migliore per la comunità di openmamba è di permetterne

l’autoorganizzazione e l’indipendenza di sviluppo e di rimanere generici

nelle definizioni dei ruoli (a differenza di quanto avevo pensato all’inizio

http://www.openmamba.org/community/).

La base per lo sviluppo di openmamba sono i vari repository, in quanto quasi

tutto ciò che riguarda lo sviluppo del sistema passa attraverso la

pacchettizzazione di RPM e questo include contenuti grafici e documentazione.

Sono escluse le attività esterne al sistema operativo tipo scrivere nel wiki,

gestire ed organizzare il sito, aggiungere contenuti riguardanti openmamba su

siti esterni ecc. ma anche in questo caso l’accesso personalizzato ftp

permette di avere un punto di collegamento attraverso openmamba.org per altre

eventualità.

Oggi ognuno ha la possibilità di avere un repository personale e con un

meccanismo che permette di spostare i pacchetti da un repository all’altro si

possono gestire i flussi di pacchetti a più livelli:

repository personale -> repository gruppo -> repository devel -> repository

stabile

Come si vede da questo esempio ho pensato di introdurre il concetto di gruppo:

due o più persone che fanno parte della comunità possono “raggrupparsi”. Ogni

gruppo quindi avrà il proprio nome e la propria definizione. Inizialmente

poiché ora la comunità non è grande e organizzata i gruppi creati potrebbero

essere generici (es. una di sviluppo generico, un’altra per lo sviluppo

web…) ed in futuro diventare sempre più specifici (es. gruppo sviluppo

grafica, gruppo gnome, gruppo server…).

Le due o più persone che formano il gruppo hanno i privilegi per gestire i

mezzi a disposizione e possono dare questi privilegi ad altri del gruppo. I

mezzi forniti sarebbero:

– repository corrispondente al gruppo

– mailing list

– area nel forum

– contact email su openmamba.org

– gestione bugs

– area nel wiki

– home page del gruppo (www.openmamba.org/groups/nome_gruppo.html)

E a venire:

– accesso a server per lo sviluppo condiviso (GIT o SVN)

Cosa ne pensate? Questo meccanismo mi sembra che possa seguire i principi di

sviluppo che sono propri del modello open source, ossia gruppi che si formano,

mutano, si distruggono come succede al software seguendo un modello che

dovrebbe portare naturalmente, al crescere dei membri della comunità, ad

avere una serie di gruppi specializzati in varie micro-attività.

Inoltre, poiché da parte mia non c’è la possibilità di fare un lavoro di

integrazione dei servizi al livello, ad esempio, di launchpad.net (ma magari

qualcuno potrebbe lanciare questo progetto attraverso un gruppo apposito),

cerco di proporre qualcosa che sia anche fattibile subito, sempre secondo il

modello Linux di partire da qualcosa che all’inizio faccia poco ma che

funzioni.

Cosa ne pensate? Questo può l’inizio di una discussione sull’organizzazione

della community, su cosa ne pensate di questo modello e se avete delle idee

diverse e potrebbe anche essere l’inizio di una discussione tra di voi per

porre le basi di un (o più) gruppo(i) di partenza.

Buona giornata,

Silvan

[fabiog]

Nell’insieme mi pare un progetto valido ed interessante, credo che stare a parlarne così in modo teorico però non possa essere molto produttivo. La cosa migliore è partire gradatamente con le cose come le hai ipotizzate tu e discutere di variazioni o nuove opzioni intanto che si procede!!

Io e Tiziana potremmo già diventare un primo gruppo di test del progetto, anzi un’ipotesi di lavoro potrebbe essere (con la tua supervisione) l’avvio della pacchettizzazione 64bit visto che il nuovo portatile che hanno dato in ufficio a Tiziana è un amd64!!

Fabio

[Bergoglio]

Questa idea di organizzazione mi aggrada molto.

Mi piacerebbe poter già creare 2 gruppi :

1) gruppo interfaccia utente / usabilità (si dovrebbe occupare di definire ad esempio di dove posizionare gli elementi sul pannello principale etc.)

2) gruppo programmi ufficio (si dovrebbe occupare di tutti quegli applicativi che vengono utilizzati in un normale uso da ufficio tipo OpenOffice).

Nei prossimi giorni vedo di convincere qualcun’altro ad unirsi alla community…..

Due domande che mi servono però per capire le regole generali di openmamba :

1) i vari gruppi che si occuperanno di pacchettizzazione devono rimanere fedeli alla regola “codice ufficiale rilasciato dal progetto” senza applicare patch reperite in chissà quale anfratto di internet? A mio modesto parere sì perché così si evita di cercare ulteriori casini, ma ditemi la vostra.

2) è vero che servono tanti programmi e quindi tanti rpm, ma si vuole procedere a pacchettizzare il mondo stile Debian o forse è meglio operare delle scelte precise eventualmente modificabili nel tempo (ad esempio stupido nei programmi da ufficio si può scegliere di inserire OpenOffice o Koffice o tutti e due, con relativa maggiore necessità di risorse da dedicare) ?

[Silvan]

Bene, vista la disponibilità sto procedendo più rapidamente per far avviare i primi gruppi. Ieri ho integrato l’autenticazione di bbpress (forum) con il sito principale ed ora posso realizzare una semplice form che permetterà di inoltrare la richiesta di creazione dei gruppi con le informazioni necessarie.

X Bergoglio:

1) non so se ho capito bene, sicuramente il software pacchettizzato per openmamba deve avere una licenza OSI compatibile che prevede che le patch non possono essere rilasciate con licenza diversa. Se invece ti riferisci al copyright del software sviluppato da zero per openmamba, questo è detenuto dai singoli sviluppatori che saranno co-detentori del copyright

2) fin dall’inizio l’approccio è stato di scegliere il software migliore disponibile in ogni campo invece che pachettizzare il mondo. La scelta di usabilità del sistema base con il suo corredo di software non è in conflitto con il fatto che l’utente abbia a disposizione 10000 pacchetti software alternativi, quindi ben venga che ci sia più software disponibile, se c’è un gruppo che se ne vuole occupare e ritiene che questo sia necessario.

[Autore]

Articoli