Strutture Dati: Aree di Competenza Tecnica e Commissioni

[ralzakark]

Per le strutture dati per le aree di competenza tecnica e le commissioni pensavo ad una cosa simile:

Competenze Tecniche

TABLE skill
* id
* name

skill: In questa tabella vengono registrate le aree di competenza prefissate.

TABLE member_skill
* member_id
* skill_id

member_skill: Associazione Utente <-> Aree di Competenza Tecnica, usata per la selezione randomica dei membri delle commissioni.

TABLE requested_skill
* issue_id
* initiative_id
* member_id
* skill_id
* ...
* winner

requested_skill: In questa tabella vengono salvate le competenze tecniche che gli utenti ritengono necessarie per la commissione.In fase di creazione della questione/proposta la tabella viene popolata con la sola scelta del creatore della questione.In seguito altri utenti potranno richiedere differenti competenze per le varie proposte alla questione. Una constraint dovrebbe impedire che ci siano più di quattro row per la tripla (issue_id, initiative_id, member_id)

Commissioni

In base alle richieste di competenza tecnica associate alla proposta vincente viene istituita una commissione tecnica:

TABLE committee
* id
* issue_id
* initiative_id
* created
* started
* ...
* frozen
* closed

commitee: Questa tabella registra la storia di vita di una commissione tecnica

TABLE committee_skill
* commitee_id
* skill_id

committee_skill: Associazione Commissione <-> Aree di competenza tecnica

TABLE committee_member
* commitee_id
* member_id

committee_member: Associazione Commissione <-> Utenti. I membri della commissione vengono scelti automaticamente in base alle loro competenze (tabella member_skill) secondo quanto richiesto dai votanti (tabella requested_skill).

Attendo feedback :)

[EmanueleSabetta]

In linea teorica andrebbe bene, anche se devo studiare la cosa appena ho tempo perché c'è il problema della distinzione tra commissioni permanenti (economica e legale) e commissioni temporanee (quele tecniche, che durano un mese). In teoria potremmo trattarle allo stesso modo a livello di codice, non se ne accorgerebbe nessuno, la sola differenza sarebbe che la mailing list di quelle permanenti sarebbe di così pochi nomi che verrebbero di conseguenza invitati sempre gli stessi. Un altro punto importante è capire se serve un secondo livello per le keyword. In altre parole se conviene fare una lista sola in cui buttare tutto, dal generico "chimica" al più specialistico "fitosanitari", oppure fare due livelli di keyword, con le specialistiche che equivalgono associativamente a 3-4 generiche. In questo modo uno specialista in fitosanitari è automaticamente considerato un candidato per una commissione dove si richiede un chimico, e viceversa una commissione convocata con la tag "fitosanitari" in mancanza di esperti specifici chiama i generici associati, ovvero "chimica", "agricoltura", "farmacologia", "igiene", "biologia", etc. Mi ci vuole un pò di tempo per studiare la questione, appena finisco di fare le cose su cui sto lavorando mi ci metto.

[ariannaf]

Se il parlamento è il luogo di proposta e deliberazione, perchè le commissioni devono essere integrate? Non avevamo deciso all'inizio che le commissioni erano in una mailing list esterna, proprio per non appesantire il progetto?

[ralzakark]

@Movimento5StelleDevelopment si potrebbe mettere tutto nella stessa lista ma trattare le specialistiche come sub skill... mi spiego meglio:

1. Intanto mi pare poco educato presentare all'utente una form select con centinaia di entry. Ci vuole come minimo una doppia select dove l'utente prima seleziona la generica e da quella il sistema ne deriva le specialistiche associate :)
2. L'utente dovrebbe comunque avere la possibilità di scegliere un'area di competenza generica selezionando nella seconda form select l'option "Generico" o qlcs di simile.
3. Alcune aree specialistiche apparirebbero quindi sotto più generiche. (es Se scelgo "chimica", "agricoltura", "farmacologia", "igiene", "biologia" nella prima form select mi ritrovo sempre "fitosanitari" nelle options della seconda form select).
4. Si potrebbe creare una struttura addizionale fatta così:

TABLE skill_spec
* skill_id
* sub_skill_id

skill_spec: Associazione Aree di Competenza Generiche <-> Aree di Comptenza Specialistica

