search

pcm-dpc / COVID-19

COVID-19 Italia - Monitoraggio situazione
Other
3.86k stars 2.24k forks source link

Assenza di procedure di controllo/rettifica dei DATI e CHIUSURA SEGNALAZIONI #982

Open iguandroid opened 3 years ago

iguandroid commented 3 years ago

Tipo di issue:

Riassunto

A titolo di esempio cito tre diverse segnalazioni, tutte riguardanti recenti incongruenze di specifiche regioni per quanto attiene al reporting dei "casi_testati".

Comincio dalla segnalzione #967 che è stata "chiusa" senza che:

Ebbene, il fatto che questa segnalazione risulti "chiusa" la colloca nel medesimo stato di #959 anch'essa riguardante un incongruenza nel dato dei casi_testati. La differenza sostanziale è che in questa circostanza:

Se quanto sopra non bastasse ad evidenziare l'incongruenza e approssimazione nella gestione delle segnalazioni (oltre che nei dati in quanto tali), aggiungo anche #972 anch'essa relativa ad un numero balordo di "casi_testati" comparso stavolta per il Molise. In questo caso:

Potrei fare numerosi altri esempi, ma mi limito a citare #974 che è invece stata chiusa, laddove il problema è palesemente ancora aperto e senza che si sia minimamente accennato ad una sua soluzione, meno che mai sia evidentemente stato recepito. Al contrario, è stato messo in dubbio che il problema sussista ("Cosa intendi con accuratezza dei dati?"), come se non sia evidente - e ne ho appena citato tre esempi recentissimi - il continuo reiterarsi di errori e incongruenze nei dati che vengono giornalmente pubblicati in questo repository.

Ebbene, finché persiste il problema della reiterata trasmissione di dati variamente sballati, perché pubblicati senza la benché minima procedura di controllo qualità che ne intercetti eventuali incongruenze prima della pubblicazione (e non ci vorrebbe molto visto che i consumatori di questi dati sono in grado di segnalare nel giro di MINUTI dalla pubblicazione), sarebbe FONDAMENTALE che almeno ci fosse un iter chiaro ed efficace di "presa in carico" delle segnalazioni e follow-up delle medesime, nonché chiarezza sui criteri in base ai queli le medesime possano essere dichiarate "chiuse".

Cosa che invece non è (come mi pare di avere esemplificato), il che aggiunge ulteriore incertezza e confusione ad un contesto già altamente dominato dall'approssimazione.

Dal che sono a sottoporre la seguente...

Proposta:

1) Nessuna "issue" dovrebbe venire chiusa senza un qualche genere di "acknowledge" da parte dei curatori del repository;

2) Tale "acknoweledge" deve:

3) Qualora il problema venga successivamente risolto, con correzione dei dati, se ne dia conferma in calce alla issue, prima di decretarne la chiusura (es.: "il dato è stato corretto oggi nel file storico nomefile").

4) Qualora il problema non sia risolvibile (la fonte non è in grado di comunicare il dato corretto), la issue può essere chiusa solo a condizione che venga inserita nel DB adeguata nota di quel dato errato (es.: alla riga del Lazio del 4 Dic.: "Dato casi_testati non aggiornato/disponibile - cfr. issue #967") in modo che resti traccia/documentazione del problema.

5) Qualora dopo N giorni dall'apertura della issue il problema non sia risolto e nessuno se ne stia più facendo carico (come accade per infinite segnalazioni rimaste nel limbo) che qualcuno si assuma la responsabilità di procedere come al punto 4, aggiungendo un commento conclusivo nel thread descrivente il problema prima di chiuderlo.

Naturalmente se si ritiene più efficace adottare criteri/modalità diversi, ben venga a condizione che ci si dia un metodo utile a produrre un risultato/beneficio tangibile, e cioè che anche per le incongruenza irrisolte, RESTI TRACCIA NELLA BASE DATI.

E fosse mai che a qualcuno (che ancora non ha colto cosa si intenda per "accuratezza dei dati") sfuggisse l'esigenza di quanto sopra, lo invito a immaginare di dover caricare tutti i dati dal CSV storico per produrne dei grafici (anche i più banali) e trovarsi di fronte a una moltitudine di incongruenze che:

Il tutto senza che, nonostante tutte le segnalazioni di questo mondo, nel campo note che affianca ciascuna di queste "anomalie" ci sia il benché minimo chiarimento del tipo: "Il totale casi odierno di Bolzano non è ZERO come risulta, ma nessuno si è mai preso la briga di correggere con il dato appropriato; cfr. #867".

Con l'auspicio che da queste osservazioni/suggerimenti scaturisca qualcosa.

Cordiali saluti.

alexodus commented 3 years ago

