Iscrizione al raduno e inserimento delle sessioni a scelta attraverso il sito

[dagoneye]

E' necessario aggiornare il modulo delle sessioni a scelta e che ci serve per vedere quanti iscritti ci sono nel raduno 2017. Ecco le azioni classiche che si possono fare attraverso il sito:

• confermare l'iscrizione al raduno attraverso il proprio profilo utente:
  • andare su www.spaghettiopendata.org/user/;
  • cliccare su "Il mio profilo", in alto a destra;
  • cliccare l'etichetta SOD15 nel menù verticale a sinistra;
  • selezionare SI o NO alla voce "Partecipo al raduno 2017"
• aggiungere uno speech tra le sessioni parallele che saranno presenti nel programma - http://www.spaghettiopendata.org/node/add/session;
• visualizzare correttamente gli iscritti al raduno in ogni momento su http://www.spaghettiopendata.org/community e sulla mappa http://www.spaghettiopendata.org/community/map

Ne avevo parlato per SOD16 qui, per avere un'idea: https://groups.google.com/d/msg/spaghettiopendata/u0edVwyFn18/BIhF0ClaBQAJ

@paolomainardi sta verificando le possibilità.

[albertocottica]

Siamo sicuri di volere usare il sito e non GitHub, come proposto da @aborruso ? C'è un vantaggio a usare GitHub: si incoraggiano non-sviluppatori a fare l'account. L'account GitHub è parte di una rampa di accesso al mondo dei dati, e a una migliore interoperabilità tra sviluppatori e non. Io l'ho fatto con TweetYourMEP, e mi ricordo che ne ero orgogliosissimo. Adesso mi aiuta a interagire con gli sviluppatori da cui compro roba, e lo uso anche per scrivere paper scientifici (dati + codice + testo del paper, tutto sulla stessa repo).

[dagoneye]

My 2 cent: occhio che dovrebbero esserci le stesse funzioni che ora abbiamo con il sito. Ergo: ci serve per contare i partecipanti, sia per tutto l'evento che per le singole sessioni (funzionale per la logistica e la scelta delle salette). Ho dei dubbi che solo usando Github si possa fare :) Ma se hai già trovato dei modi veloci per farlo, parliamone. Anzi, è meno lavoro di backend da gestire.

Altro tema: ho paura per l'inclusione dei non tecnici. Siamo sicuri di farlo? Forse gli unici davvero a saperlo sono gli amici di Terremotocentroitalia... Su questo non ho provato abbastanza con un pubblico più eterogeneo per prendere delle decisioni sensate.

[albertocottica]

@dagoneye come sappiamo, un wiki ben mantenuto fa tutto quello che vuoi. Ti ricordi quando facevamo i Barcamp su pbwiki? Per contarci si faceva così: ognuno aggiungeva il proprio nome alla lista, e questo era. Figurati GitHub. Naturalmente, quella comunità aveva accettato di fare così. C'erano anche meno problemi di spam.

Probabilmente la variabile fondamentale qui è quanto lavoro serve a Paolo per ritirare su il sito, e – fondamentale – quando lo può fare. Se il sito è pronto o quasi andiamo con il sito.

[dagoneye]

un wiki ben mantenuto fa tutto quello che vuoi. Ti ricordi quando facevamo i Barcamp su pbwiki? Per contarci si faceva così: ognuno aggiungeva il proprio nome alla lista, e questo era.

Certo che ricordo (bei tempi quelli): si potrebbe provare, così almeno chi fa danni è anche più tracciabile tutto sommato.
Sul quanto lavoro, sto verificando proprio con Paolo se è troppo: vediamo dai.

[albertocottica]

Se decidiamo di usare GitHub, propongo una riflessione (da 20 minuti, eh) su come impostare l'architettura della faccenda.

A occhio vedo un piccolo vantaggio: corrispondenza "built in" tra info sulla sessione e materiali. Per esempio, se io ripropongo una traccia hackathon su analisi di rete con dati CORDIS, potrebbe funzionare così: apro una repo sotto SOD, con solo un README pro forma. Poi vado sul wiki e descrivo la sessione. Poi vado sulla repo del raduno e copincollo titolo della sessione e link alla "mia" repo (dove? potrebbe essere sul wiki, oppure tentiamo di fare un minisito con github.io). Le persone si iscrivono chiedendo di essere aggiunte alla repo della sessione. Quando poi siamo sotto raduno, Stefano Durì e io ripuliamo i dati e cominciamo a committare roba sulla repo. A Caltanissetta abbiamo già una repo mezza fatta, e committiamo la roba man mano che la facciamo.

Torna?

[seralf]

github.io è una ottima idea: basta saper usare markdown e un po' di jekyll. Forse ci starebbe bene una sesssione apposita nella giornata di formazione, ora che ci penso: sono strumenti in fondo molto utilizzati Il giorno 12 marzo 2017 22:05, Alberto Cottica <notifications@github.com> ha scritto:

…

