Discussioni Wikipedia:Sondaggi/Accorpamento delle procedure di riconferma dei check user a quella degli amministratori

In seguito a questa discussione, ho steso una prima bozza di sondaggio in merito all'unificazione delle procedure di riconferma dei check user e degli amministratori. Chiunque volesse aiutarmi nella realizzazione della stesura definitiva e chiunque abbia osservazioni da portare è benvenuto! --Aplasia 17:41, 17 ago 2013 (CEST)

Ma il sondaggio è avviato? Perché se è una bozza ancora aperta alle modifiche mi pare che questo voto sia un po' prematuro. Nel dubbio, ho scritto due righe a Sergio e messo un avviso nella pagina, alla peggio la figuraccia la faccio io :) --Dry Martini confidati col barista 23:43, 17 ago 2013 (CEST)

Io avevo messo la cosa sul ridere, a parte che non si è nemmeno pubblicizzato un po' il sondaggio, né discusso da qualche parte della sua durata, ma è la prima volta che ne vedo uno "ferragostano" o quasi. --M/ 23:56, 17 ago 2013 (CEST)

Appunto, allora è decisamente meglio discuterne un po', visto che è stato esclusivamente pubblicizzato come bozza (discussione esterna al bar che punta a questa talk). --Dry Martini confidati col barista 00:00, 18 ago 2013 (CEST)

Mi pare che l'espressione "prima bozza" e il titolo del Bar "Preparazione del sondaggio..." lascino poco spazio ai dubbi... --CastaÑa 01:03, 18 ago 2013 (CEST)

Chiedo scusa, effettivamente le date che ho messo, del tutto indicative, lasciavano spazio a fraintendimenti. È appunto solamente una bozza su cui sicuramente abbiamo ancora molto da lavorare! --Aplasia 01:40, 18 ago 2013 (CEST)

Specchietto

Ho inserito uno specchietto per le motivazioni favorevoli e contrarie; se qualcuno volesse correggere, modificare o aggiungere è ovviamente libero di farlo! --Aplasia 12:10, 18 ago 2013 (CEST)

Ho apportato due piccoli fix formali allo specchietto. Dell'altra modifica che voglio proporre, più sostanziale, preferisco invece discutere qui: trovo che l'ultimo periodo del punto 2 dei contro, "non si vedono quindi motivi per modificare tale consenso", esprima un punto di vista, piuttosto che riportare asetticamente le posizioni. Questo, ovviamente, al di là delle intenzioni di Aplasia (che a proposito ringrazio per il lavoraccio di predisposizione di questa bozza). Proporrei di cassarlo, visto che comunque il concetto è chiaro--Formica rufa 17:53, 18 ago 2013 (CEST)

Non ho obiezioni in merito, quindi per me si può anche togliere; anzi, vi invito a non farvi problemi nell'essere "crudeli" nei miei confronti, a favore di una presentazione più asettica possibile della questione! --Aplasia 18:03, 18 ago 2013 (CEST)

un momento...

scusate un secondo: si propone una modifica di procedura per sburocratizzare e snellire le procedure medesime (e anche io sono favorevolissimo), e per far questo facciamo addirittura un sondaggio, cioè un'altra procedura, in una situazione che, se non è in unanimità di consenso (ci sono al massimo degli astenuti, o forse si dovrebbe dire indifferenti), è almeno in assenza di obiezioni o di qualsiasi segno di contrarietà??? La discussione è stata formalizzata da Lucas a giugno, che non era periodo di vacanze; vedete per caso voi (io non lo vedo) che in tre mesi qualcuno abbia detto "giammai", "ma anche no", "manco pagato", "solo ogni tanto", "se cade di venerdì", o qualcosa di simile? :-)
A quel che leggo c'è pieno consenso, salvo che non arrivi qualche riflessione realmente significativa. Per la precisione, non saremo tutti entusiasti, ma non si vede nessuno contrario, per cui non ci sono ragioni per non attuarla il prima possibile, se davvero si ritiene che sia una proposta migliorativa. Il sondaggio è per situazioni in cui ci sono da fare scelte alternative con motivazioni più cospicue sia pro che contro, non dove il massimo della contrarietà è l'indifferenza. Copincollo da WP:URNE: «In linea generale, solo le controversie che si trascinano da tempo dovrebbero essere sottoposte a un sondaggio o votazione.» In che consiste l'attuale controversia, che chi ha un'opinione ce l'ha favorevole?
Siamo pratici, su: al 10 di settembre, quando per scrupolo siamo sicuri che sono tornati tutti, se non vengono fuori obiezioni ragionevoli diventa policy. E, imho, la promulga Aplasia ;-) -- g · ℵ (msg) 17:59, 18 ago 2013 (CEST)

