VOA - Aggiunte future by hgh81368

VIEWS: 8 PAGES: 5

									Piano di modifica delle features in "Vote on Air"
Versione 19/12/2009, Vittorio Romolini

Modifiche lessicali rispetto alla versione 1 del sistema di voto:
   1. le scelte di tipo "proposta" diventano dei "documenti"
   2. le scelte diventano "proposte", dunque anche i relativi identificatori saranno "pid" anziché "cid"
   3. il "trasduttore" diventa "scrutinatore"


Motore del sistema di voto (API), versione 2
Nella sua prossima versione, il sistema di voto online prevederà le seguenti funzionalità e possibilità:
    A) integrità della base di dati
            1. Le operazioni di inserimento/modifica/eliminazione di tuple nella base di dati e che consistono in più di
                una query di scrittura devono essere racchiuse all'interno di transazioni
    B) nuova fase "accettazione"
            2. Tra la fase di presentazione delle proposte e le fasi di sottoscrizione+votazione occorre inserire la fase
                di accettazione durante la quale gli utenti autorizzati (vedi apposita sezione) potranno "bloccare"
                alcune proposte così come fu richiesto dalla presidenza del Congresso dell'Ass. Coscioni.
                La logica delle fasi successive di VOA dovrà dunque considerare questo ulteriore elemento per
                valutare se una proposta è sottoscrivibile e/o votabile.
    C) nuovo tipo di proposta: "no"
            3. La proposta di tipo "no" (che va ad affiancarsi a: effettiva, bianca, nulla) sarà usata nel contesto delle
                sole votazioni di quesiti referendari.
    D) nuovo tipo di competitor: "quesito referendario"
            4. L'elezione tra quesiti referendari serve a rappresentare tutte le singole votazioni sì/no (referenda,
                mozioni particolari in un congresso, emendazione di testi, ...): per queste elezioni il sistema deve
                provvedere a creare automaticamente la proposta "no".
                Un'elezione "quesito referendario" riferisce una specifica elezione di tipo "pacchetto referendario" dalla
                quale eredita (in sola lettura) gran parte degli attributi: scrutinio palese/segreto, elettorati, …
    E) nuovo tipo di competitor: "pacchetto referendario"
            5. Un pacchetto referendario serve a raggruppare un certo insieme (di dimensione non predefinita) di
                quesiti referendari. Questo tipo di elezione si rende necessario in quanto l'utente autorizzato (membro
                dell'elettorato passivo del pacchetto referendario) deve poter proporre un referendum anche se non
                dispone del diritto di indire un'elezione.
    F) autorizzazioni
            6. VOA non deve più basarsi sulla funzione della contro-api voa_get_callers_for_elections() .
                Piuttosto la contro-api deve definire una nuova funzione voa_can_call_for_elections() che restituisce
                TRUE/FALSE a seconda del permesso del solo utente corrente a creare elezioni. In questo modo
                l'interfaccia di VOA per specificare chi può indire elezioni si integra alla perfezione con i sistemi di
                definizione delle autorizzazione dei CMS ospite (ad esempio in Drupal basterà un chiamata a
                user_access invece di ricorrere all'attuale sistema più contorto).
            7. Nella contro-API va introdotta una nuova funzione voa_can_use_voa() che restituisce TRUE/FALSE a
                seconda se l'utente corrente può usare le funzionalità di VOA. Ogni funzione di autorizzazione in
                VOA dovrà dipendere dal valore restituito da voa_can_use_voa()
            8. Nella contro-API va introdotta una nuova funzione voa_is_webmaster() che restituisce TRUE/FALSE a
                seconda se l'utente corrente è il webmaster
            9. In un'elezione i cui competitors sono liste, introdurre i divieti:
                     ▪ di creare nuove liste se si fa già parte (come membri confermati) di altre liste della stessa
                         elezione
                     ▪ di invitare in una lista i creatori delle altre liste della stessa elezione (considerando solo le
                         proposte effettive)
            10. Permesso di "accettare" le proposte di un'elezione: controlla che l'utente corrente sia l'autore
                dell'elezione e che l'elezione sia in fase accettazione
            11. Permesso di bannare i commentatori pro/contro ad una proposta: controlla che l'utente corrente
                sia l'autore dell'elezione oppure (ma solo per i commenti "pro") sia l'autore della proposta.
                Parametro opzionale: "chi" si vuole bannare? Se costui è specificato ed è l'autore della proposta, allora
                il permesso è negato, altrimenti concesso in base ai criteri precedentemente esposti.
            12. Permesso di inviare commenti pro/contro una proposta: in generale controlla se l'utente corrente
                appartiene ad uno degli elettorati dell'elezione (attivo, passivo, sottoscrittori, sottoscrittori speciali).
                Se però l'utente corrente è tra i commentatori bannati per la tale proposta e per il tale tipo di
                commenti (pro/contro) allora egli non può inviare il commento.
                Ad ogni modo non è possibile commentare una proposta che non sia effettiva.
            13. Permesso di valutare i commenti pro (o contro) una proposta: controlla che l'utente corrente abbia
                inviato (per la stessa proposta) almeno un commento dello stesso tipo dei commenti che vuole
                valutare. Esempio: chi ha commentato "pro" può valutare solo i commenti "pro".
                Nota: l'autore della proposta, anche se non ha commentato, può sempre valutare i commenti "pro"
       14. Permesso di eliminare un talk: controlla che l'utente corrente sia proprio l'utente riferito da
           who_reply del talk specificato
       15. Se l'elezione è un test in ogni fase deve essere possibile modificare molti più attributi
       16. Chi crea un'elezione può specificare se il sistema deve mostrare (e farle sottoscrivere/votare) agli
           utenti le proposte BLANK e NULL (che comunque vengono sempre generate in automatico)
       17. La funzione voa_delete_election deve avere il parametro bypass_test_attribute (per default
           FALSE). Se si specifica TRUE e la nuova funzione voa_is_webmaster restituisce TRUE, allora la
           funzione voa_delete_election assumerà (senza verificarlo) che l'elezione specificata sia un test e
           quindi ne permetterà l'eliminazione.
           Questa funzione permette quindi al webmaster (che comunque potrebbe eliminare l'elezione tramite
           accesso diretto alla BD o via query sql tramite php) di poter cancellare senza troppo complicazioni
           un'elezione indetta erroneamente: gli sarà necessario eseguire il codice php voa_delete_election(eid,
           eliminare_elettorati_non_usati, TRUE) tramite ad esempio il modulo Devel di Drupal.
       18. Chi crea un'elezione possiede i diritti di gestione delle proposte non effettive (NULL,BLANK,NO)
       19. Deve essere possibile cancellare la candidatura in lista anche se essa è già stata accettata, purché
           ciò avvenga ancora nella fase di presentazione
