ARGOMENTO: Proposta Condivisione Conoscenza

Dallo sprint - per me esperienza bellissima - è emerso anche che un problema di questa comunità puo' essere quello della comunicazione .

Tralasciando le questioni di merito sui contenuti , faccio un po' delle considerazioni :

- Per fare crescere il prodotto è necessario piano piano aggiungere nuovi pezzi.
- Tali pezzi devono poi essere amalgamati tra di loro.
- Le nuove funzionalità possono essere prese da moduli gia' esistenti, magari migliorandone le funzionalità.

Per fare cio' pero:
- I due giorni sono serviti per discutere su cosa dovrebbe fare il software. Ovviamente non si sono potuti affrontare molti argomenti ma quelli che sono stati affrontati in maniera direi quasi completa.

Ora pero' bisogna quagliare e lasciare traccia del tempo speso ...e vengo al dunque:

1) per lo sviluppo siamo costretti a usare launchpad : tutti i progetti openerp "compliant" sono mappati su launchpad , per cui non se ne esce. Tutti i moduli vanno caricati li'
OPENERPITALIA SI TROVA QUI: https://launchpad.net/openobject-italia

Una guida generica la potete trovare qui:http://wiki.openerp-italia.org/doku.php/area_tecnica/launchpad/start

2) Escludendo la parte delle traduzioni (su cui ritorneremo) è formato sostanzialmente di 3 sezioni:
- Bug tracking
- BluePrints
- Answers

La prima voce serve per tracciare i problemi tecnici , e in questa sede non ce ne occuperemo .

le blueprints

Nelle blueprints invece si possono ritrovare le funzionalità che mancano e che devono essere sviluppate .
I campi importanti nella schermata sono :
Name: Nome breve della blueprint

Title: titolo della blueprint


Specification URL: QUESTO CAMPO PER NOI E' FONDAMENTALE : bisogna riportare il link della specifica completa della funzionalità richiesta e sara' il punto di scontro per la discussione



Summary:
breve descrizione della richiesta


Status Whiteboard: (Optional)
Note sullo stato attuale , visibili in home page (mi pare)


Come vedete gli strumenti ci sono tutti , la bluprints puo' essere assegnata a un tecnico e proposta addirittura per uno sprint. o , ancora, la si puo' mettere sotto l'attenzione di qualcun altro (feedback) , o collegarla a uno o piu' bug.

La blueprint puo' essere gerarchica: e' possibile che il rilascio di una funzionalità dipenda da una altra.

Passiamo alle answers.

Sezione del sito che serve per le domande e le relative risposte. Non ho molto approfondito l'argomento . Sara' mia cura approfondire.


Detto questo dovremmo intenderci su come stendere le specifiche e su dove metterle sul wiki , che al momento e' l'unico strumento che abbiamo per questa attivita' .