1. L'inserimento delle aree di competenza per una issue/initiative avverrebbe normalmente, l'utente può inserire un massimo di 4 competenze, indipendentemente che siano generiche o specialistiche.
2. In fase di commissione, se il sistema non trova uno specialista va in fallback su le aree di competenza generica associate alla skill via join con la tabella skill_spec.
3. Analogamente, se per una issue è stato selezionata una skill generica il sistema cerca gli utenti per la commissione in base alle loro specializzazioni incrociando con la tabella di cui sopra. La selezione automatica potrebbe partire ad esempio da coloro che hanno il maggior numero di specializzazioni associate alla generica richiesta nella issue.
4. In nessun caso un utente può avere come skill uno skill generico.. (si potrebbe inserire una constraint sull'INSERT nella tabella member_skill che controlla che l'id dello skill inserito non sia presente come "skill_id" nella tabella skill_spec, cioè deve essere una specializzazione e non uno skill generico)

[EmanueleSabetta]

@ariannaf scrive:

Se il parlamento è il luogo di proposta e deliberazione, perché le commissioni devono essere integrate?

Le commissioni nella loro totalità non sono integrate infatti. Solo la fase finale, ovvero le votazioni dei membri sul rapporto tecnico e dei vari emendamenti al rapporto tecnico, si svolgono sul parlamento elettronico in un'area apposita. In realtà la discussione tra i membri della commissione avviene fuori dal parlamento elettronico, dovunque decidano di farla ed è più comodo ai membri della commissione (può essere una mailing list, come può essere un forum di un meetup o un hangout google, sono liberi di organizzarsi in modo decentralizzato...).

Non avevamo deciso all'inizio che le commissioni erano in una mailing list esterna, proprio per non appesantire il progetto?

Infatti quello che avevamo deciso viene rispettato. La mailing list è addirittura ancora più semplice, non una vera mailing list. E' da intendere letteralmente come "email address list", ovvero la lista degli indirizzi email dei membri della commissione iscritti come potenziali membri convocabili nella loro area di competenza. Il processo è semplice: i membri vengono convocati e invitati nell'area riservata a loro (ma leggibile a tutti). Qui propongono il testo della relazione, lo emendano, lo modificano, ne pubblicano revisioni, etc. finché sono tutti d'accordo e raggiungono un voto definitivo a maggioranza. Ma la discussione non avviene qui, come ho detto avviene fuori. E non possiamo essere noi a definire un luogo, perché è pericolosissimo fissare ad esempio una mailing list noi, diverrebbe immediatamente target di sabotatori che modificherebbero le email intercettandole e inserendo dati falsi per pilotare l'esito. I commissari si devono inventare da soli un modo per comunicare. Gli vengono visualizzate le email degli altri membri della commissione quando entrano nell'area privata, quindi possono organizzarsi e usarle per comunicare in modo indipendente tra loro e accordarsi su un luogo di discussione.

In generale il costo per il parlamento elettronico è solo quello di aprire un area temporanea, invitarci i 12 commissari mandandogli una email, approvare con il solito iter una proposta (che stavolta è il testo del rapporto) e poi chiudere l'area. Non c'è bisogno di creare un forum di discussione o altro, si usano gli strumenti stessi di liquid.

[EmanueleSabetta]

@ralzakark scrive:

Intanto mi pare poco educato presentare all'utente una form select con centinaia di entry. Ci vuole come minimo una doppia select dove l'utente prima seleziona la generica e da quella il sistema ne deriva le specialistiche associate :)

La tua osservazione è corretta. Infatti a livello di UI di solito per cose di questo tipo si dovrebbe usare una TreeView con i nodi. Neanche il sistema del senato lo usa: http://www.senato.it/3869

Ma in compenso il problema l'hanno risolto con una cosa che si chiama "sistema TESEO":

http://www.senato.it/3235?testo_generico=745

http://goo.gl/jbCtU

In europa invece ne hanno creato un altro ancora, che si chiama EUROVOC:

http://eur-lex.europa.eu/SuiteLegislation.do?T1=V100&T2=V1&T3=V5&RechType=RECH_legislation&Submit=Cercare

http://eurovoc.europa.eu/drupal/?q=it/navigation&cl=it

L'utente dovrebbe comunque avere la possibilità di scegliere un'area di competenza generica selezionando nella seconda form select l'option "Generico" o qlcs di simile.

Il problema è che potrebbe diventare un trucco per essere pescato più spesso dall'algoritmo, quindi diventerebbe una strategia dominante e la userebbero tutti skippando sempre il secondo form. Se io metto "Chimica" e "Fitofarmaci" sicuramente vengo selezionato in meno casi per far parte di una commissione rispetto a chi mette "Chimica" e "Generico". E' questo uno dei punti su cui devo riflettere.

Nel frattempo considera ad esempio queste aree di specializzazione, visto che sono inserite come scelte obbligate da tutti i candidati nel form del M5S Lazio : http://www.lazio5stelle.it/index.php/commissioni-parallele/