G) attributi di un'elezione
       20. Il numero massimo di persone che possono far parte della lista
           (applicabile alle elezioni i cui competitors sono liste di qualsiasi tipo)
       21. Il numero massimo di preferenze esprimibili con un singolo voto
           (applicabile alle elezioni i cui competitors sono liste di qualsiasi tipo, intero maggiore o uguale a 1)
       22. Il peso delle sottoscrizioni speciali, ovvero il valore che viene dato a ciascuna sottoscrizione
           speciale per determinare se una proposta ha superato la fase di sottoscrizione. Il valore default (zero)
           sta ad indicare che basta una sottoscrizione speciale per fare passare la proposta alla fase di
           votazione.
       23. Il tipo di sistema elettorale: standard (per tutti i tipi di competitors) o instant runoff (applicabile
           solo se i competitors sono: documenti oppure utenti oppure liste bloccate — cioè non si applica per:
           referendum e iste con preferenze)
       24. Il numero di voti che ciascun elettore può esprimere se il sistema elettorale è l'instant runoff (è un
           intero maggiore o uguale ad uno)
H) cronologia delle attività di un utente ("facebook elettorale")
       25. Introdurre una nuova tabella nella base di dati: "activities"
           Attributi della tabella (tutto-chiave):
                 UID who                         ← identificatore dell'utente che ha compiuto l'azione
                 UINT operation                  ← identificatore dell'azione
                 DATE date                       ← data in cui è stata compiuta l'azione
                 EID election_id                 ← identificatore dell'elezione nella quale è stata compiuta l'azione
                 VARCHAR parameters              ← parametri descritti dell'azione
           Esempi (uid=identificatore dell'utente corrente // pid=identificatore proposta):
                •   crea elezione: uid, op_id("crea elezione"), time(), eid, NULL
                •   modifica elezione: uid, op_id("modifica elezione"), time(), eid, NULL
                •   annullamento elezione: uid, op_id("annulla elezione"), time(), eid, NULL
                •   eliminazione elezione: uid, op_id("elimina elezione"), time(), eid, NULL
                •   registrazione seggio fisico: uid, op_id("registrazione seggio"), time(), eid, id_seggio
                •   revoca della registrazione al seggio fisico: uid, op_id("revoca delega"), time(), eid, id_seggio
                •   inserimento voto segreto: uid, op_id("voto"), time(), eid, {seggio}
                •   inserimento voto palese: uid, op_id("voto"), time(), eid, {seggio, pid, preferenze}
                •   creazione proposta: uid, op_id("crea proposta"), time(), eid, pid
                •   modifica proposta: uid, op_id("modifica proposta"), time(), eid, pid
                •   eliminazione proposta: uid, op_id("elimina proposta"), time(), eid, pid
                •   la sua proposta è stata approvata: uid, op_id("proposta approvata"), time(), eid, pid
                •   invio commento ad una proposta: uid, op_id("commento proposta "), time(), eid, {pid, tipo}
                •   bannato dai commentatori di una proposta: uid, op_id("bannato"), time(), eid, {pid, tipo}
                •   sottoscrizione: uid, op_id("sottoscrizione"), time(), eid, pid
                •   ricezione invito in lista: uid, op_id("invito in lista"), time(), eid, pid
                •   rimozione della lista: uid, op_id("rimosso dalla lista"), time(), eid, pid
                •   rifiuto invito in lista: uid, op_id("rifiuto invito"), time(), eid, pid
                •   conferma invito in lista: uid, op_id("conferma invito"), time(), eid, pid
                •   in caso di pubblicazione di una risposta, gli eventi da registrare sono due:
                    uid_di_chi_chiede, op_id("mi hanno risposto"), time(), eid, tid
                    uid_di_chi_risponde, op_id("ho risposto"), time(), eid, tid
       26. Se una elezione o una scelta riferite in "activities" venisse rimossa? Occorre quindi tenere un'altra
           tabella ("last_names") con i nomi tenuti da elezioni/proposte/talk/utenti al momento della
           loro rimozione. Gli attributi sarebbero evidentemente: tipo dell'oggetto (election, proposal, talk,
           utente); id; titolo
