Discussioni Wikipedia:Quando sono revocate le funzioni di amministratore/Archivio6

message: In linea con le varie modifiche fatte in questi anni, propongo di spostare questa pagina al titolo corretto "Quando viene revocato lo status di amministratore", quella di amministratore infatti non è una carica (così come non è una carica essere "utenti autoverificati", "utenti autoverificati", ecc.), si tratta semplicemente di uno dei livelli di accesso degli utenti. --Lucas  ✉  23:23, 25 dic 2013 (CET)
replies: text: se capisco lo spirito, si vuole evitare che il riferimento al flag sia evidenza di un equivocabile diverso trattamento degli utenti che ce l'hanno; ma se questo è l'intento, mi sa che parlare di "status" potrebbe essere peggio :-) Suggerirei di restare al tecnico, ad esempio "quando sono revocati i permessi di amministratore", o "le abilitazioni", così che il focus sia appunto sul tipo tecnico di accesso, più vicino al MediaWiki che non alle polemiche. (cmq, a fini interni non vedo negativamente che possa essere inteso come "carica", termine che ricorda un riferimento generico e generale alla fiducia ricevuta, anche se ho chiaro appunto che potrebbe equivocarsi ;-) -- g · ℵ (msg) 00:52, 26 dic 2013 (CET)
replies: text: dato che WP:A parla di "funzioni"/"funzione", si potrebbe titolare la pagina con "Quando vengono revocate le funzioni di amministratore", "Quando viene revocata la funzione di amministratore" o varianti analoghe. --valepert 08:14, 26 dic 2013 (CET)
replies: text: Meglio in effetti "permessi" (o in subordine "funzioni") come suggerito. --MarcoK ***auguri*** (msg) 11:02, 26 dic 2013 (CET)
replies: text: D'accordo con g e MarcoK, forse la parola più leggera semanticamente sarebbe "strumenti", come compare nel menu a tendina a destra. - --Klaudio (parla) BUONE FESTE 11:46, 26 dic 2013 (CET)
replies: text: Esattamente come MarcoK. --93.65.127.52 (msg) 15:00, 26 dic 2013 (CET)
replies: text: Mi convince! Personalmente userei funzioni, mi pare più "elegante" e fa anche riferimento ai compiti più in generale, non solo agli "strumenti" in sé (i tastini). --Lucas  ✉  08:57, 27 dic 2013 (CET)
replies: text: Per me OK allo spostamento a Wikipedia:Quando vengono revocate le funzioni di amministratore. Sanremofilo (msg) 01:37, 28 dic 2013 (CET)
replies: text: Non si potrebbe unire a WP:A? --Vito (msg) 01:43, 28 dic 2013 (CET)
replies: text: La penso come Vito purché si alleggerisca WP:A, ad esempio scorporando la lista degli amministratori attuali e passati. Tra tutti i termini proposti preferisco quello di "funzioni" (tra l'altro "permessi" è gergo tecnico e si presta ad equivoci). --Nicolabel 01:53, 28 dic 2013 (CET)
replies: text: favorevole a proposta Vito + emendamento Nicolabel :-) -- g · ℵ (msg) 01:56, 28 dic 2013 (CET)
replies: text: In effetti non è così utile avere una pagina a sé, ma quella è già lunghetta... Sanremofilo (msg) 02:04, 28 dic 2013 (CET)
replies: text: Lista esclusa quella è 20kb, questa 5, fuse assieme sarebbero sui 23-24, con un po' di lavoro si può pure scendere a 21-22, sempre lista esclusa. --Vito (msg) 16:54, 28 dic 2013 (CET)
thread_title: Cambio titolo

message: Con il recente sondaggio che ha unificato la riconferma da amministratore e da CU si è stabilita la contemporanea decadenza da entrambi i ruoli qualora venga meno la fiducia comunitaria anche solo in uno dei due. 
Ma se, per ipotesi, un admin del quale la comunità abbia piena fiducia si candidasse a CU (o a burocrate) e non venisse eletto - per un qualunque motivo, ad esempio per ragioni che riguardano strettamente la perizia tecnica e non la fiducia - decadrebbe anche da amministratore? Questa fattispecie non è stata prevista: IMHO è opportuno rimuovere ogni dubbio ora che si tratta di una circostanza ipotetica (e a candidarmi io non ci penso proprio!). --Nicolabel 20:10, 17 mar 2014 (CET)
replies: text: Direi di no, una mancata riconferma è diversa da una mancata elezione ;)--DoppioM 22:24, 17 mar 2014 (CET)
replies: text: Lo credo anch'io. Però è bene confrontarci prima che la circostanza capiti. --Nicolabel 23:26, 17 mar 2014 (CET)
replies: text: Sinceramente mi pare che il dubbio non esista :D --Jaqen [...] 16:01, 19 mar 2014 (CET)

text: Considerando che si tratta di due funzionalità diverse, non ritengo che si debba avere una decadenza automatica, naturalmente, se nel corso della votazione a CU o burocrate vengono fuori motivazioni tali da giustificare una procedura di rimozione della funzionalità da admin il discorso cambia (però è necessario aprire una procedura separata). - --Klaudio (parla)  18:21, 19 mar 2014 (CET)
replies: text: Anche per me, la mancata elezione non coduce alla perdita dell'altra carica. --Harlock81 (msg) 11:17, 21 mar 2014 (CET)
thread_title:  E se un admin non viene eletto CU (o burocrate)? 

