Wikipedia:Bar/Discussioni/Sistema di riconferma CU

Da Wikipedia, l'enciclopedia libera.
Vai alla navigazione Vai alla ricerca

Sistema di riconferma CU

Ultimo intervento: 10 agosto 2017, 18:33 | 22,3 KB | RSS · Atom | Torna al bar


Lo stesso argomento in dettaglio: Wikipedia:Bar/Discussioni/CU: elezioni e riconferme.
Lo stesso argomento in dettaglio: Meta:CheckUser policy/it, Meta:Policy sull'accesso ai dati riservati e Wikipedia:Politica relativa alla privacy.

Riesumo e rinnovo una "vecchia" discussione a propostito delle riconferme dei Check user: mi piacerebbe arrivare ad una soluzione che possa essere condivisa da tutti, tenendo ben presente quanto detto in passato. Mi si permettano un paio di precisazioni preventive, visti gli argomenti emersi nella scorsa discussione (linkata qui in alto).

Premessa sulle policy che regolano i Check User WMF

Il ruolo del check user è regolato da una severa policy di WMF, che a sua volta rispetta le policy di WMF sulla privacy e sull'accesso ai dati riservati. Queste policy sono linkate in calce ad ogni pagina di Wikipedia e in ogni finestra di modifica: il lettore di Wikipedia dovrebbe quindi essere consapevole che il sistema registra alcuni dei suoi dati (come li registrano tutti i siti web), e l'utente (registrato o meno) che effettua una modifica è informato del fatto che il proprio indirizzo IP verrà registrato. La policy di WMF che vuole che questi dati siano solitamente riservati (a meno che l'IP non operi da anonimo, ovviamente) non è qui in discussione (le sedi sono ben altre, non certo la Wiki locale), come non è in discussione il fatto che determinati utenti, identificati con documento presso WMF, possano accedere ai log. Al termine di questa premessa, evidenzio come la policy di WMF tratti solo dell'elezione del CU, non della sua eventuale riconferma:

La comunità deve approvare i CheckUsers locali con il consenso. [...] Dopo aver ottenuto il consenso (almeno il 70%-80% dei favorevoli nelle votazioni o il maggior numero di voti nel caso ci siano candidature multiple) nella comunità locale, con l'approvazione di almeno 25-30 utenti, l'utente si aggiungerà alla Requests for permissions avendo cura di indicare con un link la pagina dove è contenuta la decisione della comunità. [...] Se l'account di un utente con lo status CheckUser è inattivo per più di un anno, avrà il flag CheckUser rimosso.

Per inciso, la nostra policy locale prevede una maggioranza del 80% (per l'elezione e idem per le riconferme) e un periodo di decadenza di due mesi. Ho segnalato il minimo nella policy sul quorum, anche se fortunatamente viaggiamo su numeri ben maggiori.

Dopo questa premessa, espongo la questione e la mia proposta.

Le riconferme dei CU sono un momento molto importante, per i quali la Comunità si è espressa più volte richiedendo una votazione esplicita (niente "silenzio assenso" né "stile burocrati"). Tuttavia, delle votazioni di riconferma spesso ce ne dimentichiamo, essendo decisamente poche (e fortunatamente non abbastanza "chiassose" da ricordarsi della loro esistenza :D ). Per fare in modo di semplificare la procedura, non nella sostanza ma più che altro nella "tempistica", avrei due proposte alternative: la prima prevede l'unificazione temporale delle riconferme di tutti i CU, la seconda l'accostamento della riconferma da CU a quella da amministratore.

Nel primo caso, si potrebbe tenere il mese di maggio (visto che lo scorso anno ce ne siamo ricordati proprio a maggio) o proporre febbraio (che mi piace di più come periodo), arrotondando per eccesso o per difetto la durata del primo anno di servizio in modo da mettere in pari la riconferma del neo-CU con quella dei colleghi. Mi rendo conto che un allungamento dei termini di potrebbe essere eccessivo, per questo si può pensare di abbreviarlo in ogni caso (anche se il caso del CU eletto a novembre 2012 e riconfermato già a febbraio 2013 mi parrebbe eccessivo). Nel caso, se ne può discutere.

Nel secondo caso, le opzioni sono a loro volta due: prima la votazione da CU e poi la riconferma da sysop, oppure viceversa. In entrambe le proposte c'è sia il caso "doppio passaggio" che il caso "veloce". Tuttavia, dato che è più frequente che il CU venga confermato piuttosto che revocato, la procedura "2" sarebbe più snella, ma prevederebbe una "doppia sfiducia esplicita" per chiedere il deflag, con conseguenti motivazioni "contro l'amministratore" nella votazione per il check user. Faccio uno schema per riassumere le varie possibilità:

1. Ricoferma da amministratore

a. Revoca --> revoca da amministratore e da CU, oppure
b. Riconferma --> votazione da CU

2. Votazione da CU

a. Confermato --> automaticamente confermato amministratore (non può essere CU senza essere sysop)
b. Revocato --> procedura di riconferma da amministratore (comunque tacita o votiamo subito?)

Dopo tutto questo papello, chiedo il vostro parere. Ricordo che non sono in discussione né la sostanza, né le modalità, né il ruolo stesso dei check user, ma solo "quando" fare la riconferma per semplificare il tutto.--DoppioM 18:35, 22 nov 2012 (CET)[rispondi]

Io sarei per votare i CU tutti insieme nello stesso periodo, quindi sono propenso per il primo caso. Restu20 18:52, 22 nov 2012 (CET)[rispondi]
Anch'io d'accordo sul voto unico. Quale mese - il candidato attualmente in votazione non me ne voglia - non è IMHO un tema centrale, visto che il problema si porrà anche a regime: d'ora in poi, se (diciamo nel 2043) dovessimo votare un CU nel mese di gennaio, una trentina di giorni dopo andrebbe in riconferma (l'alternativa sarebbe definire una ridicola "stagione dei CU", qualcosa del tipo "si eleggono solo fra aprile e ottobre"; insomma: non regge).
Al limite, se si vuole, si potrebbe decidere di includere i CU "freschi" nella riconferma solo se dall'elezione è passato un tot di mesi, ma onestamente mi sembra un avvitamento evitabile.--Formica rufa 20:30, 22 nov 2012 (CET)[rispondi]
Si può dire: si decide maggio (abbastanza lontano dall'estate, dalle vacanze natalizie e da quelle pasquali :D ). Il neo-CU resta in carica al massimo 12+4? mesi, quindi se è eletto a settembre 2012 si becca febbraio 2013 (5 mesi), se è eletto a ottobre se ne riparla a febbraio 2014 (16 mesi). In pratica si arrotonda... non alla "metà", solo per il primo anno.--DoppioM 21:34, 22 nov 2012 (CET)[rispondi]
Si può anche fare così, tanto non credo che qualche mese in più (o in meno) facciano la differenza in maniera sostanziale. Restu20 01:31, 23 nov 2012 (CET)[rispondi]
Perché non mantenere la riconferma di anno in anno, come per gli amministratori? Si guarda la data dell'ultima riconferma da CU (o dell'elezione) e si agisce di conseguenza. Allo stato attuale ci troveremmo tre riconferme a maggio, una a gennaio ed una (probabilmente) a dicembre. Non vedo perché complicare la cosa (o forse mi sono perso discussioni precedenti che non ho tempo di andare a leggere). --Mark91it's my world 02:26, 23 nov 2012 (CET)[rispondi]
Mark, la riconferma è e rimarrà sempre di anno in anno. Il fatto è che averne 5 in 5 periodi diversi dell'anno non aiuta, e semplicemente ce ne dimentichiamo (tre sono insieme perché l'anno scorso me ne sono ricordato io quando tre erano ormai scadute da un pezzo e le ho fatte partire insieme). Per questo ho pensato di proporre un sistema per averle "più comode", ovvero o unite alla riconferma o tutte nello stesso periodo.--DoppioM 12:39, 23 nov 2012 (CET)[rispondi]
IMHO mi sembra un pò assurdo avere una "stagione di riconferme CU" come si diceva qui sopra. Basta che qualcuno tenga d'occhio le date su WP:CU. --Mark91it's my world 02:25, 24 nov 2012 (CET)[rispondi]
Cosa che negli ultimi anni non è successa :D--DoppioM 14:43, 24 nov 2012 (CET)[rispondi]