Se decidiamo di usare GitHub, propongo una riflessione (da 20 minuti, eh) su come impostare l'architettura della faccenda. A occhio vedo un piccolo vantaggio: corrispondenza "built in" tra info sulla sessione e materiali. Per esempio, se io ripropongo una traccia hackathon su analisi di rete con dati CORDIS, potrebbe funzionare così: apro una repo sotto SOD, con solo un README pro forma. Poi vado sul wiki e descrivo la sessione. Poi vado sulla repo del raduno e copincollo titolo della sessione e link alla "mia" repo (dove? potrebbe essere sul wiki, oppure tentiamo di fare un minisito con github.io). Le persone si iscrivono chiedendo di essere aggiunte alla repo della sessione. Quando poi siamo sotto raduno, Stefano Durì e io ripuliamo i dati e cominciamo a committare roba sulla repo. A Caltanissetta abbiamo già una repo mezza fatta, e committiamo la roba man mano che la facciamo. Torna? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFYfOHPOhWpOUcXS7r5F5YggUwUYDifks5rlF4EgaJpZM4MagUA> .

[aborruso]

@seralf ho buttato una nota qui, è un'ottima idea.

Ho aggiunto i microservice

[dagoneye]

@albertocottica potrebbe tornare: sto pensando alla mia track sull'amianto dell'anno scorso e tutto sommato semplificherebbe molto.
Unico vincolo: tutti i partecipanti al raduno dovranno avere un profilo Github. E questo potrebbe essere un side-effect utile. Bisogna documentare per bene il tutto però.

Possiamo tenere il sito come finestra informativa di base rispetto a quello che nasce sui repo e sul wiki, tutto sommato.

COME ISCRIVERSI AL RADUNO
Chiedere l'inserimento nel repo del raduno.
Il wiki del repo del raduno diventa il programma che si crea man mano.
Le sessioni a scelta sono l'unico elemento dove l'attenzione deve essere alta: ma usando le tabelle in markdown non dovrebbe essere difficile gestirsi.

COME ISCRIVERSI ALLE SESSIONI
Ogni sessione avrà un repo, ergo il conteggio sarà l'adesione al repo.

Conseguenze: plenaria, potremmo usare il wiki per ripubblicare slide e materiale agevolmente e tutti assieme, più che dipendendo solo dal sito.

COME GESTIRE LE SESSIONI
Creare un nuovo repo all'interno di SOD su quella sessione con un README basico.
Sfruttare il Wiki del repo della sessione per descriverla e aggregare i materiali utili.

Ha senso, no? Io direi di provarci a questo punto, più ci penso e più potrebbe funzionare.

[seralf]

+1 per me: se mi spiegate cosa bisogna documentare, a tempo perso provo a dare una mano Il giorno 13 marzo 2017 20:51, Matteo Brunati <notifications@github.com> ha scritto:

…

@albertocottica <https://github.com/albertocottica> potrebbe tornare: sto pensando alla mia track sull'amianto dell'anno scorso e tutto sommato semplificherebbe molto. Unico vincolo: tutti i partecipanti al raduno dovranno avere un profilo Github. E questo potrebbe essere un side-effect utile. Bisogna documentare per bene il tutto però. Possiamo tenere il sito come finestra informativa di base rispetto a quello che nasce sui repo e sul wiki, tutto sommato. COME ISCRIVERSI AL RADUNO Chiedere l'inserimento nel repo del raduno. Il wiki del repo del raduno diventa il programma che si crea man mano. Le sessioni a scelta sono l'unico elemento dove l'attenzione deve essere alta: ma usando le tabelle in markdown non dovrebbe essere difficile gestirsi. COME ISCRIVERSI ALLE SESSIONI Ogni sessione avrà un repo, ergo il conteggio sarà l'adesione al repo. Conseguenze: plenaria, potremmo usare il wiki per ripubblicare slide e materiale agevolmente e tutti assieme, più che dipendendo solo dal sito. COME GESTIRE LE SESSIONI Creare un nuovo repo all'interno di SOD su quella sessione con un README basico. Sfruttare il Wiki del repo della sessione per descriverla e aggregare i materiali utili. Ha senso, no? Io direi di provarci a questo punto, più ci penso e più potrebbe funzionare. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFYfJJ--p-xrPS2eHogfFTn98Eb7Zcoks5rlZ47gaJpZM4MagUA> .

[albertocottica]

+1 per @seralf . @dagoneye secondo me ha senso, e come. Dobbiamo farlo da comunità inclusiva, quindi niente RTFM. Per esempio, potremmo offrirci volontari a turno, una volta alla settimana, per fare una chat o un Google Hangout con chi vuole una mano per fare la registrazione GitHub e le varie iscrizioni, creazioni di repo per chi vuole proporre una sessione etc. etc.

[paolomainardi]

Io nel frattempo sto aggiornando il sito, eventualmente è già pronto qualsiasi altra strada si scelga :)

[paolomainardi]

ho aggiornato @dagoneye su slack, la piattaforma è pronta ed aggiornate per il nuovo evento.

[dagoneye]

Chiudo la issue: abbiamo deciso di usare direttamente il sito di SOD, ora perfettamente funzionante. Esiste una guida generale sul come funziona nel wiki del repo.