message: Nel valutare la decadenza per inattività di un amministratore si considerano le funzioni che compaiono nel log: cancellazioni (e recuperi) di pagine o di loro singole versioni, protezioni di pagine, blocchi di utenti ed IP, modifiche nell'assegnazione dei "diritti" delle utenze, importazione da altri progetti e - si era detto - modifiche delle pagine MediaWiki. Tutte, tranne quest'ultime, compaiono nel quadro riepilogativo delle statistiche sugli amministratori di it.wiki, che viene utilizzato comunemente come un primo indicatore dell'attività dei sysop.
Alcune funzioni che erano prerogative degli amministratori (come ad esempio il rollback) non sono più tali e conseguentemente non sono considerate nel rilevare l'attività del sysop. La questione non è peregrina perché Sbisolo ora (e Kal-El prima di lui) decadrebbe dal ruolo di admin se non si tiene conto dei rollback eseguiti. Questa interpretazione è corretta? Nel caso, andrebbe chiarita anche nelle policy. --Harlock81 (msg) 21:57, 30 nov 2015 (CET)
replies: text: Quello che hai linkato è un tool scritto da qualcuno che ha scelto cosa inserire e cosa no. Quelle che generalmente vengono considerate le azioni da admin sono solo una piccola parte del totale (Speciale:ElencoPermessiGruppi). --Buggia 23:09, 30 nov 2015 (CET)
replies: text: I rollback sono prerogativa anche di un altro gruppo, i rollbacker appunto, quindi non mi sembrano "azioni da admin" e pertanto non le considererei valide. --Superchilum(scrivimi) 10:20, 1 dic 2015 (CET)
replies: text: A leggere la policy il rollback non va escluso, dato che è elencato fra le funzioni a cui si fa riferimento nella sezione Decadenza per inattività. --Jaqen [...] 11:11, 1 dic 2015 (CET)
replies: text: D'accordo con Jaquen, il dettaglio delle funzioni lo prevede. Il rollback non è un'esclusiva degli amministratori, ma è una loro funzione che può essere delegata ad altri (i rollbacker). --Bradipo Lento (msg) 11:26, 1 dic 2015 (CET)
replies: text: IMHO è solo un difetto d'aggiornamento. Francamente non si può sostenere che un admin non debba decadere se fa un'azione che anche un non-admin può fare. Poi, se vogliamo, ragioniamo sulla decadenza automatica. Ma IMHO finché c'è va applicata alle azioni proprie degli admin (gli edit MediaWiki, per esempio, per andare oltre l'elenco indicato da Harlock, e qualunque altra azione che solo un amministratore può fare)--Formica rufa 12:27, 1 dic 2015 (CET)
replies: text: Esatto, è quello che intendevo: "azioni che solo un amministratore può fare". Ad esempio anche spostare un file se non erro non rientra in questa casistica, esistendo i file mover. --Superchilum(scrivimi) 12:31, 1 dic 2015 (CET)
replies: text: Secondo me dobbiamo decidere se la regola va applicata rigidamente o no: perché se va applicata rigidamente allora è funzione admin tutto quello che è elencato fra le funzioni admin; se invece decidiamo che non vanno applicate rigidamente -nel senso che alcune cose non vanno considerate- allora possiamo diventare meno rigidi anche sui 6 mesi e tenere buone azioni effettuate anche qualche giorno dopo. --Jaqen [...] 12:53, 1 dic 2015 (CET)
replies: text: La regola che è stata applicata fino ad ora considerava solo le azioni esclusive dell'admin. Se c'è da modificare, o specificare meglio ciò che non appare chiaro, naturalmente dovrà valere solo dal momento in cui si decide in avanti, ma non per sanare situazioni già passate. --Euphydryas (msg) 14:37, 1 dic 2015 (CET)
replies: text: Io sono sempre per riconfermare chi non è molto attivo, ma non è giusto cambiare le regole ora, malgrado si sia fatto sempre in un altro modo. --Vito (msg) 14:59, 1 dic 2015 (CET)
replies: text: Ma secondo me il problema è l'opposto, è la "regola" applicata finora ad essere in contrasto con quello che sta scritto qui.--Eustace Bagge (msg) 15:19, 1 dic 2015 (CET)
replies: text: La regola è ciò che è scritto ora: "non effettuare alcuna operazione propria della funzione", e come è scritto fin dal 2008: "nessuna operazione da amministratore". E' dal 2010 che il rollback non è più una operazione propria "da amministratore". --Euphydryas (msg) 15:39, 1 dic 2015 (CET)
replies: text:  [conflittato] − Anche secondo me. La sezione "funzioni proprie" difetta di molte funzioni (alcune usate molto di rado, so bene); vi è altresì il problema che molte di queste azioni non lasciano traccia nei registri e quindi non è possibile controllare se sono state effettuate.Non è la prima volta che ci mettiamo a discutere su cosa considerare o meno, tant'è che per un utente non venne considerato bastante un suppressredirect e i permessi furono rimossi. --Buggia 15:47, 1 dic 2015 (CET)
replies: text: Beh, certo un admin per esempio può anche leggere una pagina cancellata, ma come facciamo a controllarlo? andiamo sulla fiducia? Il tool che si usa ci dà dei dati verificabili, su ben determinate azioni, e c'è quindi uniformità e certezza di uguale valutazione per tutti. --Euphydryas (msg) 15:57, 1 dic 2015 (CET)
replies: text: Certamente, consideriamo solo quelli che hanno un log. Ci sono quindi anche filtri, etichette, importazioni e unioni che non sono citati esplicitamente. Non li consideriamo? --Buggia 16:15, 1 dic 2015 (CET)