Personalmente ero già favorevole a promulgare la policy senza passare tramite sondaggio; ma, visto che molti dei favorevoli hanno richiesto di passare attraverso sondaggio data la delicatezza del ruolo di check user e visto che la questione si trascina da anni senza si sia mai riusciti ad arrivare a una conclusione definitiva, ho optato per la preparazione del sondaggio, se non altro per porre un termine definitivo alla questione. Ovviamente se si ritiene che si possa soprassedere al sondaggio non posso che essere favorevole. --Aplasia 18:23, 18 ago 2013 (CEST)

A livello wikigiuridico il sondaggio non serve, perché la policy attuale non è frutto di sondaggio (almeno, io nell'archivio non ho trovato nulla di simile). Qualche perplessità c'era, ma in effetti il sondaggio sembra un avvitamento burocratico... --Dry Martini confidati col barista 20:18, 18 ago 2013 (CEST)

IMHO per sicurezza è meglio passare per il sondaggio.--John95^(posta) 09:27, 19 ago 2013 (CEST)

Anche secondo me, invece, il sondaggio non è necessario--Formica rufa 09:29, 19 ago 2013 (CEST)

Concordo con Formica rufa e Dry Martini, il sondaggio non è tecnicamente necessario (si sta modificando qualcosa che non era stato deciso per sondaggio) e costituirebbe solo un inutile passaggio in più (avvitamento burocratico).--L736E^{l'adminalcolico} 11:30, 22 ago 2013 (CEST)

Questa discussione viene dopo un'altra discussione, che a sua volta si basava su altre discussioni protrattesi nel corso degli anni. L'impressione è che si voglia cambiare la regola e che tutti siano d'accordo, ma che vista la delicatezza della cosa si abbia quasi il timore di farlo. Secondo me ha ragione Gianfranco: sarebbe meglio aspettare che tutti fossero ritornati dalle vacanze per cambiare direttamente la regola. Purtroppo però temo che questo sarebbe un altro modo per rimandare e poi non fare per l'ennesima volta niente, ecco perché mi può andare bene l'idea del sondaggio: non è impegnativo per nessuno (quindi fattibile senza problemi) e alla sua fine il cambiamento sarà praticamente "obbligatorio". Forse vi sembrerà una considerazione un po' amara, ma ragazzi io sono vecchio e prima di morire vorrei vedere finalmente la regola cambiata :-) --Lepido (msg) 14:27, 22 ago 2013 (CEST)

Al momento direi che per il 10 di settembre, orario da definire secondo le condizioni climatiche, è in programma che la regola sia cambiata, salvo che nel frattempo non giunga qualcuno a spiegarci convincentemente che stiamo facendo una fesseria, e non credo verrà :-) Anche io non sono più un ragazzino, ahimé, quindi terremo duro insieme sino al 10; e imho non sarebbe disdicevole, per altre cose, se seguitassimo a tener duro anche per altri cent'anni ;-) -- g · ℵ (msg) 23:42, 23 ago 2013 (CEST)

Domanda

Scusate, se in caso molto raro un admin-CU venisse sfiduciato solo come CU. Si potrà sempre aprire una propcedura di revoca del CU. Oppure bisognerà voltarli contro in sede di riconferma come admin?--John95^(posta) 09:34, 19 ago 2013 (CEST)

Secondo anche quanto risulta dalla discussione che c'è stata, i due incarichi sono legati tra loro. Se si viene sfiduciati per uno dei due, si decade automaticamente anche per l'altro. Tutto questo è riportato nel punto 2 dello specchietto riassuntivo che ha fatto Aplasia (lato verde) --Lepido (msg) 10:21, 19 ago 2013 (CEST)