L'idea mia e' di creare un template (in parte in questa specifica c'e' gia' : http://wiki.openerp-italia.org/doku.php/moduli/l10n_it_fiscal_year_closing)

Ma rimane comunque il problema di come strutturare i contenuti.

Anche in ottica di rivisitazione sito io avevo pensato di creare tanti piccoli minisiti (o workspace) che trattassero di specifiche tematiche : tipo contabilita' , magazzino , produzione ecc eccc. ... dove gli utenti interessati potrebbero andare e contribuire. L'approccio dovrebbe essere piu' comunitaro' in stile social network , che adesso fa pure figo.


l'ultimo punto che vorrei discutere con voi e' la tracciabilità sulle funzionalita' che gli altri moduli hanno e che ci potrebbero servire.

Faccio notare poi che dovremmo arrivare a un punto di consolidamento dei modulini nostri su launchpad per permettere anche all'utente di poterseli installare.... ma su questo forse basta una guida ...


ciao , e' mezzanotte e vado a dormire

Umibozu mi commuovi!

Sono perfettamente d'accordo con te e mi allineerò bene presto, inoltre aggiungo che ci vorrebbero delle impostazioni sullo sviluppo, cioè ne perlavo con Elbati, magari inserire nella descrizione anche un brief delle funzionalità e magari allegare un file txt con una breve documentazione.
Poi impostare la forma dei moduli come ad esempio:

l10n_it_{modulo principale}_{funzionalità extra}

in questo modo tutto quello che riguarda ad esempio gli obblighi e le funzionalità necessarie per la contabilità andrebbero nel modulo:

l10n_it_account

Se ci fossero delle funzionalità extra per esempio sulla gestione del reverse_charge farei un modulo a parte come:

l10n_it_account_reversecharge

Questo lo renderebbe anche + manutenibile, inoltre durante lo sviluppo se dobbiamo scrivere una funzionalità exnovo, lascerei una impostazione standare per creare degli hook in modo tale da poter iniettare estensioni o check o quello che si vuole.

My 2 cents

Franco

Che poeta, Barbra Streisand sarebbe orgogliosa di lui!

Io ho una marea di informazioni da riversare su wiki e blueprints, questa notte purtroppo i miei limiti biologici non mi hanno permesso di lavorare.

Oggi so già che non ce la farò. Facciamo che mi prendo a questo punto il fine settimana per elaborare tutti gli appunti e srotolarli sui nuovi strumenti

Ciao!
Concordo su quanto scritto qui ... mi permetto di aggiungere che, soprattutto per i neofiti (come me), sarebbe molto utile uno schema del tipo (elenco non esaustivo) :

1. Strumenti per comunicare (indicando per quali motivi usare uno o l'altro):
a. Chat
b. Forum
c. Mailing List

2. Strumenti per condividere :
a. Wiki (magari con template da usare o pagine di esempio come l'ottima di Umibozu e strumenti a supporto)
b. Launchpad : Bug tracking, BluePrints, Answers (con descrizione d'utilizzo)

3. Strumenti per sviluppo :
a. Bazaar
b. Launchpad : Code , Translations
c. Editor Python (Nano, Vim, Eclipse, ...)
d. Linee guida per sviluppo moduli (come riportato da Dr.Dran)

Questa lista ovviamente andrebbe sul wiki così è arricchibile da chiunque ...
Buon pranzo!

Mi aggiungo al coro di "I agree", concordo con FabriZ che effettivamente sia utile una traccia degli strumenti più o meno utili, che magari ad oggi già utilizzo, ma che però sono stati frutto di una ricerca a "spizzichi e bocconi"; sui forum si trova sicuramente di tutto, spesso però non si sa dell'esistenza e quindi non si cerca neppure...

umibozu ha scritto:Se parli di funzionalità già presenti in OpenERP, non duplicherei la documentazione già presente in doc.openerp.com/v6.0/ (che verrà tradotta).
Se parli di funzionalità italiane, le specifiche di ogni singolo modulo dovrebbero già affrontare le questioni calde.
D'altronde poi le specifiche dovranno diventare la documentazione del modulo.

Dico questo solo perchè non vorrei rischiare di buttare troppa roba al fuoco, quando magari alla fine in pochi avranno il tempo di mettersi a scrivere tanti discorsi.
Mentre invece, se vogliamo sviluppare i moduli che ci servono, le specifiche devono essere scritte.
Direi che se uno trova qualcosa di utile in un modulo esistente, lo può scrivere nelle specifiche (come hai fatto te, da bravo )
Vi invito quindi a tenere sempre sott'occhio apps.openerp.com
In realtà (come ho scritto poco fa qui wiki.openerp-italia.org/doku.php/moduli/start ) i nostri moduli sono già su apps (vengono prelevati da launchpad ogni qualche giorno: apps.openerp.com/?text_search=italian ) e scaricabili come zip, quindi installabili da chiunque

P.S.: per il resto ovviamente sottoscrivo tutto