text: Il "dettaglio delle funzioni" prevede anche autopatrol, ma non mi pare che questa sia considerata una funzione da sysop. --Horcrux九十二 22:58, 1 dic 2015 (CET)
replies: text: Come il Carica file, che è indicato per gli admin ma anche per gli utenti autoconvalidati e gli utenti confermati. --Euphydryas (msg) 23:25, 1 dic 2015 (CET)
replies: text:  concordo con l'interpretazione di Formica Rufa e Euphydryas --Gregorovius (Dite pure) 23:42, 1 dic 2015 (CET)
replies: text:  I miei due cent. Se si considera funzione propria degli admin una funzione che hanno loro e solo loro, escludendo quelle condivise con altri gruppi, si arriverebbe a risultati paradossali. Già infatti si dovrebbe togliere il supressredirect e il movefile perché ce l'hanno il gruppo dei mover. Se un giorno venisse creato un numero di gruppi in cui ogni funzione propria degli admin venisse condivisa, allora gli admin non potrebbero più esistere? Se fanno uno spostamento sopprimendo il redirect, fanno qualcosa che può fare un mover, se fanno un rollback fanno qualcosa che può fare un rollbacker, se eseguono un blocco fanno un qualcosa che probabilmente sarà in futuro prerogativa del gruppo blocker. Ma si dimentica qualcosa: un admin assume in sé tutte queste funzioni. Un utente autoconvalidato non ne ha nessuna di queste, un rollbacker ha solo il rollback, il mover ha solo il movefile e il suppressredirect (a proposito, il suppressredirect lo hanno da sempre anche i bot, per caso c'è qualche admin decaduto in quanto le uniche azioni admin erano spostamenti con soppressione del redirect?). L'admin ha una serie di azioni che può esercitare tutte, anche contemporaneamente, come prerogativa propria della sua funzione (che non può fare il rollbacker, o il mover, o l'ipotetico futuro gruppo dei blocker, che ne possono esercitare solo quelle proprie del loro gruppo, e non le altre), quindi, se la esegue (a prescindere che esistano altri gruppi che ne condividano una parte), esegue un'azione admin. --IndyJr (Tracce nella foresta) 00:34, 2 dic 2015 (CET)
replies: text: È pur vero che se in sei mesi usa solo il suppressredirect forse tutto sto bisogno delle altre funzioni da amministratore non ce l'ha (e magari, come succede a me dopo appena due mesi di assenza, ha pure perso la confidenza nell'irrogare blocchi, o non è aggiornato su una qualche variazione delle regole sulle cancellazioni immediate) e può, una volta decaduto, chiedere l'assegnazione dei flag che più si adattano ai suoi bisogni attuali. Come scritto da altri e altrove, dobbiamo toglierci dalla testa che perdere il flag sia come perdere una mano. Al massimo glie la tengo in fresca io, tanto tra 3 mesi può già ritornare. Piuttosto troviamo un modo per tenere traccia di tutte le modifiche riservate agli amministratori non rintracciate dallo strumento attuale: decidere se chiudere una PdC o mandarla a votazione è una decisione difficilissima e da apprezzare, eppure nessuno va mai a guardare quante votazioni ha aperto un admin negli ultimi 6 mesi. Ci vorrebbe un modo per aggregare le cronologie dei FiltriAntiAbusi e verificare se un utente li ha modificati recentemente. Alcune di queste potrebbero essere affidate a un Bot, o forse si può impostare un tool migliore... --Dry Martini confidati col barista 01:03, 2 dic 2015 (CET)
replies: text: Secondo me, piuttosto che ragionare sulle funzioni che sono condivise con altri gruppi, conviene continuare a fare come è stato fatto finora per una questione di comodità nel controllo, magari esplicitandolo nella linea guida. Del resto un amministratore che in sei mesi fa qualche rollback, evidentemente non ha più bisogno delle abilitazioni. Se invece ci mettessimo a considerare tutte le possibili azioni amministrative, come ad esempio l'apertura di una votazione in una PdC o un contributo in una pagina completamente protetta, non oso immaginare le ricerche che ci sarebbero da fare e il tempo che si perderebbe per capire se un amministratore è da considerarsi decaduto oppure no. Francamente mi sembra solo un inutile avvitamento burocratico. --Fullerene (msg) 03:58, 2 dic 2015 (CET)
replies: text: Dopo aver letto le considerazioni successive al mio intervento, mi rendo conto che si è trattato di un parere espresso sulla base di una rigida lettura delle funzioni proprie dell'amministratore. Fullerene ha indicato alcune operazioni che attualmente non sono elencate né facilmente rintracciabili, ma comunque importanti. All'atto pratico conviene, per evitare grosse perdite di tempo, continuare a basarsi sui dati forniti dal tool che individua le azioni amministrative. Potrebbe essere un'idea quella di modificare la pagina dei criteri di revoca per inattività indicando le funzioni amministrative "pure" (blocchi pagine e utenze, cancellazioni pagine e file, oscuramento cronologie, interventi sul filtro anti abusi...) per maggiore chiarezza? --Bradipo Lento (msg) 08:37, 2 dic 2015 (CET)
replies: text: Le modifiche dei filtri sono già incluse nel normalissimo log, visibile facilmente cliccando su "registri" nella colonna strumenti: esempio: è il log che si consulta come ulteriore verifica prima di chiedere un deflag per inattività, oltre alle modifiche in  Mediawiki, che invece si devono andare a rintracciare dai contributi, selezionando quel namespace. --Euphydryas (msg) 09:58, 2 dic 2015 (CET)
replies: text: Ah giusto, grazie! Sulla questione più generale, in realtà l'intervento di Fullerene tocca un tasto, cioè quello di non burocratizzare troppo. D'altra parte sarebbe una distorsione sciocca dire che "alcune azioni da amministratore [il rollback, lo spostamento di file, ecc li do per esclusi, non ripeto quanto argomentato sopra] sono più importanti di altre". E del resto il tool attuale fornisce già una grossa scrematura (che potrebbe essere ancora maggiore se includessimo tutti le azioni da log): chiaramente se ci fosse qualche admin che ha una fila di zeri in quella tabella bisognerebbe poi andare a controllare i contributi, che è un po' una rottura. Una risposta potrebbe essere automatizzare di più la verifica dell'inattività, per rendere meno dispendioso l'accertamento della verità :) --Dry Martini confidati col barista 10:22, 2 dic 2015 (CET)