Attuazione modifiche alla procedura il 10 settembre 2013

Per tutto quanto convenuto in precedenza, dal 10 settembre 2013, salvo ragionevoli obiezioni che in questi giorni diano buon motivo per non farlo, si applicherà l'accorpamento delle procedure.
Come da specchietto preparato da Aplasia,

«la fiducia della comunità per i due ruoli tecnici diventa unica, e ogni abuso commesso in uno dei due ruoli che la faccia diminuire diventa automaticamente motivo di sfiducia per l'altro ruolo, nonostante questi siano distinti pur essendo entrambi molto delicati. In ogni caso rimane di base il consenso sul fatto che un sysop sfiduciato non possa continuare a fare il check user.»

In conseguenza, la modifica implica che

«la procedura di riconferma nel ruolo di check user sia accorpata a quella dello stesso utente come amministratore, con lo stesso numero di voti contrari per avviare una votazione di riconferma (15) e con lo stesso quorum (2/3), in modo che la comunità si esprima contemporaneamente in merito a entrambi i ruoli tecnici e che la riconferma in entrambi i ruoli sia tacita fintanto che non si avvii una votazione secondo le attuali regole per la riconferma degli amministratori.»

La discussione è stata lunga e di tanto in tanto richiamata al bar, la pubblicizzazione sufficiente, la data è stata scelta per consentire il rientro del maggior numero di utenti, viste le assenze per ferie estive. Come per tutte le modifiche procedurali, segnaliamo per favore prontamente i possibili problemi tecnici, collaterali e di dettaglio. -- g · ℵ (msg) 11:32, 29 ago 2013 (CEST)

+1 --Roberto Segnali all'Indiano 11:58, 29 ago 2013 (CEST)

Praticamente "Simul stabunt vel simul cadent". Beh, è bene che si parta dal 10 settembre ché scegliere l'11 sarebbe stato di cattivo gusto...

La modifica di Aplasia andrebbe IMHO integrata con un aspetto: se in ipotesi un amministratore che sia stato eletto o riconfermato ad agosto 2013 fosse eletto check-user a settembre 2013 (giugno 2014), la riconferma successiva, unica per entrambi i ruoli, si terrebbe ad agosto 2014 oppure a settembre 2014 (giugno 2015)? In altri termini, l'elezione a CU costituisce un'implicita riconferma anticipata nella funzione di sysop? (m2c: sì) --Nicolabel 12:28, 29 ago 2013 (CEST)

direi di sì, essere sysop è condizione del diventare CU, è una riconferma implicita; se intendevi che la riconferma "cumulativa" si sposta al settembre del tuo esempio, penso conseguentemente di sì. -- g · ℵ (msg) 12:40, 29 ago 2013 (CEST)

Leggermente OT - piccolo dubbio, rimane possibile dimettersi da check user senza doversi dimettere da admin, no? --Cruccone (msg) 13:07, 29 ago 2013 (CEST)

penso proprio di sì, proprio per il tipo di funzione e ciò che comporta di diverso; ad es, il sysop non si identifica in WMF, per dirne una -- g · ℵ (msg) 13:10, 29 ago 2013 (CEST)