Mi spiace che tu abbia dedicato tanto tempo a scrivere tutto questo "papiro" con l'illusione che @umbros ti risponderà. Lui se ne infischia del buon funzionamento del repository. Anche dei tanti che hanno voluto offrire un contributo tipo pull request per gestire la validazione dei dati. Quale vantaggio ne ottenga nell'avere un repository soggetto, dopo 9 mesi, alle peggio castronerie, non mi è dato sapere. Però l'inettitudine rimane visibile e chiara a chiunque abbia un minimo di dimestichezza con l'informatica. E le figure di cacca a livello internazionale per dei dati che manco sono validati ce la meritiamo tutta! @umbros DIMETTITI!!!!!!!

alexodus commented 3 years ago

@iguandroid guardati la pull request #847 per gestire un minimo di validazione.....è dell'8 Settembre e nessuno se l'è filato...3 mesi, dico: 3 M-E-S-I!!!!

iguandroid commented 3 years ago

Però l'inettitudine rimane visibile e chiara a chiunque abbia un minimo di dimestichezza con l'informatica.

Che dire... quando per ben due volte in meno di una settimana si pubblicano dati con errori nell'ordine del 1000% (cioè 10 volte quelli che avrebbero dovuto essere!) e si ha anche la faccia tosta di mettere nero su bianco frasi del tipo "cosa intendi per accuratezza dei dati?", c'è poco altro che meriti di essere aggiunto... (più che "scienze dell'informazione" si potrebbe dire "vadiamo se così me la cavo...").

La latitanza pilatesca e il reiterato e puntiglioso sottolineare che "qui è necessario modificare i dati da parte della Regione, domani saranno corretti" (senza che poi naturalmente ne segua alcunché) chiariscono il resto...

floatingpurr commented 3 years ago

A tal proposito vedere anche #945

miccoli commented 3 years ago

Non partecipo volentieri a queste discussioni, ma essendo l'autore della GH-847, vorrei spezzare una lancia a favore di @umbros.

Mi sembra evidente che questa sia una repo "istituzionale", e come tale quello che può fare/non fare un singolo è molto limitato. Il fatto stesso che sia una sola persona a fare commit / triage delle issue / gestione delle pull request dimostra che si è investito molto poco. Non possiamo pretendere un servizio di qualità professionale, se alla fine è tutto sulle spalle di un "one-man-team".

Dunque nessun dubbio sulla buona volontà di @umbros, che non conosco, ma tutto il mio disappunto sul fatto che la presidenza del consiglio dei ministri e il dipartimento della protezione civile non abbiano saputo trovare le risorse che permetterebbero di formare una squadra con le competenze e la forza lavoro necessarie a gestire questa repo.

Concludo amaramente, osservando che la buona volontà di un singolo tiene in piedi un servizio di fondamentale importanza sia per la comunità scientifica, sia per la comunità civile Italiana. Non può esserci democrazia senza trasparenza, ed è proprio dalla trasparenza dei dati raccolti da PCM/DPC che stiamo parlando in questo thread.

PS. Sopra ho esordito dicendo che non intervengo volentieri, non tanto perché ritengo questa discussione inutile, anzi! Il problema è che stiamo derivando dai problemi di questa repo, a considerazioni che riguardano, la politica, l'organizzazione della raccolta dati, le persone. In qualche modo sono argomenti molto importanti, troppo importanti, per essere discussi nelle issue.

alexodus commented 3 years ago

@miccoli va precisato che non c'è solo @umbros ma anche @pierluigicara che fanno le commit sul repo. Inoltre, proprio perché esiste un concetto di community, parte del lavoro poteva essere tranquillamente fatto da "contributors" come la tua "inascoltata" pull request stessa dimostra. Non so se tu programmi caro @miccoli ma per gestire il tutto basterebbe un programmatore junior con 3/4 anni max di esperienza,per un'oretta o al massimo 2 al giorno. Manca la competenza di sicuro, che @umbros ha dimostrato di non avere.

Io ti invito a guardare ancora oggi che tipo di correzioni vengono fatte ai dati: ancora non si è capito se i dati sono interi o reali. Oggi si sono messi a numeri interi...ieri erano numeri reali (cosa insensata visto che i casi testati sono un numero intero) e se un tizio fa uno script aspettandosi un intero allora va in errore. Di questi errori (questo è banale ma dimostra l'inettitudine di chi li gestisce) ce ne sono a iosa nei 9 mesi che esiste questo repository. image

alexodus commented 3 years ago

PS: domani probabilmente il campo "casi_testati" sarà delimitato da apicetti, vero @umbros ? :D

miccoli commented 3 years ago

@alexodus condivido pienamente la tua frustrazione.

Il problema è sicuramente un work-flow con troppi step manuali, scelte apparentemente erratiche e dettate dall'impeto del momento, la mancanza di una procedura chiara di verifica qualità, la mancanza di una policy che chiarisca quando e come possono essere corretti i dati... (e mi fermo qui perché l'elenco rischia di diventare troppo lungo.)