text: Concordo con Pap3rinik, ed in effetti la decadenza automatica ha portato a risultati paradossali. Del resto per quale motivo non dovrebbero essere usati i tastini, se li si ha, quando sono necessarie azioni urgenti a protezione dell'enciclopedia, ad esempio bloccare un vandalo notturno se si è l'unico admin in giro (e capita)? Invece della decadenza automatica si potrebbe proporre la decadenza come non riconferma per inattività per consenso: se al momento della riconferma annuale l'admin non ha fatto azioni nell'ultimo anno (quindi aumentare da sei mesi ad un anno la finestra di inattività admin) in fase di riconferma, senza passare per alcuna votazione ma solo per consenso motivato, si può decidere di richiedere il deflag per quell'admin. Così si evita la rigida applicazione di quali azioni considerare e quali no, e l'admin comunque può continuare a fare le azioni finché ha i tastini, non saranno quell'unica o quelle due azioni in fotofinish a cambiare la situazione. --IndyJr (Tracce nella foresta) 21:41, 2 dic 2015 (CET)
replies: text: Piano: le situazioni più brutte ci sono state quando l'admin ha (magari in buona fede, eh) fatto qualche azione amministrativa a pochi [giorni, ore] dalla scadenza dei sei mesi. Allungare a un anno mica impedisce che queste cose si verifichino (sono comunque le azioni attorno alla scadenza che fanno storcere il naso), solo che l'aggiunta di un elemento di consenso creerà (basta andare a vedere qualche riconferma cascata vicino al sesto mese di inattività) inutili frizioni e discussioni attorno a una questione che veramente non è così vitale. La regola secca, se ben definita e applicata con uniformità (ma senza flessibilità, se no definirla bene non serve a niente e si perde tempo in contestazioni che entro 3 mesi potrebbero essere perfettamente inutili per l'avvenuta rielezione dell'utente) serve a perfezione come piccolo ed economico (in termini di discussioni e blister di tranquillanti) incentivo ad avere amministratori ragionevolmente attivi e aggiornati su quel che succede in it.wiki. Ulteriori sovrastrutture e processi decisionali sarebbero un'inutile avvitamento burocratico, a mio avviso. Su quali azioni considerare e quali no: conveniamo che se in sei mesi uso solo il rollback potrebbero sostituirmi il flag mentre dormo (togliermi l'admin e darmi il rollbacker) e non mi accorgerei di niente? E allora, visto che tra l'altro tenere conto di un log in più o in meno non genera complicazioni burocratiche (tanto fa tutto il tool), perché attaccarsi così strenuamente a queste funzioni? Come si faceva notare sopra: il flag di amministratore include anche la facoltà di spostare le pagine e segnare le modifiche altrui come verificate (roba da autoconvalidati: 4 giorni e 10 edit all'attivo), entrambe rientranti nella definizione generale del ruolo di amministratore, l'una perché riconducibile a fare "manutenzione" tra le voci dell'enciclopedia e l'altra perché riguarda il proteggerle dai vandalismi. Il limite dove lo mettiamo? Anzi, i permessi dei mover e dei rollbacker, in questo senso, sono proprio perfetti come downgrade: sono assegnati solo su richiesta personale, infatti sono pensati per rispondere a necessità di contribuzione "avanzate" ma molto personalizzabili come quelle che può avere un admin poco attivo. --Dry Martini confidati col barista 23:19, 2 dic 2015 (CET)
replies: text: Concordo con Pap3rinik. Nemo 22:22, 29 dic 2015 (CET)