Affari costituzionali e statutari Affari istituzionali Enti locali e risorse umane Federalismo fiscale Sicurezza Integrazione sociale Lotta alla criminalità Affari comunitari e internazionali Cooperazione tra i popoli Tutela dei consumatori Vigilanza sul pluralismo dell'informazione Bilancio Partecipazione Demanio e patrimonio Programmazione economico-finanziaria Cultura Diritto allo studio Istruzione Pari opportunità Politiche giovanili Spettacolo Sport Turismo Ambiente Lavori pubblici Mobilità Politiche della casa Urbanistica Politiche sociali e salute Agricoltura Artigianato Commercio Formazione professionale Innovazione Lavoro Piccola e media impresa Ricerca e sviluppo economico

Alcune sono molto specifiche, altre così generiche che comprenderebbero praticamente tutto... Ad esempio qui sarebbe utile incasellarle in un genere, tipo: "Innovazione" diventerebbe "Innovazione (Economia)", "Innovazione (Architettura)", "Innovazione (Sport)", "Innovazione (Agricoltura)", etc. Ma comunque risulta difficile stabilire un criterio per alcune. Ad esempio che differenza c'è tra "Innovazione" e "Ricerca e sviluppo economico"? O tra "Artigianato" e "Piccola e media impresa"? E che tipo di categoria di competenze generiche ha un esperto di "Vigilanza sul pluralismo dell'informazione"? E' un laureato in giurisprudenza o in scienze della comunicazione? In economia o in sociologia? Insomma è abbastanza complicata la faccenda, e richiede uno studio approfondito.

[bhack]

Ho trovato questo link interessante anche sulla prospettiva semantica/linked data (notare anche gli aggiornamenti successivi a fine post) http://legalinformatics.wordpress.com/2009/08/19/linked-data-and-law/

Date un'occhiata anche qui sul menu a destra "dati e ontologia" (in più c'è attivo anche un endpoint SPARQL):

http://dati.senato.it/19?testo_generico=22

[ariannaf]

Sono d'accordo su tutto, tra l'altro anche la certificazione andrebbe estesa alla ml se interna al progetto e creerebbe falle in sicurezza grazie! Il giorno 21/lug/2013 20.23, "Movimento5StelleDevelopment" < notifications@github.com> ha scritto:

@ariannaf https://github.com/ariannaf scrive:

Se il parlamento è il luogo di proposta e deliberazione, perché le commissioni devono essere integrate?

Le commissioni nella loro totalità non sono integrate infatti. Solo la fase finale, ovvero le votazioni dei membri sul rapporto tecnico e dei vari emendamenti al rapporto tecnico, si svolgono sul parlamento elettronico in un'area apposita. In realtà la discussione dei membri della commissione avviene fuori dal parlamento elettronico, dove è più comodo alla commissione (può essere una mailing list, come può essere un forum di un meetup o un hangout google, sono liberi di organizzarsi in modo decentralizzato...).

Non avevamo deciso all'inizio che le commissioni erano in una mailing list esterna, proprio per non appesantire il progetto?

La mailing list è la lista delle email dei membri della commissione iscritti come potenziali membri convocabili nella loro area di competenza. Il processo è semplice: i membri vengono convocati e invitati nell'area riservata a loro (ma leggibile a tutti). Qui propongono il testo della relazione, lo emendano, lo modificano, ne pubblicano revisioni, etc. finché sono tutti d'accordo e raggiungono un voto definitivo a maggioranza. Ma la discussione non avviene qui, come ho detto avviene fuori. E non possiamo essere noi a definire un luogo, perché è pericolosissimo fissare ad esempio una mailing list noi, diverrebbe immediatamente target di sabotatori che modificherebbero le email intercettandole e inserendo dati falsi per pilotare l'esito. I commissari si devono inventare da soli un modo per comunicare. Gli vengono visualizzate le email degli altri membri della commissione quando entrano nell'area privata, quindi possono organizzarsi e usarle per comunicare in modo indipendente tra loro e accordarsi su un luogo di discussione.

In generale il costo per il parlamento elettronico è solo quello di aprire un area temporanea, invitarci i 12 commissari mandandogli una email, approvare con il solito iter una proposta (che stavolta è il testo del rapporto) e poi chiudere l'area. Non c'è bisogno di creare un forum di discussione o altro, si usano gli strumenti stessi di liquid.

— Reply to this email directly or view it on GitHubhttps://github.com/Movimento5StelleLazio/ParlamentoElettronicoM5S/issues/247#issuecomment-21314384 .