Tutto questo era accettabile a marzo ed aprile. Oggi invece non ha più alcun senso.

alexodus commented 3 years ago

@miccoli ti faccio un ultimo esempio di cui mi sono accorto poco fa. Come ben sai (#980) i campi casi_da_sospetto e casi_da_screening da 2 dicembre non sono più valorizzati. Fino a ieri in quei campi veniva messo "0" e questo faceva si che l'app che ho realizzato e che usano in tanti, funzionasse (a meno dell'antistetico "0" che compare nella home per i 2 campi). Bene: oggi hanno deciso così, di punto in bianco, di mettere al posto di "0" il valore "null". Questo fa si che la mia app vada in errore (fino al 1dicembre quel campo era mandatorio). Quindi ora dovrò sistemare il tutto e pure in fretta. Diciamo insomma che mi sarei un pochino rotto le palline di dove correre appresso agli incapaci (o incapace) che hanno messo a gestire questo repo. E come me anche altri si saranno stancati.

renatizzi commented 3 years ago

Assolutamente d'accordo con le considerazioni fin qui fatte e visto che sono stato chiamato in causa quale estensore dell'issue #974, a conferma di quanto detto, aggiungo il commento destinato ad @umbros in risposta alla sua singolare domanda "Cosa intendi con accuratezza dei dati?":

"... ti confesso che ho difficoltà a interpretare correttamente il senso della tua domanda perché il concetto di accuratezza è basilare e di fondamentale importanza per chi tratta dati ed informazioni. Cito in ogni caso Treccani per il significato in metrologia: "differenza tra il valore misurato e il valore presunto vero di una grandezza". Ho usato volutamente questo termine e non quello di "precisione" perché, nel caso in specie, il tasso di errore è molto elevato avendo a che fare con dati inseriti manualmente e pertanto, vista la loro rilevante sensibilità, sarebbe opportuno introdurre una serie di controlli formali prima della loro pubblicazione. Peraltro ritengo che la rettifica a posteriore degli stessi dati non soddisfi le esigenze di coloro i quali usano i file csv messi a disposizione."

Ritengo però inopportuno prendersela con Tizio piuttosto che con Caio; come più volte ribadito, la qualità dei dati assume in questo contesto un'importanza rilevante e meriterebbe un'immediata azione di escalation per porre rimedio ai problemi rilevati. I media potrebbero veicolare efficacemente questa specifica esigenza.

Renato Stefanizzi

floatingpurr commented 3 years ago

Al di là di tutto, sarebbe davvero apprezzato un feedback di @umbros sul tema per capire se la qualità e la pulizia dei dati è percepita come un problema oppure no e se, in caso positivo, si sta pensando di automatizzarne la verifica.

Come scrivevo nella #945, è comprensibile che rettificare un numero nella sua sostanza richieda una serie di processi "burocratici" che coinvolgono gli enti emittenti (e.g., le regioni) che non possono essere automatizzati. Tuttavia ci sono una serie di errori banali, probabilmente introdotti da procedure manuali, che si potrebbero rettificare facilmente prima del rilascio. Parlo di errori di serializzazione, formati, refusi, etc... E' qui che secondo me un workflow automatizzato farebbe una grande differenza a basso "costo".

@umbros, perdonami se insisto ma si tratta di una questione sollevata a più riprese che sarebbe davvero un peccato lasciar cadere nel nulla senza alcun riscontro.

renatizzi commented 3 years ago

Sono d'accordo con te floatingpurr, ma sinceramente non credo che il feedback di @umbros possa essere risolutivo. Come detto, occorrerebbe a mio avviso un intervento di escalation nei confronti di Arcuri/Speranza, sottolineando come il problema sollevato possa inficiare di fatto l'impegno profuso finora dall'intera filiera operativa. D'altra parte sono convinto che l'effort richiesto per la revisione del workflow sia davvero marginale: è una mera questione di "volontà politica"...

FragIt66 commented 3 years ago

Personalmente ho utilizzato i file json per creare una dashboard web basata sullo stack MEAN ( Mongodb / Express / Angular / NodeJS ) E' un peccato che la qualità del dato sia questa, anche perchè si potrebbero sistemare diverse cose con un costo pressochè nullo. Ad esempio, per la validazione dei json, immagino che esistano librerie per tutti i linguaggi possibili ( su npm nè ho trovate già un paio destinate a javascript/typescript ). Per evitare di pubblicare dati duplicati ( è successo di recente sui regionali ), se vengono fuori da un qualche db, basterebbe mettere un bell'indice unique. Di esempi se ne potrebbero fare tanti ... ma, purtroppo, ho l'impressione che non ne verremo fuori....