text: Preciso che i criteri di decadenza applicati fino ad ora prevedono la considerazione delle sole azioni presenti in questo tool (cancellazioni/ripristini, blocchi/sblocchi, protezioni/sprotezioni, importazioni e variazioni dei diritti degli utenti) e dei contributi nel namespace MediaWiki. Come ho già scritto propendo per la loro "conferma" e conseguente esplicitazione nella linea guida, al fine di semplificare il controllo, considerando anche la complicatezza dell'aggiunta di alcune ulteriori azioni. Vista anche la recente decadenza di Ariel applicata senza tener conto dei rollback, condivido la necessità di trovare una soluzione quanto prima, qualunque essa sia: segnalo nuovamente al bar generale. --Fullerene (msg) 18:03, 29 dic 2015 (CET)
replies: text: La mia opzione preferita è la terza, perché - come dice bene Eustace - perdere un admin, finché lasciargli i tastini non è pericoloso, danneggia il progetto. In subordine la prima: la seconda, IMHO, non ha molto senso. O si lega la decadenza a un requisito di attività specificamente legato a questo flag o la si elimina, insomma --Formica rufa 18:59, 29 dic 2015 (CET)
replies: text: sono anche io per la terza, per un mio modo essenzialmente pratico di intendere la funzione: se una sera passa un vandal-bot e gli admin sono tutti a gozzovigliare alla festa del tastino, se quella sera circola solo un ex, deflaggato esclusivamente per non uso dei tastini in base al comma terzo dell'articolo 15 del regolamento attuativo etc etc etc, ecco, poi mentre si rimette tutto faticosamente a posto, ci diamo ragione sulla bontà dell'inflessibile regolamento attuativo :-) Seriamente: c'è un aspetto importante che riguarda l'accesso ai dati oscurati (revisioni "cancellate", che il sysop può leggere e il pubblico, come gli altri utenti, no). Fintantoché si tratta di un utente-admin che continua a collaborare alla gestione del sito, ovviamente non c'è pericolo e non c'è motivo di deflag, se non blocca chissenefrega, basta che lo vediamo e sappiamo dov'è. Se però è proprio assente, disperso, missing in inaction, si tratta di qualcuno che sta chissà dove con una chiave di accesso a dati riservati che non usa per ciò per cui l'ha avuta (e che potrebbe cadere in mano di terzi). Metterei quindi più generale attenzione sull'utenza nel suo complesso -- g · ℵ (msg) 19:39, 29 dic 2015 (CET)
replies: text: Tendenzialmente d'accordo con Formica Rufa: la seconda proposta è inattuabile nella pratica, la terza sarebbe la più sensata, la prima, ovvero lasciare le cose come stanno, non aveva mai dato problemi fino al "caso Sbisolo". Diciamo che per un admin dvrebbe essere un po' un "dovere morale" cercare di essere presente anche con le funzioni aggiuntive (altrimenti perde senso l'accettazione della candidatura) e anche, d'altro canto, limitare la propria attività ai campi in cui si è sicuri di non fare danni. Va da sé che chi è inattivo da molto tempo, se è dotato di buon senso, non si lancerà in azioni diverse dal semplice patrolling o dalla piccola manutenzione. Tuttavia anche la questione sollevata da Gianfranco (accesso a dati oscurati) è importante. Comunque personalmente non avrei problemi a sostituire "inattività da admin" con "inattività totale", fermo restando che gli utenti poco attivi, siano IP, registrati, admin o steward, vanno tutti sorvegliati allo stesso modo. --Mari (msg) 20:16, 29 dic 2015 (CET)
replies: text: D'accordo con la terza ipotesi ma tenete conto di una cosa. È talvolta frustrante sapere benissimo cosa fare e non poter fare nulla perché non si hanno i tastini a disposizione. Sia beninteso, non sto studiando da amministratore e non voglio farlo, soprattutto perché la gestione delle utenze, aspetto secondo me fondamentale della figura dell'amministratore, è una cosa che non mi appassiona. Ma alcuni tastini (come mover qualcuno lo ho... e sono utilissimi) per il mio costante lavoro sulle voci, diciamo che farebbero comodo. Ma chi li ha non li usa. Per mesi. Però sta a fare bella mostra di sé nella hall of fame dei cento e passa amministratori di it.wiki e chi lavora è, per chi come me sta dall'altra parte della barricata, uno dei pochi soliti noti. Il discorso andrebbe invece spostato da chi ha la fiducia non deve perderla salvo sparire da Wikipedia, che mi trova d'accordo come puro buonsenso ma che non cambia lo stato delle cose, a facciamo degli specialisti con più possibilità di manovra. La funzione di mover per me è stata un'innovazione grandiosa, facciamo altre sottofunzioni: specialisti di voci, copyright, utenze, immagini, template e chi più ne ha più ne metta. Sono andato OT... chiedo venia per questo, ma per l'utente normale, che ha bisogno del supporto degli amministratori, che ci sia Sbisolo o meno, non fa nessuna differnza. La differenza la fanno quelli (ma non solo quelli) che sono intervenuti in questa discussione, quantomeno solo per il fatto di esserci. --НУРшЯGIO(attenti all'alce) 21:50, 29 dic 2015 (CET)
replies: text: Resto favorevole all'opzione 1. Non trovo motivi per cambiare una modalità che fino ad ora non aveva dato problemi: chi avesse ancora, o avesse di nuovo, voglia/disponibilità di tempo può tranquillamente chiedere di nuovo la fiducia, come è già successo per diversi ex tornati nel ruolo.--Euphydryas (msg) 22:15, 29 dic 2015 (CET)
replies: text: Condivido le preoccupazioni di Gianfranco sulla sicurezza e problema dei missing in action, tuttavia aggiungo, che al pari di Euphydryas non trovo motivi per cambiare una modalità che fino ad ora non aveva dato problemi.--Bramfab Discorriamo 09:12, 30 dic 2015 (CET)
replies: text: Anch'io favorevole alla 3. Per me la ratio della regola dovrebbe essere la sicurezza dell'account, come proposto. Per chi fosse preoccupato di un'eventuale sopraggiunta inadeguatezza dovuta al mancato aggiornamento rimangono sempre le riconferme per chiarire il punto (anche se preferisco di gran lunga segnalare subito eventuali problemi in ns3). Per quanto riguarda il lasso di tempo personalmente sarei per un anno. --Buggia 09:32, 30 dic 2015 (CET)

text: Come Gce e Euphydryas, non vedo particolari motivi per cambiare, dunque favorevole solo alla proposta 1, che chiarisce che solo le azioni esclusive degli admin valgono nel conto. Sul punto 3 non sono specificati i tempi, potrebbe essere anche un'aggiunta al punto 1, ma un'inattivitò totale sarebbe pericolosa con tempi ben più ristretti dei sei mesi, già un mese di inattività totale è troppo. In ogni caso non mi pare ci siano stati problemi in quel senso, premesso che una password difficile (e cambiata spesso) dovrebbe essere la norma, soprattutto per chi ha tastini che non devono cadere nelle mani di un eventuale cracker.--Kirk39 Dimmi! 18:22, 3 gen 2016 (CET)
replies: text: Come Euphydryas. --Dimitrij Kášëv 01:44, 5 gen 2016 (CET)
replies: text: Come Gce. Non vedo motivo di cambiare. --Retaggio (msg) 13:11, 7 gen 2016 (CET)
replies: text: Come Gce anch'io. --Superchilum(scrivimi) 13:16, 7 gen 2016 (CET)
thread_title:  Inattività degli admin 

message: Terminata la procedura che ha dato origine alla discussione, penso sia una buona cosa definire meglio la situazione. A mio avviso ci sono tre possibili soluzioni:
#chiarire la policy adattandola alla "regola" applicata finora (quindi specificare che si considerano azioni "da sysop" solo quelle non condivise con altri gruppi).
#considerare tutte le azioni indicate nell'elenco delle funzioni.
#tornare a legare la decadenza per inattività alla sicurezza dell'account (un'utenza inattiva per tot tempo potrebbe essere stata abbandonata e quindi essere più "vulnerabile" sul lungo periodo) e quindi alla sua inattività totale. 
Personalmente sono a favore dell'opzione 3, perché tutto sommato penso che se un utente rimane comunque attivo, pur non utilizzando le funzioni aggiuntive per un periodo comunque limitato, non sia di particolare utilità deflaggarlo. In ogni caso, qualsiasi decisione si prenda, mi sembra utile prendere una direzione chiara ed esplicitarlo qui.--Eustace Bagge (msg) 15:01, 29 dic 2015 (CET)
replies: text: Preciso che i criteri di decadenza applicati fino ad ora prevedono la considerazione delle sole azioni presenti in questo tool (cancellazioni/ripristini, blocchi/sblocchi, protezioni/sprotezioni, importazioni e variazioni dei diritti degli utenti) e dei contributi nel namespace MediaWiki. Come ho già scritto propendo per la loro "conferma" e conseguente esplicitazione nella linea guida, al fine di semplificare il controllo, considerando anche la complicatezza dell'aggiunta di alcune ulteriori azioni. Vista anche la recente decadenza di Ariel applicata senza tener conto dei rollback, condivido la necessità di trovare una soluzione quanto prima, qualunque essa sia: segnalo nuovamente al bar generale. --Fullerene (msg) 18:03, 29 dic 2015 (CET)
replies: text: La mia opzione preferita è la terza, perché - come dice bene Eustace - perdere un admin, finché lasciargli i tastini non è pericoloso, danneggia il progetto. In subordine la prima: la seconda, IMHO, non ha molto senso. O si lega la decadenza a un requisito di attività specificamente legato a questo flag o la si elimina, insomma --Formica rufa 18:59, 29 dic 2015 (CET)
replies: text: sono anche io per la terza, per un mio modo essenzialmente pratico di intendere la funzione: se una sera passa un vandal-bot e gli admin sono tutti a gozzovigliare alla festa del tastino, se quella sera circola solo un ex, deflaggato esclusivamente per non uso dei tastini in base al comma terzo dell'articolo 15 del regolamento attuativo etc etc etc, ecco, poi mentre si rimette tutto faticosamente a posto, ci diamo ragione sulla bontà dell'inflessibile regolamento attuativo :-) Seriamente: c'è un aspetto importante che riguarda l'accesso ai dati oscurati (revisioni "cancellate", che il sysop può leggere e il pubblico, come gli altri utenti, no). Fintantoché si tratta di un utente-admin che continua a collaborare alla gestione del sito, ovviamente non c'è pericolo e non c'è motivo di deflag, se non blocca chissenefrega, basta che lo vediamo e sappiamo dov'è. Se però è proprio assente, disperso, missing in inaction, si tratta di qualcuno che sta chissà dove con una chiave di accesso a dati riservati che non usa per ciò per cui l'ha avuta (e che potrebbe cadere in mano di terzi). Metterei quindi più generale attenzione sull'utenza nel suo complesso -- g · ℵ (msg) 19:39, 29 dic 2015 (CET)
replies: text: Tendenzialmente d'accordo con Formica Rufa: la seconda proposta è inattuabile nella pratica, la terza sarebbe la più sensata, la prima, ovvero lasciare le cose come stanno, non aveva mai dato problemi fino al "caso Sbisolo". Diciamo che per un admin dvrebbe essere un po' un "dovere morale" cercare di essere presente anche con le funzioni aggiuntive (altrimenti perde senso l'accettazione della candidatura) e anche, d'altro canto, limitare la propria attività ai campi in cui si è sicuri di non fare danni. Va da sé che chi è inattivo da molto tempo, se è dotato di buon senso, non si lancerà in azioni diverse dal semplice patrolling o dalla piccola manutenzione. Tuttavia anche la questione sollevata da Gianfranco (accesso a dati oscurati) è importante. Comunque personalmente non avrei problemi a sostituire "inattività da admin" con "inattività totale", fermo restando che gli utenti poco attivi, siano IP, registrati, admin o steward, vanno tutti sorvegliati allo stesso modo. --Mari (msg) 20:16, 29 dic 2015 (CET)
replies: text: D'accordo con la terza ipotesi ma tenete conto di una cosa. È talvolta frustrante sapere benissimo cosa fare e non poter fare nulla perché non si hanno i tastini a disposizione. Sia beninteso, non sto studiando da amministratore e non voglio farlo, soprattutto perché la gestione delle utenze, aspetto secondo me fondamentale della figura dell'amministratore, è una cosa che non mi appassiona. Ma alcuni tastini (come mover qualcuno lo ho... e sono utilissimi) per il mio costante lavoro sulle voci, diciamo che farebbero comodo. Ma chi li ha non li usa. Per mesi. Però sta a fare bella mostra di sé nella hall of fame dei cento e passa amministratori di it.wiki e chi lavora è, per chi come me sta dall'altra parte della barricata, uno dei pochi soliti noti. Il discorso andrebbe invece spostato da chi ha la fiducia non deve perderla salvo sparire da Wikipedia, che mi trova d'accordo come puro buonsenso ma che non cambia lo stato delle cose, a facciamo degli specialisti con più possibilità di manovra. La funzione di mover per me è stata un'innovazione grandiosa, facciamo altre sottofunzioni: specialisti di voci, copyright, utenze, immagini, template e chi più ne ha più ne metta. Sono andato OT... chiedo venia per questo, ma per l'utente normale, che ha bisogno del supporto degli amministratori, che ci sia Sbisolo o meno, non fa nessuna differnza. La differenza la fanno quelli (ma non solo quelli) che sono intervenuti in questa discussione, quantomeno solo per il fatto di esserci. --НУРшЯGIO(attenti all'alce) 21:50, 29 dic 2015 (CET)
replies: text: Resto favorevole all'opzione 1. Non trovo motivi per cambiare una modalità che fino ad ora non aveva dato problemi: chi avesse ancora, o avesse di nuovo, voglia/disponibilità di tempo può tranquillamente chiedere di nuovo la fiducia, come è già successo per diversi ex tornati nel ruolo.--Euphydryas (msg) 22:15, 29 dic 2015 (CET)
replies: text: Condivido le preoccupazioni di Gianfranco sulla sicurezza e problema dei missing in action, tuttavia aggiungo, che al pari di Euphydryas non trovo motivi per cambiare una modalità che fino ad ora non aveva dato problemi.--Bramfab Discorriamo 09:12, 30 dic 2015 (CET)
replies: text: Anch'io favorevole alla 3. Per me la ratio della regola dovrebbe essere la sicurezza dell'account, come proposto. Per chi fosse preoccupato di un'eventuale sopraggiunta inadeguatezza dovuta al mancato aggiornamento rimangono sempre le riconferme per chiarire il punto (anche se preferisco di gran lunga segnalare subito eventuali problemi in ns3). Per quanto riguarda il lasso di tempo personalmente sarei per un anno. --Buggia 09:32, 30 dic 2015 (CET)

text: Come Gce e Euphydryas, non vedo particolari motivi per cambiare, dunque favorevole solo alla proposta 1, che chiarisce che solo le azioni esclusive degli admin valgono nel conto. Sul punto 3 non sono specificati i tempi, potrebbe essere anche un'aggiunta al punto 1, ma un'inattivitò totale sarebbe pericolosa con tempi ben più ristretti dei sei mesi, già un mese di inattività totale è troppo. In ogni caso non mi pare ci siano stati problemi in quel senso, premesso che una password difficile (e cambiata spesso) dovrebbe essere la norma, soprattutto per chi ha tastini che non devono cadere nelle mani di un eventuale cracker.--Kirk39 Dimmi! 18:22, 3 gen 2016 (CET)
replies: text: Come Euphydryas. --Dimitrij Kášëv 01:44, 5 gen 2016 (CET)
replies: text: Come Gce. Non vedo motivo di cambiare. --Retaggio (msg) 13:11, 7 gen 2016 (CET)
replies: text: Come Gce anch'io. --Superchilum(scrivimi) 13:16, 7 gen 2016 (CET)
thread_title: (reprise)

message: C'è una cosa che non mi torna in tutta questa discussione su cosa considerare come "azione di amministrazione": ci si limita a cercare criteri quantitativi - anche perché sono gli unici quantificabili oggettivamente - ma non si pensa allo scopo del sysop, che è quello di "mantenere in ordine Wikipedia". 
Io sono un amministratore a mezzo servizio da anni. (In realtà se ci fosse un flag che permetta di vedere le versioni cancellate delle voci, a me basterebbe quello per rispondere alle richieste che mi arrivano come portavoce di Wikimedia Italia da gente che non ha capito la differenza con Wikipedia). Qualche "operazione da amministratore" la faccio tutti i mesi se non proprio tutte le settimane, quindi non corro certo il rischio di essere cancellato per inattività. Però per esempio stamattina ho fatto due operazioni: cancellare la pagina Discussione:Fumoir con testo
:::è BELLISSIMA!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
:::intrigante. di sicuro comincerò ad usare anch'io il fumoir!!!!!!!!!!!!!!!!!!111
e bloccare per NUI l'utente 	"Marco XXXXX Fotografo Videomaker" (ho cancellato qui il cognome perché irrilevante). Ora, anche se nessuno avesse compiuto la mia prima operazione, i danni per Wikipedia non sarebbero stati poi così gravi; il blocco per NUI è invece più serio. Ma come fa una procedura automatica a riconoscere questa differenza?
È per questo che, mentre capisco una revoca dopo un certo periodo in cui non si fanno operazioni, sarei più liberale nel decidere quali sono effettivamente le operazioni. -- .mau. ✉ 13:44, 5 gen 2016 (CET)
replies: text: , capisco perfettamente il senso del tuo intervento e in teoria sarei pienamente d'accordo. Il problema è proprio stabilire parametri oggettivi per evitare di ricorrere a chilometriche discussioni in ciascuna di queste occasioni, che si fanno sempre più frequenti mentre la comunità è sempre più grande ed eterogenea. Se già la proposta n.2 (ampliare il ventaglio delle azioni considerabili "da amministratore") è stata bocciata quasi all'unanimità perché di difficile applicazione, non oso immaginare quanto lo sarebbe dover discutere sull'utilità di ogni singola azione di un amministratore poco attivo. Per me, per esempio, anche cancellare una pagina di discussione "da forum" è un gesto utile all'enciclopedia perché contribuisce a mantenerne la serietà e la fruibilità (altrimenti né tu, né io ci daremmo la pena di farlo), mentre altri utenti potrebbero non essere d'accordo. Si tratta insomma di conciliare il sacrosanto buon senso, che mi auguro non venga mai a mancare, con l'esigenza di semplificare almeno le procedure facilmente automatizzabili come quella di cui stiamo discutendo. --Mari (msg) 17:05, 7 gen 2016 (CET)
thread_title:  stiamo guardando gli alberi e non la foresta 

message: Continuando [[Aiuto:Sportello informazioni#autoverificato < $qualcosa < amministratore|questa domanda]], ma se un admin in realtà fosse eletto solo per fargli modificare qualche template protetto, non sarebbe praticamente sempre inattivo secondo la definizione di decadenza per inattività che non comprende la modifica a pagine protette? --Valerio Bozzolan (msg) 16:34, 12 mar 2017 (CET)
replies: text: Noi contiamo molto sul fatto che una volta fornito di spada laser si faccia coinvolgere nella lotta contro il lato oscuro della forza e faccia anche altro... :-) --Civvì (You talkin' to me?) 16:54, 12 mar 2017 (CET)
replies: text:  Capisco. --Valerio Bozzolan (msg) 17:40, 12 mar 2017 (CET)
replies: text: Formalmente si, se l'admin in questione non facesse altro decadrebbe. Ma sarebbe strano: considera che ad esempio i C9 farà il favore di cancellarseli da solo... ;-) --Yuмa (msg) 17:46, 12 mar 2017 (CET)
replies: text: Questa domanda mi pare dimostri che il criterio "quantitativo" è un po' inadeguato (se uno "smanettone" lavorasse a, mettiamo, 6 template all'anno, migliorandoli, o anche 12, non farebbe alcuna cancellazione per C9). C'è una proposta che mi pare sia sempre quantitativa qui. Io manterrei la riconferma annuale, eliminando però del tutto il criterio quantitativo, quale che sia. In questo modo possiamo ragionare in termini di senso: anche ipotizzando un admin con zero edit sysop, ma attivo per il resto, alla riconferma anche coloro che ritengono che ci voglia un minimo sindacale (per intenderci) di edit sysop possono votare contro la riconferma in base ad una mancata percezione di fiducia, senza che però intervengano elementi ragionieristici (reali o percepiti) da parte dei sysop. Manterrei invece il deflag d'ufficio per sei mesi di inattività completa, esclusivamente a tutela dell'utenza da mani malintenzionate. Con questo sistema rigidamente anti-quantitativo, ritengo che 1. ragioneremmo del roster con in mente soltanto le persone che stanno dietro i tastini, 2. coloro che chiedono che si batta un colpo "minimo" potranno dire la propria anche se il sysop ha, mettiamo, solo 2 edit sysop in sei mesi, sentendosi al contempo spinti ad avanzare una contrarietà più articolata, senza "sbattere" contro l'obiezione "eh, però 2 edit sysop li ha, mo' che vuoi, le regole sono regole ecc.", 3. un sysop non sarebbe mai spinto a fare anche una sola azione esclusivamente in vista del deflag, 4. non avremmo l'imbarazzo di identificare l'"edit sysop", perché confermeremmo il sysop ed esso voteremmo, quindi qualunque genere di sysop. Forse, l'abolizione di una soglia quantitativa è la chiave della soluzione del dissidio che serpeggia su questa materia da un po' di anni a questa parte. Ma magari invece sto scrivendo grandi sciocchezze notturne, nel qual caso ditemelo e sconterò, nello scusarmi, la pena (utile a wp!) che deciderete. :D pequod Ƿƿ 03:35, 13 mar 2017 (CET)
replies: text: Concordo con Pequod che è meglio tenere 6 mesi di inattività totale e basta (come fr.wiki; en.wiki e de.wiki prevedono un anno); una soglia quantitativa è inutilmente burocratica e può portare (come si vede nella domanda iniziale) a situazioni assurde. --MarcoK (msg) 11:06, 13 mar 2017 (CET)

text: Magari a prescindere dai criteri, il controllo di questi criteri potrebbe essere a prescindere dall'ultimo periodo di attività. Esempio: sono inattivo da 1 anno, ma attivo nell'ultima settimana, ma non si considerano buoni queste attività, e quindi sono comunque considerabile inattivo. Potrebbe essere un compromesso-tampone. --Valerio Bozzolan (msg) 13:45, 13 mar 2017 (CET)
replies: text:  Hai mai letto il paradosso dell'impiccagione imprevedibile? Potrebbe in un certo senso applicarsi alla tua teoria, perché allora io potrei fare attività nella penultima settimana (visto che l'ultima non conterebbe), che quindi andrebbe anch'essa esclusa dal computo, e così via, arrivando al paradosso che tutti gli amministratori verrebbero deflaggati il primo giorno :-) --Lepido (msg) 14:41, 13 mar 2017 (CET)
replies: text: State ovviamente puntando al Wikioscar "avvitamento burocratico", vero? KISSes a tutti e due :-D --Civvì (You talkin' to me?) 14:48, 13 mar 2017 (CET)
replies: text:  ...e se il peso delle modifiche fosse rapportato ad una funzione gaussiana affinchè i contributi più importanti siano quelli da periodi non-sospetti (meno importanza all'inizio e alla fine e più importanza in mezzo)? No? OK basta asd. --Valerio Bozzolan (msg) 18:19, 13 mar 2017 (CET)
thread_title:  Inattività 

message: Ho messo o chiesto non so quanti edit notice su dove fare le domande e poi ho sbagliato io intanto segnalo [] poi cambuso. Devo scappare--Pierpao.lo (listening) 09:23, 23 ago 2017 (CEST)
thread_title:  Segnalo discussione