Unificazione[modifica wikitesto]

Faccio una proposta per snellire l'imperante burocrazia wikipediana. Personalmente sono d'accordo con la proposta di unificazione indicata sopra da DoppioM (e vedo un discreto consenso), la riassumo per chi arriva dal bar. Visto che le procedure sui CU sono spesso dimenticate, a volte fatte partire con settimane o mesi di ritardo (perchè nessuno se ne ricorda), mi pare intelligente e comodo unificarle con quelle da admin. La procedura di conferma, in sostanza, riguarderebbe il ruolo di "funzionario wikipediano" (passatemi il termine): se la comunità non lo ritiene adatto a uno dei ruoli che svolge, decade ovviamente in tutti. La fiducia, infatti, viene prima di tutto.

Domanda: siete d'accordo a unificare la votazione di riconferma per admin e CU? Nella pratica, se un utente viene sfiduciato come admin (che ha "poteri" limitati), a maggior ragione viene sfiduciato come CU (che tratta dati che riguardano la privacy); se viene sfiduciato in quanto CU (che tratta cose più "serie") comprensibilmente non ha fiducia nemmeno come admin. Perciò: accorpiamo in nome della semplicità e coerenza? --Lucas ✉ 19:54, 14 giu 2013 (CEST)[rispondi]