Quindi, prendendo come esempio pratico il mio caso, dove la riconferma come sysop dovrebbe avvenire il 15 novembre 2013 e come CU il 6 dicembre 2013, quale delle due date si prenderà? IMO sarebbe più corretto, per la prima riconferma (dato che poi saranno sempre unificate), scegliere la prima data temporalmente utile (ossia novembre nel caso del mio esempio), indipendentemente dal tipo di "flag" a cui essa si riferisce.--L736E^{l'adminalcolico} 16:32, 29 ago 2013 (CEST)

Per i check user già attivi non riterrei opportuna la retroattività, dal momento che quando abbiamo votato le ultime volte lo si faceva esplicitamente per il ruolo di check user: per loro direi che quindi la prossima riconferma debba rimanere a un anno dall'ultima riconferma da sysop (nel caso di L736E, ad esempio, il 15 novembre p.v.). Per le elezioni future possiamo decidere in entrambi i modi. Personalmente ritengo la proposta di Nicolabel del tutto lecita; ciò che basta fare è aggiungere una postilla in Wikipedia:Check user/Elezioni che tale votazione vale, in caso di risultato positivo, come conferma della fiducia nel ruolo di sysop dell'utente, e che la successiva riconferma avverrà a partire da un anno dal termine della votazione. Non vale ovviamente il contrario, ovvero come votazione sulla sfiducia di un sysop, dal momento che questa viene valutata in modo diverso e con quorum e voti minimi contrari diversi. --Aplasia 16:56, 29 ago 2013 (CEST)

Ah, sono ovviamente favorevole all'entrata in vigore della modifica della policy dal 10 settembre p.v., a meno di valide e motivate obiezioni. --Aplasia 17:01, 29 ago 2013 (CEST)

Giusto, ho dimenticato di dire che sono favorevole anche io sia alla riconferma unificata che sulla data del 10 settembre.--L736E^{l'adminalcolico} 19:22, 29 ago 2013 (CEST)

Favorevole a tutto, inclusa la postilla di Nicolabel. Sulla norma transitoria: io sceglierei la prima data utile per riconfermare entrambi gli incarichi, ma in fin dei conti poco cambia--Formica rufa 21:09, 29 ago 2013 (CEST)

[← Rientro] Favorevole all'unione delle procedure. Riguardo la proposta di Nicolabel: io prenderei la prima data utile in ogni caso... forse è ipergarantismo, ma in fondo succede al massimo una volta nella carriera di ogni CU, per cui non è un fastidio eccessivo. --Dry Martini confidati col barista 12:53, 30 ago 2013 (CEST)

Favorevole anch'io alla norma e alla scelta di prendere in considerazione la prima data utile per i CU già eletti. Restu²⁰ 16:03, 30 ago 2013 (CEST)

Commento: Non mi pare improbabile che ad una riconferma si voglia sfiduciare un utente da CU ma non da admin. Trattandosi di due ruoli comunque diversissimi, un utente può rivelarsi inadatto a fare il CU pur restando un admin passabile... Si sta pensando ad una ipotesi del genere? --pequod ^..Ħƕ 03:30, 31 ago 2013 (CEST)

Potresti fare un esempio concreto? Perché da quello che ho sempre visto, il deflag viene richiesto quando viene meno la "fiducia" verso l'utente, intesa nella più ampia accezione possibile: fiducia nelle sue capacità, nella sua imparzialità, nella sua correttezza, ecc. Quando potrebbe avvenire secondo te che la mancata "fiducia" verso il CU non farebbe decadere la "fiducia" verso l'admin? --Lepido (msg) 04:34, 31 ago 2013 (CEST)

In seguito a quali eventi un CU perde la fiducia? A occhio e croce quando abusa delle sue funzioni specifiche (altre violazioni più generiche minano direttamente la fiducia come admin). Ma un utente che viola la mia privacy (abuso delle funzioni di CU, per l'appunto) non avrà mai la mia fiducia come amministratore. Ergo, secondo me, il tipo di eventi che possono portare alla sfiducia di un CU fanno cadere anche l'idoneità al ruolo di amministratore. Questo mi pare si applichi sia alle votazioni iniziate da una UP sia a quelle partite da una riconferma tacita. --Dry Martini confidati col barista 09:58, 31 ago 2013 (CEST)

Anche per il caso che si volesse sfiduciare un CU perché sia pure in buona fede interpreta male i suoi risultati e fa perciò errori diciamo tecnici, sarebbero errori estremamente gravi per portata, ma relativamente "ordinari" a paragone di ciò che di solito l'admin è chiamato ad analizzare; quindi anche per me la sfiducia per CU è anche sfiducia per admin. La fortuna è che siamo mille miglia lontani dal doverci porre questo problema, è solo raffinato esercizio di teoria :-) -- g · ℵ (msg) 11:46, 31 ago 2013 (CEST)

Ok, adesso ci si è pensato. ;) Per me non ci sono problemi, va bene come dite. --pequod ^..Ħƕ 12:24, 31 ago 2013 (CEST)

Innanzitutto Favorevole da sempre :D

In pratica diventerebbe come per i burocrati, giusto?

Ah, due annotazioni. Ricordiamoci di specificare le note transitorie (eliminare dal 10 settembre le riconferme CU, aspettare per i vecchi la prossima da admin, per i nuovi ogni anno da quella da CU, giusto?) e anche che, in caso di inattività come CU, la decadenza "automatica" si applica comunque solo ai tastini da CU (il caso opposto non esiste, in quanto per decadere da admin si sarebbe decaduti da CU mesi prima, e in ogni caso deflaggherebbe completamente l'utente)--DoppioM 23:57, 1 set 2013 (CEST)

Spero sia considerabile "buon motivo" che il compito, i poteri, la discrezionalità e le informazioni a cui hanno accesso gli utenti check user sono tali, importanti e delicati che sarebbe bene vi fossero controlli più attenti, informati, accurati e più frequenti. Invece di andare in tal senso, al contrario questa proposta se è vero che non altera frequenza e altre modalità (quindi purtroppo non migliora come invece sarebbe auspicabile), rende la riconferma ancor meno evidente e cosciente mischiandole assieme a tutte le "normali" riconferme di amministratore e marginalizzando la riconferma di CU a un aspetto della riconferma di questi (quindi peggiora).

p.s. ma, visto che questa discussione è in questa pagina, s'intende fare un sondaggio?

p.s.2: se ben ricordo la riconferma dei CU all'inizio non esisteva, semplicemente al termine del mandato tale delicato compito veniva assegnato a altri. Poi, non ricordo con quante e quali discussioni e quante e quali valutazioni sulla delicatezza della cosa (forse al contrario si è pensato semplicemente a una dimenticanza, che non si era previsto la riconferma come per gli altri casi) si è attivata la riconferma. --79.16.147.38 (msg) 23:35, 8 set 2013 (CEST)

non ho mai letto che qualcuno proponesse di fare controlli sui CU, tantomeno che se ne facessero di "più attenti", visto che non ci sono affatto controlli. Ci sono riconferme, che sono un'altro genere di procedura. Quanto a questo, non credo proprio che l'accorpamento sia una marginalizzazione, penso invece che, diversamente da ora, di qui in avanti ci potrà essere tutto "il pubblico delle grandi occasioni", e perciò le riconferme saranno più partecipate. Mi piace infine sottolineare che i CU sono utenti di massima fiducia selezionati fra utenti già di massima fiducia, dunque nel valutare la "delicatezza della cosa", vorrei ricordassimo tutti che non stiamo parlando di pendagli da forca ed è bene non dar l'impressione che qualcuno pensi lo siano. Grazie. Ciò nel senso che la gravità della materia l'abbiamo ben presente al momento della nomina e ad ogni riconferma. Prova ne è che abbiamo utenti davvero straordinari, nominati a questo ruolo (fatevi un giretto su altri wiki anche famosi e vi renderete facilmente conto che siamo molto ma molto fortunati).

ps1: no, con un consenso come questo sarebbe grave fare un sondaggio.

ps2: o era una domanda sulla storia della riconferma CU, o non ho saputo cogliere il senso del richiamo, scusami -- g · ℵ (msg) 00:14, 9 set 2013 (CEST)

Per rispondere anch'io all'IP, tanto marginali erano le riconferme dei CU che ci si dimenticava di attivarle. Sono d'accordo con g: appunto accorpandole a quelle che intervengono per il ruolo di sysop si mettono in evidenza le riconferme a CU.

Sui sondaggi ho un'idea un po' diversa, nel senso che occasionalmente essi servono anche a "sigillare" un consenso per altri versi abbastanza evidente (evitando ovviamente la clausola della palla di neve). Ovviamente non mi scandalizzo se lo evitassimo in questa occasione, perché è un'operazione che ci sembra di buonsenso. In concreto non abbiamo assolutamente problemi con i CU attuali di it.wiki, per cui imho risulta molto da HCUA il controllo spessorato auspicato dall'IP. --pequod ^..Ħƕ 07:32, 9 set 2013 (CEST)

Applicazione della nuova procedura

Essendo oggi il 10 settembre, come concordato e soprattutto convenuto, non essendosi manifestate ragioni ostanti, le nuove procedure sono applicate per effetto di specifico consenso. Buon lavoro a tutti gli admin e ai CU :-) -- g · ℵ (msg) 18:09, 10 set 2013 (CEST)