I) deleghe di voto e seggi fisici
       27. Gli attributi di ciascun seggio fisico: id, elezione, titolo, scrutinatore, indirizzo del luogo, URL di
           una mappa, data+ora di apertura, data+ora di chiusura del seggio.
           Un seggio fisico può essere creato da chi può indire elezioni.
           Nota: il seggio con id 0 è implicitamente internet e viene usato per tutte le elezioni.
       28. Occorre eliminare la possibilità di delegare il proprio diritto di voto ad altri membri
           dell'elettorato attivo: non è così utile come immaginato durante la progettazione di VOA1 e per di
           più complica notevolmente il sistema di voto (sia la logica, sia l'intuitività dell'interfaccia).
           Le uniche deleghe possibili saranno assegnabili ai soli scrutinatori di seggi fisici; la loro semantica può
           essere sintetizzata come risposta a: "quale è il seggio fisico nel quale l'utente intende votare?".
       29. Permettere la revoca della delega allo scrutinatore di un certo seggio
       30. Il calcolo dei risultati del voto accetterà come nuovo parametro di ingresso (facoltativo) il riferimento
           ad un seggio fisico. Se questo parametro non viene passato, vengono restituiti i risultati generali,
           altrimenti sono restituiti i risultati nel seggio specificato.
J) revisione dello schema della base di dati per quanto riguarda la memorizzazione dei voti/votanti
       31. una tabella unica dei votanti, sia per le elezioni palesi che segrete: "voters" (chiavi: eid, uid)
                 EID eid                        ← identificatore dell'elezione per la quale è stato espresso il voto
                 UID uid                        ← identificatore dell'elettore
                 DATE vote_date                 ← data in cui è stato espresso il voto
       32. una tabella unica dei voti palesi (tipo 1), dei voti segreti (tipo 2), delle preferenze palesi (tipo
           3) e delle preferenze segrete (tipo 4): "votes" (tutto-chiave)
                 UINT type                      ← il "tipo" di ciascuna entry della tabella
                 UINT polling_station           ← in quale seggio è stato espresso il voto?
                 PID pid                        ← l'identificatore della proposta votata
                 NULLABLE UID voter             ← l'identificatore del votante (NULL se il tipo è 2 oppure 4)
                 NULLABLE UINT total            ← il totale dei voti/preferenze ricevute dalla proposta/candidato
                                                   (NULL se il tipo è 1 oppure 3)
                 NULLABLE UID preference ← l'identificatore dell'utente espresso come preferenza
                                                   (NULL se: (il tipo è 1 o 2) o (sistema elettorale=instant runoff))
                 UINT rank                      ← il ranking del voto per l'instant runoff
                                                   (1 se il sistema elettorale dell'elezioni non è l'instant runoff)
                                                   Nota: l'instant runoff non è applicabile ad elezioni con preferenze
           Esempi:
                •   voto palese senza preferenza:
                    1, polling_station , pid, voter, NULL, NULL,1
                •   voto palese con due preferenze:
                    1, polling_station , pid, voter, NULL, NULL, 1
                    3, polling_station , pid, voter, NULL, pref1, 1
                    3, polling_station , pid, voter, NULL, pref2, 1
                •   voto segreto senza preferenza
                    2, polling_station , pid, NULL, (total+1), NULL, 1
                •   voto segreto con due preferenze
                    2, polling_station , pid, NULL, (total+1), NULL, 1
                    4, polling_station , pid, NULL, (total+1), pref1, 1
                    4, polling_station , pid, NULL, (total+1), pref2, 1
                •   voto palese con instant runoff a due voti
                    1, polling_station , pid1, voter, NULL, NULL, 1
                    1, polling_station , pid2, voter, NULL, NULL, 2
                •   voto segreto con instant runoff a due voti
                    2, polling_station , pid1, NULL, (total+1), NULL, 1
                    2, polling_station , pid2, NULL, (total+1), NULL, 2