Lucas ha scritto più sopra nella proposta: « se un utente viene sfiduciato come admin [...] a maggior ragione viene sfiduciato come CU [...]; se viene sfiduciato in quanto CU [...] comprensibilmente non ha fiducia nemmeno come admin ». Quindi non ci sarebbe il caso di un CU sfiduciato che resterebbe Admin ma le due funzioni sarebbero legate tra loro indissolubilmente. Questa non sarebbe quindi la "proposta 3", qui si parla effettivamente di "tutto o niente" e a me va proprio bene così. --Lepido (msg) 17:26, 15 giu 2013 (CEST)[rispondi]
sì, tra l altro uno puo sempre essere rieletto come admin con relativa procedura classica.--Lucas ✉
  • Favorevole con procedura di tacito assenso. --τino 032 [...] 17:33, 15 giu 2013 (CEST)[rispondi]
  • Favorevole --Paperoastro (msg) 18:48, 15 giu 2013 (CEST)[rispondi]
  • ok anche per me --Salvo da PALERMO 20:10, 16 giu 2013 (CEST)[rispondi]
  • Commento: (ancora) Propongo però di abbassare il numero minimo di voti contrari per far partire la votazione di riconferma per gli Admin/CU. Da 15 lo porterei addirittura a 5, anche meno, vista la delicatezza del ruolo. Ah, e viste le critiche con cui in passato sono state vite queste proposte, mi augurerei una partecipazione e un consenso nettamente maggiori...--DoppioM 23:46, 16 giu 2013 (CEST)[rispondi]
    Continuerei decisamente lasciandolo a 15 come in questa proposta: procedura unica senza distinzione (come data, la si sposta a quella di admin finché non sono tutte armonizzate). Se poi si decade per mancanza di fiducia, si decade da tutto: se si resta, si resta. Questo può aiutare anche a mitigare le tensioni. Il fatto poi che il consenso si cristallizzi in poco tempo è in realtà cosa abbastanza comune su wiki, dipende anche dal "come" si pone una questione. Se proprio si sente la necessità di un sondaggio si faccia pure, ma personalmente non lo vedo necessario, allo stato, mi pare una discussione ragionevole e "trasversale". :) --Lucas ✉ 06:16, 17 giu 2013 (CEST)[rispondi]
    Senza voler aggiungere troppa carne al barbecue, avanzo una proposta collaterale: così come il quorum per le elezioni è (giustamente) variabile al variare della partecipazione (un anno fa 65 circa, oggi meno di 50), forse potrebbe essere reso tale anche la soglia di pareri motivatamente contrari che danno avvio alle riconferme esplicite. --Nicolabel 09:21, 18 giu 2013 (CEST)[rispondi]
    idea molto interessante, ma la tratterei decisamente dopo aver portato a termine questa (segnati già il mio parere favorevole, cmq, anche se mi piacerebbe una bella discussione in proposito) :) --Lucas ✉ 17:32, 18 giu 2013 (CEST)[rispondi]
  • Favorevole alla riconferma tacita, ma mi astengo sull'accorpamento. --Horcrux92 10:27, 18 giu 2013 (CEST)[rispondi]
  • Favorevole. --Epìdosis 21:33, 18 giu 2013 (CEST)[rispondi]

