Nell’incontro di ieri è nata l’idea di investire sul futuro del prodotto, per quanto riguarda la community, non tanto in termini di una nuova feature specifica di Foundation e Cloud (cosa comunque importanissima), quanto nel creare un set di componenti realizzati dalla community.
A mio avviso questo aumenta di molto il valore aggiunto dei prodotti.
Mi permetto di proporre che bisogna decidere cosa fare e come fare, non voglio scrivere un papiro, ma solo rompere il ghiaccio quindi vado sintetico.
COSA FARE:
componenti di backend interessanti
componenti widget UI (ad esempio un completo set di wrapper di devextreme)
COME FARE:
Progamma (?) mette a disposizione un teamworks (magari accessibile anche a chi non ha la licenza teamworks??? Così nessuno è tagliato fuori) dove si gestiscono i componenti "community open source ".
in qualche modo si gestisce lo sviluppo (teamworks non ha pull request o le feature git-like che servono per gestire un progetto open source, ma si può trovare una soluzione con gli strumenti che già ci sono)
Sarebbe poi bello che ci fossero dei componenti “iniziali” su cui iniziare a lavorare, noi ad esempio possiamo proporre questi (li dobbiamo prima “componentizzare per bene”):
componente goCardless (per gestire i pagamenti sul provider di Sepa Direct Debit GoCardless). Noi lo usiamo già come componente per quanto riguarda le api, però la logica dei pagamenti è in una applicazione. Per renderlo davvero utile andrebbero aggiunti nell’inerfaccia del componente alcuni metodi. Ci sarebbe quindi del lavoro da fare da parte nostra prima di mettere il componente a disposizione, oppure potremmo anche mettterlo com’è e poi assieme migliorarlo.
wrapper del widget orgchart di balkanChart che usiamo in una app. Al momento questo non è componente e andrebbe componentizzato. Il componente non è open source e va acquistato, c’è un “call home” che limita gli IP da cui può essere usato (quindi nella custom uno dovrebbe mettere il codice del proprio componente), ma è un orgchart molto bello ed il migliore che abbiamo trovato dopo una lunga ricerca (e che non costasse cifre esagerate).
Ho fatto un esempio di un componente di backend e uno di frontend, ma ce ne poterbbero essere altri, io non ho esperienza di gestione di progetti open source, in ogni caso credo che per ogni tipo di componente (back o front) ci vogliano delle “Linee guide community”, nonché un team che gestisca i progetti dei componenti.
Solo un breve messaggio per rompere il ghiaccio, poi magari @paolo.giannelli ci dici come pensi di proseguire.
Buone notizie!
Stiamo approntando gli spazi per gestire il lavoro di gruppo per Foundation e Cloud in modo da poter sviluppare componenti open source per i due prodotti.
Foundation
Mettiamo a disposizione un Team Work su di un nostro server.
Chi vuole partecipare risponde a questo post e indica Nome, Cognome ed email e gli creiamo l’account.
Cloud
Utilizziamo il server ide di Community (che quindi è già disponibile).
Il procedimento potrebbe essere questo:
Creo un progetto nella parte Community di Console (per intenderci quella dell’organizzazione Instant Developer).
Lo condivido con tutti gli utenti di Instant Developer (lo vedono nei progetti pubblici cercandolo per nome).
Chi vuole collaborare si fa un fork del progetto sempre nella parte Community.
Dal fork può fare commit e PR verso il progetto master.
il proprietario del progetto accetta la PR.
Chiunque può realizzare un componente e condividerlo con tutti
Anche qui dobbiamo sapere chi sono quelli che collaborano per metterli nel gruppo giusto.
Rimane il problema del limite delle 20 videate nei progetti di Community ma lo risolviamo lato Console utilizzando un gruppo che non ha questo limite o semplicemente impostandolo sul progetto.
Nell’attesa di avere il teamworks per i componenti foundation io “dichiaro” il primo componente che pubblicherò.
Si tratta di un componente su cui sto lavorando, è un componente che serve alle applicazioni ionic pensate solo come “mobile first app”, ovvero senza shell, lo scopo è mettere a disposizione le funzioni di cui si occupa la shell anche in una app senza shell, per ora ho fatto l’upload di file, ma a regime vorrei avere anche lo scanbarcode e il geolocate.
Una voce di corridoio che ho sentito in assistenza diceva che l’interesse per questo tipo di applicazioni è alto e quindi penso che questo componente sarebbe utile a molti.
Anni fa avevo iniziato un progetto InDeCloud per creare un componente che potesse gestire il pattern MVU (come ad esempio flutter e react).
Mi sono dovuto fermare per mancanza di tempo, ero arrivato a gestire la creazione della videata
a partire dall’albero iniziale, la creazione del nuovo albero e avevo importato un componente per eseguire il diff tra i due alberi.
A quel punto è necessario guardare le diff e modificare l’albero corrente per diventare come quello di destinazione.
Avevo iniziato a implementare questa parte ma mi ero fermato all’inizio.
Se qualcuno è interessato il progetto è pubblico e si chiama “mvu-project”.
Ammetto che non si tratta di un componentino ma di un nuovo sistema di rendering e creazione delle videate, quindi è un lavoro un pò impegnativo .
Vorrei porre l’attenzione su un dettaglio importante, non scrivete qui le email (anzi, non scrivetele MAI in chiaro nei forum) ma comunicatele direttamente a @paolo.giannelli perché se riesce a passare qualche crawler poi vi trovate le email indicizzate sui motori di ricerca e buono spam!
@d.termini grazie del consiglio, hai perfettamente ragione.
Modifico i post e le nascondo.
Scrivete qui che volete collaborare e poi mandatemi un messaggio in privato con la mail che volete utilizzare.
Ciao. Chiedo scusa ma sono ancora in ritardo e non ho ancora pubblicato un componente. Ne ho uno pronto (anche se non proprio “concluso”), lo potrei anche caricare, però mi chiedo: come viene gestito? Io so cosa andrebbe fatto, come funziona la gestione del progetto.
L’idea che avrei è che se metto i nostri componenti nella community vorrei poter continuare a usarli dalla community e non avere “anche la mia copia nel mio teamworks”. Cioè non vorrei che il primo che passa faccia una modifica, ma che in un certo senso ci fosse una gestione del progetto, altrimenti devo per forza avere il mio componente e quello community. Però se non ci si può fidare del componente community il tutto perde valore
Io ho due componenti che vorrei sottoporre:
un componente per fare nelle app mobile ionic le cose che al momento si fanno solo con la shell (upload file, scan barcode, geolocate). Al momento ho fatto solo l’upload (mi manca di finire il bottone di upload che ha un css impreciso e vorrei che usasse in qualche modo il css di ionic per mostrarsi sempre bene).
il componente per convertire i file da un formato all’altro che usa OnlyOffice API
Prima di continuare e quindi riservarmi del tempo, mi piacerebbe capire come funzionerebbe la gestione dei progetti.
Io alla fine ho caricato il mio primo progetto, mi sono messso a pulirlo e ho anche sistemato il problema del css con un trucco.
Potrei fare un video o scrivere un’istruzione, come si deve fare in questi casi?
Per ora tengo il mio progetto vero sul mio teamworks e quello di community è una copia ma mi piacerebbe poter usare solo uno come dicevo prima. Chiaramente ci sono molti dettagli da considerare però tra 0 e 100 ci sono molti numeri…
Di solito nelle community chi ha creato un contenuto resta anche come manutentore, a meno che non voglia trasferirne la proprietà, ma dubito si possa trasferirla alla community stessa.
Il ruolo del manutentore, in accordo con la community, è quello di valutare se le modifiche proposte sono integrabili oppure da rifiutare.
Lasciare un progetto aperto a tutti poi diventa come wikipedia quando ci sono le edit wars.
Per il Team Works di Foundation purtroppo non abbiamo a disposizione le funzionalità che servirebbero a @f.faleschini e in particolare:
I check-in quando fatti non si possono rifiutare (non esiste il concetto di modifica da accettare, come le pull request di Cloud) e quindi non si possono eliminare.
I permessi sono per utente e non per progetto; se un utente e del gruppo Community li può vedere e modificare.
Inizialmente saremo pochi a collaborare a questi progetti e direi che il buon senso e magari due regole scritte possono risolvere il problema.
Nulla vieta che possa nascere proprio da questo gruppo la voglia di modificare l’applicazione TWWebClient per renderla compatibile a questo modo di lavorare in comune.
.