K) arricchimento delle strutture-dati restituite dalle funzioni di accesso ai dati
       33. le funzioni che restituiscono informazioni e dettagli sugli oggetti trattati dal sistema di voto (elezioni,
           elettorati, proposte, …) devono sempre restituire i nomi degli oggetti stessi, non solo gli identificatori
           numerici.
           Ad esempio voa_get_election_info() deve restituire anche i nomi degli elettorati, gli elenchi di
           proposte devono contenere anche i nomi delle proposte (e quindi bisogna trasferire nell'API la logica
           per la costruzione del titolo in base al tipo della proposta stessa), … eccetera.
L) commenti
       34. tre nuove tabelle per i commenti, per le valutazioni dei commenti e per la gestione degli utenti ai
           quali viene impedito l'invio di commenti:
           comments (chiave: cid)
                 UINT cid                       ← identificatore del commento
                 UID comment_author             ← identificatore dell'autore del commento
                 UINT pid                       ← identificatore della proposta commentata
                 TEXT comment_message           ← testo del commento
                 BOOL pro                       ← tipo di commento: pro o contro
           comments_ratings (chiave: cid, uid)
                 UINT cid                       ← identificatore del commento
                 UID uid                        ← identificatore dell'utente che ha valutato il commento
                 UINT rating                    ← valutazione (da 1 a 5) del commento
           comments_banned (tutto-chiave)
                 UID uid                        ← identificatore dell'utente bannato dai commenti della proposta
                 PID pid                        ← identificatore della proposta
                 BOOL pro                       ← tipo di commenti della proposta che l'utente non può più fare
           35. chi può esplorare un'elezione può anche recuperare l'elenco dei commenti pro e contro per una
               data proposta e il relativo rating medio.
           36. gli utenti autorizzati possono lasciare commenti alle proposte (classificandoli come a favore o
               contro, come in Rule2Gether 1 )
           37. gli utenti autorizzati possono bannare i commentatori. Nota: quando si banna un commentatore ne
               vanno eliminati i commenti dello stesso tipo per la stessa proposta e ne vanno eliminati i rating per i
               commenti dello stesso tipo e della stessa proposta
           38. gli utenti autorizzati possono valutare i commenti
     M) question & answer
               una nuova tabella "talks" per le conversazioni elettore-candidato:
                    TID tid                      ← identificatore del talk
                    UID who_ask                  ← identificatore dell'utente che ha posto la domanda
                    UID who_reply                ← identificatore dell'utente stato chiamato a rispondere
                    TEXT question_message        ← messaggio della domanda
                    DATE question_date           ← data della domanda
                    TEXT answer_message          ← messaggio di risposta
                    DATE answer_date             ← data della risposta
                    VARCHAR title                ← titolo della conversazione
                    BOOL published               ← il talk è pubblicato?
           39. gli utenti autorizzati ad usare VOA possono formulare domande ad altri utenti (chiamiamoli
               "candidati") autorizzati ad usare VOA, specificando anche un titolo per il talk. Una volta inviata, né la
               domanda né il titolo sono più modificabili
           40. i candidati potranno decidere se rispondere e se lo scambio di messaggi debba essere pubblicato su
               un'apposita pagina delle "Domande & risposte" del candidato. Nel rispondere, I candidati possono
               modificare il titolo del talk.
           41. un utente A può vedere tutte le conversazioni pubblicate del candidato B oltre alle
               conversazioni tra A e B anche se non pubblicate (ovviamente l'interfaccia dovrà enfatizzare la
               differenza tra questi due casi).
               il candidato B ovviamente può leggere tutti i talk che sono stati avviati verso di sé.
           42. gli utenti autorizzati possono eliminare un talk
     N) assorbimento del modulo voa_demo
           43. mantenimento di: disabilitazione profili demo user; messaggi di preavviso di pulizia
               ad ogni cron run, però, andranno eliminate solo le azioni compiute dai demo user
           44. un block che mostra la descrizione della pagina corrente