quindi, come ci muoviamo? --Salvo da PALERMO 00:19, 19 giu 2013 (CEST)[rispondi]

attendiamo ancora un po' di favorevoli poi ci muoviamo (o con modifiche concrete sempre suscettibili di test/revert/ecc o con sondaggiazzo). --Lucas ✉ 09:22, 20 giu 2013 (CEST)[rispondi]
  • Favorevole all'accorpamento. --Superchilum(scrivimi) 10:32, 20 giu 2013 (CEST)[rispondi]
  • sulla conferma tacita Favorevole se si abbassa il numero di pareri richiesti per il passaggio alla votazione. Neutrale Neutrale sull'accorpamento, che in caso di conferma tacita (specie con diverso numero di pareri per il passaggio alla votazione) potrebbe essere solo una complicazione superflua. --Nicolabel 11:01, 20 giu 2013 (CEST)[rispondi]
  • Favorevole se si abbassa il numero (vista la maggior delicatezza del ruolo), mi astengo in caso contrario. CMQ credo anch'io dovremmmo passare in sondaggio...--Alkalin l'admIncasinato 12:44, 20 giu 2013 (CEST)[rispondi]
  • Favorevole Concordo anch'io sul sondaggio, l'esito direi che è scontato, tuttavia è bene comunque dare maggiore evidenza a questa proposta. --Ada-lin-gio 11:11, 25 giu 2013 (CEST)[rispondi]
  • d'accordo. Inoltre, (forse qui OT) pensavo che sarebbe utile individuare una data unica annuale per le procedure di riconferma (non ho statistiche ma credo che la percentuale di votazioni di riconferma sia molto ma molto bassa, mentre le altre sono giustamente (visto l'enorme lavoro fatto dagli admin) quasi automatiche. Una data unica, o semmai anche due all'anno, consentirebbe di dare il giusto rilievo nella comunità. Della cosa dove se ne potrebbe discutere? Grazie. --giuranus (msg) 15:43, 30 giu 2013 (CEST)[rispondi]
  • molto d'accordo per istituire una procedura unificata: rivotare tutti gli anni è una seccatura micidiale (ed evitabile). Auspico comunque che si passi da sondaggio. --Vale93b Fatti sentire! 01:25, 5 ago 2013 (CEST)[rispondi]

Segnalo che ho steso una prima bozza di sondaggio qui. Chiunque volesse darmi una mano a prepararlo può intervenire direttamente o partecipare alla discussione che avrà luogo qui. --Aplasia 17:38, 17 ago 2013 (CEST)[rispondi]

Estratto da "https://it.wikipedia.org/w/index.php?title=Wikipedia:Bar/Discussioni/Sistema_di_riconferma_CU&oldid=90047570"