Motore del sistema di voto (API), possibili altre aggiunte
Il sistema potrebbe prevedere, in sue successive versioni, le seguenti funzionalità e possibilità:
     1. le relazioni di invalidazione per i quesiti referendari: si deve permettere di specificare che se in un
         pacchetto referendario ci sono due quesiti A,B e se A viene approvato allora B è automaticamente bocciato (a
         prescindere dai risultati di voto). Notare che va impedito che accada il seguente scenario: A invalida B e B
         invalida A. Si rende quindi necessaria la creazione della tabella "referendum_invalidations":
                  PID validator, PID to_be_validated
         Riflettere: chi è autorizzato a definire la lista di invalidazione per un quesito referendario?
     2. a favore degli utenti "offline" o comunque non capaci di usare il computer (già in grado di votare per
         interposta persona):
              •   chi crea un'elezione dovrebbe poter presentare delle proposte per conto di altri membri dell'elettorato
                  passivo (anche se chi crea l'elezione non appartiene all'elettorato passivo) con tanto di segnalazione
                  all'utente stesso che è stata presentata una proposta per suo conto (così che possa eventualmente
                  rimuoverla)
              •   trovare un modo per farli partecipare indirettamente anche alla fase di sottoscrizione delle proposte
     3. i contenitori delle elezioni per raggruppare elezioni tra loro connesse
     4. possibilità di riordinamento dei membri di lista
     5. implementare la capacità di "calcolare" (con sistema proporzionale) quali membri di lista sono stati eletti,
         determinandoli in funzione di:
              ▪ numero di voti ricevuti dalla lista
              ▪ tipo di lista (bloccata?)
              ▪ numero di preferenze ricevute da ciascun membro di lista
     6. ulteriore attributo all'elezione: "doppio turno?" (booleano, default: false). se impostato su TRUE, l'elezione
         avrà due fasi di votazione (con un eventuale periodo di tempo di separazione) in cui alla seconda fase
         accedono solo le due proposte che hanno riscosso più consensi nella prima.
         Rispetto allo schema dei dati progettato finora, occorre aggiungere alla tabella delle elezioni degli ulteriori
         attributi: un booleano two_steps_votation, un intero eventualmente nullo second_votation_delay, una data
         eventualmente nulla second_votation_expiration
         Oltre a ciò occorre ripensare:
                 il modo di memorizzare i voti per via dei due momenti del voto a doppio turno: potrebbe essere usato
                  un ulteriore attributo che specifica il turno di votazione al quale si riferisce il voto memorizzato.
                 le funzioni di autorizzazione


1   http://www.slideshare.net/tff/rule2gethercom-decidiamoit
Interfaccia per Drupal-6, versione 2
  1.   usabilità
           1.   nella pagina dei dettagli delle elezioni accanto a ciascuna proposta va aggiunto il pulsante
                "sottoscrivi/vota questa proposta"
           2.   maggior ricorso ad AJAX per la il check client-side della validità dei dati inseriti nelle form
           3.   creazione di una dashboard o pagina introduttiva alle funzionalità del sistema di voto
  2.   ( tutta l'interfacci relativa alle nuove funzionalità descritte nella VOA-API v.2 )
  3.   lista dei votanti che hanno espresso una data preferenza
  4.   configurabilità degli allowed tags nelle descrizioni delle elezioni e delle proposte
  5.   hook voa_d6_user() , operazione VIEW: mostra i link alle pagine per vedere i voti pubblici e le
       sottoscrizioni dell'utente
  6.   nuova impostazione: il selettore di data&orario deve indicare tutti i minuti oppure solo un sottoinsieme di
       essi (ad esempio: 00, 05, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55 come in Facebook) ?
  7.   se una proposta appartiene ad un'elezione senza sottoscrizioni, il tab "sottoscrittori" nella pagina della
       proposta non va mostrato

								
To top