Discussioni Wikipedia:Richieste di permessi

message: Al momento la sezione per l'assegnazione del flag di convalidato rimanda alla pagina di richiesta dei flag su Meta (pagina usata quando serve uno steward) ma ora i Burocrati possono aggiungere e rimuovere il flag di convalidato (vedete qui) quindi le richieste dovrebbero essere gestite in questa pagina. --Samuele2002 (Chiedi pure!) 22:21, 13 set 2017 (CEST)
replies: text: Già. Ma se attribuissimo il permesso per l'assegnazione del flag direttamente agli admin?... --Lucas  ✉  00:07, 14 set 2017 (CEST)
replies: text: Io son d'accordo, ma non so se poi da meta la possano considerare "troppa libertà"... Martin (scrivimi) 14:49, 14 set 2017 (CEST)
replies: text: Non credo che le richieste possano essere così tante da richiedere più di 6 utenti. E facciamoli lavorare 'sti burocrati! :P XD --Gce ★★★+4 15:01, 14 set 2017 (CEST)
replies: text: Quante richieste di convalida sono state fatte finora? --Vito (msg) 18:10, 15 set 2017 (CEST)
replies: text: Si non è utile anzi, lasciamo le cose come stanno, ci mancano solo i vandali che vengono a sollecitare parti delicate perchè vogliono diventare convalidati per modficare le pagine semiprotette. I CU patrollino :)--Pierpao.lo (listening) 18:21, 15 set 2017 (CEST)
replies: text:  Probabilmente una ogni morte di sei papi, visto anche la richiesta "evapora" in fretta. Per questo la vedo non molto sensibile specie se gestita fuori da "pagine di richieste" ufficiali pro-spammer. --Lucas  ✉  18:25, 15 set 2017 (CEST)
replies: text: Non ne capisco l'utilità, se sono automaticamente autoconvalidati con appena 10 edit e 4 giorni dalla registrazione, che bisogno c'è di accelerare? Come dice Pierpao più probabili i vantaggi degli svantaggi. Per pochi giorni se deve caricare un file o spostare di titolo che lo chiedano ad un altro o.. aspettino, mica sono 2 mesi, mentre sono più probabili gli edit di pagine semiprotette a cui sono interessati.--Kirk Dimmi! 18:32, 15 set 2017 (CEST)
replies: text: Ma qui mica discutiamo l'utilità del flag, ma di chi lo attribuisce, l'utilità è e resta molto molto limitata (sono casi particolari: in genere o per utenze specifiche con funzioni tecniche o per nuovi utenti che già si conoscono e necessitano subito delle funzioni base di upload immagini, magari in un editathlon e simili; poi da rimuovere), tutto qua. --Lucas  ✉  18:44, 15 set 2017 (CEST)
replies: text: No è la stessa cosa perchè se lo attribuiscono i Burocrati  poi le richieste non si fanno più su Meta, altrimenti su Meta dicono "o ci siete o ci fate". E se dobiamo fare le richieste qui dobbiamo scriverlo nelle pagine dell'aiuto. E secondo te chi si presenta a fare richiesta dicendo "è scritto nelle linee guida" e poi "perchè non mi avete convalidato" in tre discussioni diverse e poi "apro una segnalazione a Vituzzu che non mi ha convalifato dopo la mia richiesta"? Immagina: una richiesta ogni semiprotezione più o meno.--Pierpao.lo (listening) 18:51, 15 set 2017 (CEST)
replies: text: Anche adesso è scritto nelle linee guida, e non sarebbe scritto diversamente da come è ora (cambierebbe solo il luogo). E lo stesso discorso, se fosse vero, varrebbe anche e più per gli autoverificati, ma non si sono mai verificati scenari simili. --Lucas  ✉  19:16, 15 set 2017 (CEST)
replies: text: Si ma meta è lontano, è in inglese, i vandali di cui parlo, quelli che leggono le linee guida, sono indisciplinati, deboli ma non stupidi se le cose sono facile e trovano la scusa che ai loro occhi giustifica ci provano per presunzione, vedi la richiesta di pareri su Xinstalker. Ma se sono troppo complicate no. Una richiesta di autoverificazione per un neoregistrato è palesemente al di fuoridi ogni scusa, lo vede anche un troll. Invece qualchè scusa imbecille per chiedere l'autoconvalida capace la tirerebbero fuori. Non so se riesco a spiegarmi. Secondo me il rischio c'è e non vale l'utilità pressocchè nulla di spostarla qua--Pierpao.lo (listening) 19:34, 15 set 2017 (CEST)
replies: text: La vedo diversa: come nei casi che citavo prima nella parentesi, può essere utile in casi concreti, e un'attribuzione interna, ancorché rara, ne facilita e snellisce l'utilizzo. Ovviamente se uno scenario così apocalittico davvero mai dovesse verificarsi si rollbacka a vista, l'abbiamo sempre fatto dovunque. Non dimentichiamo che oltre ad essere gestibile dai burocrati, in alcune wiki è un permesso che è attribuito agli admin, e non sono crollate sotto orde di vandali spammer. It.wiki è la partria di tutti i vandali? :-) La domanda di Vito è la più concreta: può servire? Io direi di sì, per i motivi suddetti. Capisco eventuali timori, ma credo anche siano inferiori ai potenziali vantaggi, sempre piccoli restano, poiché raro è l'utilizzo, ma ci sono: e sono esattamente quelli che hanno portato l'estensione del permesso ai burocrati di default. --Lucas  ✉  19:52, 15 set 2017 (CEST)

text: Semmai ai burocrati; nel Utente:Lucas si può pensare ad un linea guida estremamente restrittiva che non incentivi richieste fantasiose--Pierpao.lo (listening) 22:39, 17 set 2017 (CEST)
replies: text: Tirando le somme la permettiamo la richiesta in questa pagina (permettendo l'assegnazione anche solamente ai burocrati)? Anche perché se uno fa richiesta su Meta al 99% viene rifiutata in quanto qui ci sono dei burocrati attivi. --Samuele2002 (Chiedi pure!) 12:20, 14 gen 2018 (CET)
thread_title: Aggiungere le richieste per il flag di convalidato

message: A torto o a ragione, l'assegnazione del flag di AV sta diventando sempre più esclusivo. Le nostre linee guida recitano che "un utente è adatto ad essere proposto per il gruppo degli autoverificati non qualora la sua contribuzione sia esente da errori, ma quando appare sufficientemente affidabile da rendere eccessiva la puntuale verifica di ogni sua modifica". Tuttavia, che esistano alcune regole non scritte (o parametri da rispettare, se preferite) è un segreto di Pulcinella, e le riassumo spannometricamente di seguito:
*il candidato è registrato da almeno 6 mesi.
*il candidato ha effettuato almeno 1000 edit.
*il candidato compila regolarmente il campo oggetto,
a cui spesso si aggiunge la richiesta di una contribuzione costruttiva e di un atteggiamento pacato. Evidentemente nemmeno queste sono ritenute sufficienti perché sempre più spesso saltano fuori richieste IMHO... esorbitanti, che persino gli utenti di lungo corso (compreso qualche admin!) faticherebbero a soddisfare. Senza alcuna polemica, proviamo a tirare le somme su cosa sia lecito aspettarsi da un candidato e, soprattutto, cosa non lo sia? Le situazioni come quelle venutesi a creare nella candidatura di Effems a febbraio e più recentemente in quella di Plasm sono state parecchio spiacevoli e imbarazzanti. Per tutti, non solo per i candidati --Ombra 12:39, 27 set 2017 (CEST)
replies: text: Non è una medaglietta di merito dove si premia qualcuno alla carriera wikipediana. È solo un flag che dice questo utente è affidabile e va controllato meno. Mi è successo in passato che un utente autoverificato ha iniziato a cambiare titoli di pagine (magari anche in buona fede) senza una linea guida a supporto, senza una benché minima discussione, solo supportato dal "be bold" e da dei convincimenti personali. Se non fosse stato autoverificato ci si sarebbe accorti subito di ciò che stava facendo, ma nel frattempo sono passati un paio di giorni e ha combinato un discreto caos. Spiacente ma io voglio che queste cose non accadano più o, almeno il meno possibile, e pertanto sono severo e contineurò a fare le pulci a chi è proposto per il flag. Abbiamo esempi di utenti validissimi (uno è addirittura uno storicississimo utente proposto per ben sette volte, e che non ha mai avuto il flag, per me il settimo pilastro di Wikipedia, ammesso che esista il sesto) che non hanno il flag ma va bene così. È un flag tecnico, lasciamolo tale e diamolo solo a chi siamo veramente sicuri e non a chi probabilmente se lo merita. Per l'utente averlo o non averlo non cambia nulla, per i patroller cambia moltissimo. --НУРшЯGIO(attenti all'alce bestadmin) 13:10, 27 set 2017 (CEST)
replies: text: Non ritengo corretto avere dei criteri aggiuntivi segreto di Pulcinella che non sono ufficializzati, pertanto sono  a mettere per iscritto alcuni di essi, in particolare quello delle 1000 modifiche, un numero abbastanza ampio da potersi fare un'idea di massima sul contributore e su come opera. --Gce ★★★+4 14:02, 27 set 2017 (CEST)
replies: text: Si, mettiamoli per iscritto (anche l'uso corretto del campo oggetto), ma teniamo conto che gli utenti non autoverificati spesso non sanno cosa sia, quindi è un flag utile per patroller ed admin, non per l'utente. Quando sono stato proposto, sono cascato dalle nuvole! --Ruthven (msg) 14:54, 27 set 2017 (CEST)
replies: text: , però poi non esageriamo con gli avvitamenti burocratici--Ferdi2005  (Posta) 15:00, 27 set 2017 (CEST)
replies: text:  Secondo me sono inutili. C'è il rischio che quello diventi il target per essere autoverificati quando invece si deve verificare solo una cosa, l'affidablità dell'utente. E il campo oggetto, al quale sono molto attento, fa parte, anche quello dell'affidabilità.--НУРшЯGIO(attenti all'alce bestadmin) 16:05, 27 set 2017 (CEST)

text: Temo di essere stato frainteso. Non mi interessa dare la priorità a parametri o statistiche [per quanto i tre punti che ho elencato qua sopra, e che non ho inventato io, sono già da un bel pezzo la regola, e sarebbe miope negarlo. Basta leggere le presentazioni dei candidati che comprendono sempre questi tre numeri oppure farsi un giro nell'archivio e dare una scorsa ai motivi più frequenti della mancata assegnazione. Perciò a dirla tutta, l'invito a "mantenere le cose come sono" significa semplicemente mantenere una realtà sommersa] bensì abbozzare un orientamento di massima (giustissimo il procedere "caso per caso" purché si condivida la stessa interpretazione del flag) atto a evitare procedure in cui fazioni diverse si beccano tra loro mentre il candidato è spettatore di una assegnazione di flag che non ha nemmeno richiesto --Ombra 17:58, 27 set 2017 (CEST)
replies: text: Quoto Lucas parola per parola. --Retaggio (msg) 18:01, 27 set 2017 (CEST)
replies: text: @Ombra, sì sì avevo capito l'intento, :-) ma alla fine credo che l'unico "criterio" sia proprio quello che diceva Hypergio: l'utente fa edit del tutto incontestabili? Sì? Flag. No? Niente flag. Ha centomila edit? Ne ha mille? Usa il campo oggetto? Lo usa poco? Sì; no; non lo so; ma alla fine non c'entra. :-) --Lucas  ✉  13:59, 28 set 2017 (CEST)
replies: text: Sono contrario a inserire nuovi requisiti e trovo a maggior ragione sbagliato farli valere senza che siano resi espliciti: si finisce solo per generare delle incomprensioni, che a loro volta portano a episodi spiacevoli come quelli citati da Ombra (in uno dei quali, purtroppo, ho fatto la mia parte, e me ne scuso). Entrando nel merito dei "criteri aggiuntivi", faccio notare che i sei mesi e i 1000 contributi sono superiori al requisito minimo attualmente previsto per essere candidati sysop - il che sarebbe un assurdo. Quanto alla compilazione del campo oggetto, concordo che rientri tra i parametri di valutazione (se non lo si usa mai o, peggio, lo si usa in modo ingannevole), ma mi sembra riduttivo considerarlo l'unico parametro, come ho visto fare in diverse procedure di assegnazione; soprattutto se la valutazione viene fatta con astrusi calcoli di percentuali..--Eustace Bagge (msg) 14:25, 28 set 2017 (CEST)
thread_title: Tiriamo le somme?

message: Vedo che le richieste vengono singolarmente archiviate manualmente ogni tanto appena concluse, sarebbe fattibile invece un'archiviazione automatica come all'Officina e allo Sportello informazioni? Non credo sia un problema lasciare nella pagina le richieste concluse da un po', e mi sembra che ogni richiesta venga chiusa nel giro di massimo 15 giorni. --goth nespresso 15:19, 13 gen 2019 (CET)
replies: text: Non è fattibile, perché mentre questa pagina è cumulativa, gli archivi sono differenziati per tipo di richiesta. Inoltre, anche se pianificassimo un solo archivio generale, il bot non raggrupperebbe le richieste per tipo, ma le mischierebbe in base al solo criterio cronologico.--Sakretsu (炸裂) 17:17, 13 gen 2019 (CET)
replies: text: Se invece istruissimo il bot per fare un'archiviazione alla volta per tipo (es: il 29 di ogni mese gli autoverificati, il 30 i mover, ecc...), potremmo fargli capire di preciso cosa prendere e dove archiviarlo? --goth nespresso 17:56, 13 gen 2019 (CET)
replies: text: In teoria al bot basterebbe leggere i nomi delle sezioni per capire dove archiviare le richieste, ma ci sono un po' di controindicazioni: se qualcuno si dimentica di inserire una sottosezione "Revoche", la richiesta verrebbe archiviata tra le abilitazioni; mover e rollbacker vanno riportati pure nella pagina di smistamento degli archivi; la formattazione degli archivi deve prevedere la distinzione tra abilitazioni e revoche. Praticamente ci vorrebbe qualcuno che adattasse lo script generico solo per questa pagina.--Sakretsu (炸裂) 18:25, 13 gen 2019 (CET)
thread_title:  Archiviazione automatica 

message: Non sarebbe meglio gestire in questa pagina le richieste dei flag temporanei di amministratore? È senz'altro più adatta del progetto Cococo.--Mauro Tozzi (msg) 20:23, 13 mar 2019 (CET)
replies: text: Mi sembra una buona idea. Per quanto mi riguarda sono d'accordo. --НУРшЯGIO(attenti all'alce) 22:04, 13 mar 2019 (CET)
replies: text:  questa pagina nasce proprio per non disperdere l'assegnazione dei vari flag --Ombra 22:29, 13 mar 2019 (CET)
replies: text:  quando ho letto stavo pensando alla pagina dove ci sono le candidature o le elezioni degli Admin, ma trattandosi di un flag temporaneo (che in molti casi serve anche con tempi più celeri) mi vien da pensare senza dubbio a questa pagina. --Torque (scrivimi!) 09:20, 14 mar 2019 (CET)
replies: text:  idem come i precedenti. --Epìdosis 12:00, 14 mar 2019 (CET)
replies: text:  Come sopra. --Dimitrij Kášëv 13:41, 15 mar 2019 (CET)
replies: text: Non si è mai discusso al progetto co co co tout court. Succedeva semplicemente che a volte si formavano dei gruppi di lavoro e dopo un certo periodo di affiatamento e verifica reciproca a certe persone si dava un flag non solo temporaneo ma finalizzato a terminare un lavoro specifico che avevano dimostrato di saper fare bene e senza sbavature--Pierpao.lo (listening) 12:24, 14 mar 2019 (CET)
replies: text:  in verità la regola dice di fare richiesta in Progetto:Cococo/Flag temporanei come scritto in tale pagina, se poi adesso si decide di cambiare Va bene lo stesso --NewDataB (msg) 12:32, 14 mar 2019 (CET)
replies: text: Si certo non sono stato chiaro, io volevo spiegare il senso della regola e come era stata applicata, almeno per quello che ricordo io. --Pierpao.lo (listening) 12:38, 14 mar 2019 (CET)
replies: text: Ho aggiunto il template storica al COCOCO, leggendo l'ordine proposto da GN nella discussione successiva, che direi che va bene, dove si mette la sezione per i flag temporanei?--Pierpao.lo (listening) 15:08, 16 mar 2019 (CET)
thread_title:  Richieste di flag temporanei 

message: Ciao, è normale che la funziona "cerca negli archivi" del template  non funzioni in questa pagina? A memoria fino a poco tempo fa funzionava se cercavo degli utenti. --Torque (scrivimi!) 12:50, 20 mar 2019 (CET)
replies: text: Immagino perché il template  cerca le parole che scrivi solo tra le sottopagine di "Wikipedia:Richieste di permessi" (credo), quindi non trova nulla perché, ad esempio, le richieste di rollbacker stanno in Wikipedia:Rollbacker/Abilitazioni/Archivio (che non è appunto una sottopagina della voce in cui è inserito il template). Correggetemi se sto dicendo una castroneria. --goth nespresso 15:34, 20 mar 2019 (CET)
replies: text: La pagina non ha un archivio diretto ma varie sottopagine per categoria a loro volta suddivise per data. Non più di qualche settimana fa facendo una ricerca funzionava (nello specifico volevo proporre un utente come autoverificato ma prima volevo controllare se esistevano già precedenti richieste... di solito non dava problemi; ora invece da 0 risultati). --Torque (scrivimi!) 17:19, 20 mar 2019 (CET)
replies: text: Per risolvere dovremmo appunto spostare gli archivi al prefisso "Wikipedia:Richieste di permessi/...", d'altronde sono sottopagine di questa.--Sakretsu (炸裂) 17:54, 20 mar 2019 (CET)
replies: text: Si praticamente quando si sono centralizzate le richieste non si sono centralizzati gli archivi--Pierpao.lo (listening) 18:49, 20 mar 2019 (CET)
replies: text:  ho spostato tutte le pagine, aggiornato i wikilink e lasciato in vita i redirect con link in entrata dalle vecchie discussioni. Adesso la ricerca negli archivi dà i suoi frutti--Sakretsu (炸裂) 12:37, 7 apr 2019 (CEST)
thread_title:  Problema archivio 

message: C'è qualcosa di stonato nei requisiti. Mentre per i mover chiediamo espressamente che siano AV questo non avviene per i rollbacker. Lo aggiungiamo? Se n'era già fatto cenno qui, forse è il caso di riparlarne nella sede opportuna (Discussioni Wikipedia:Rollbacker)? --Civvì  (Parliamone...) 14:00, 22 gen 2020 (CET)
replies: text: Disuniformità a parte, di fatto (non so alle origini, ma perlomeno da parecchi anni) non si flagga mai chi non è autoverificato, perciò tanto vale riportarlo espressamente tra i requisiti anziché doverlo scrivere ogni volta--Parma1983 14:07, 22 gen 2020 (CET)
replies: text: Decisamente da aggiungere, secondo me. Penso non sia stato scritto fra i requisiti in quanto dato per scontato, ma meglio specificare. ×°˜`°×ηαη¢у×°˜`°× 14:08, 22 gen 2020 (CET)
replies: text:  Anche io penso sia opportuno inserirlo come requisito --Dave93b (msg) 14:12, 22 gen 2020 (CET)
replies: text:  anch'io--Luke Stark 96 (msg) 14:13, 22 gen 2020 (CET)
replies: text:  come Parma.--Luca•M 14:16, 22 gen 2020 (CET)
replies: text:  come Parma. --Antonio1952 (msg) 14:29, 22 gen 2020 (CET)
replies: text:  quoto Parma --goth nespresso 14:30, 22 gen 2020 (CET)
replies: text: , sono assolutamente d'accordo con Parma.--Ferdi2005[Posta] 16:19, 22 gen 2020 (CET)

text: Secondo me ci stiamo trascinando delle robe storiche. Il gruppo autopatrolled è stato istituito (ho dei vaghi ricordi ma posso sbagliarmi) successivamente, i requisiti per diventare admin erano già stati delineati. Mentre i gruppi Mover e Rollbacker sono successivi. Però è vero, specificare che anche per candidarsi admin è necessario essere AV eviterebbe eventuali candidature "temerarie", sono rare ma in passato ne sono capitate... --Civvì  (Parliamone...) 18:40, 22 gen 2020 (CET)
replies: text:  anche a richiederlo per diventare admin. De facto è già così, e nei requisiti per diventare admin si richiede già che il candidato possegga tutte le qualità richieste per essere AV (addirittura avrà il potere di assegnare il flag di AV ad altri utenti). Poi ecco, inserirlo nelle linee guida è quasi superfluo (a differenza che per i rollbacker), però non vedo che male faccia o che problemi possa creare. --Ripe (msg) 20:42, 22 gen 2020 (CET)

text: --Leo0428 (msg) 20:55, 22 gen 2020 (CET)
replies: text: Interessante l'appunto di 3knolls,  ad aggiungere una nota per entrambi i flag. --Dimitrij Kášëv 20:58, 22 gen 2020 (CET)
replies: text:  ad aggiungere una nota sulla necessità di essere AV per candidarsi a qualsiasi flag di livello superiore. Come diceva Civvì si tratta di una lacuna antica di cui nessuno, evidentemente, si era mai curato. --Sesquipedale (non parlar male) 21:51, 22 gen 2020 (CET)
replies: text: Credo che la ricostruzione della Civvì sia realistica: d'altra parte, tra i requisiti per diventare admin c'è l'aver compiuto almeno 500 modifiche, soglia in corrispondenza della quale se uno si candidasse oggi verrebbe bocciato clamorosamente :D Direi che effettivamente sarebbe necessario indicare anche là l'autoverifica tra i requisiti ;)--Parma1983 00:22, 23 gen 2020 (CET)
replies: text: , come Sesquipedale. --GC85 (msg) 00:34, 23 gen 2020 (CET)
replies: text: Visto che c'è unanimità al riguardo, chi si occupa di aggiornare le pagine?--Mauro Tozzi (msg) 08:49, 24 gen 2020 (CET)
replies: text: In tarda mattinata provo a iniziare a elencare le pagine da aggiornare (ho la sensazione che sicuramente ce ne sfuggirà qualcuna) :-| --Civvì  (Parliamone...) 09:14, 24 gen 2020 (CET)

text: Ecco, oltre a Utente:Civvì/Correzioni queste vi viene in mente altro? --Civvì  (Parliamone...) 15:46, 24 gen 2020 (CET)

text: Grazie per la nota storica. Però, se introduciamo il vincolo dell'AV, formalmente il rischio si ripresenta, perché la candidatura diventa inammissibile. In pratica, essendo i sysop più di 100, il rischio, ammesso che ci sia mai stato, di un ostracismo per motivi ideologici (di qualunque tipo essi siano, politici, religiosi, calcistici, ecc.) mi sembra molto, molto basso. Fra 100 e più, qualche "bastian contrario" si trova sicuramente! --Antonio1952 (msg) 16:49, 24 gen 2020 (CET)

text: Ho come la lievissima sensazione che tutte queste affascinanti ipotesi violino un "filino" la presunzione di buona fede. Ma solo un filino. --Civvì  (Parliamone...) 18:06, 24 gen 2020 (CET)
thread_title:  Requisiti 

message: E' un po' di tempo che ci penso ed effettivamente è strano che un utente possa diventare Mover tramite un cambio di permessi effettuato da un qualsiasi Admin, mentre per i Rollbacker sia necessario un Burocrate. Entrambe le cariche possono far danni (IMHO della stessa gravità): non sarebbe il caso di uniformare anche questo aspetto?--Luca•M 14:59, 22 gen 2020 (CET)
replies: text: Non so se ci siano dei motivi particolari che abbiano spinto a differenziare l'assegnazione dei due flag, ma apparentemente non sembrerebbero essercene, quindi sarei  ad uniformare anche questo aspetto--Parma1983 15:05, 22 gen 2020 (CET)
replies: text: Anche io sono  ad equiparare.--Ferdi2005[Posta] 16:19, 22 gen 2020 (CET)
replies: text:  all'equiparazione --Lemure Saltante    sentiamo un po'   16:44, 22 gen 2020 (CET)
replies: text:  anche per me, condivido le riflessioni qui sopra --Dave93b (msg) 16:46, 22 gen 2020 (CET)
replies: text:  pure io, penso che un pasticcio fatto da un mover sia più complicato da ripristinare rispetto a un rollback errato - qui basta un contro rollback. --Bradipo Lento (msg) 16:49, 22 gen 2020 (CET)

text:  Equiparare in che senso? Che ci voglia un burocrate anche per i mover? Scusate quanti casi di mover problematici ci sono stati? Non si ha fiducia negli amministratori? Sempre contrario ad ogni avvitamento immotivato.--Pierpao.lo (listening) 16:54, 22 gen 2020 (CET)
replies: text:  In realtà l'avvitamento immotivato è la situazione attuale: perché due categorie molto simili per tanti aspetti devono avere due modalità di assegnazione differente? Non è più semplice averne solo uno (che sia quello di far modificare i permessi per Mover ai soli Burocrati o viceversa quello di Rollbacker a tutti gli admin)?--Luca•M 17:03, 22 gen 2020 (CET)
replies: text: } User:Luca M ovviamente su questa seconda ipotesi sono d'accordo, non so quanto sia fattibile credo che certi permessi siano decisi globalmente. Chiedo a user:Wim b--Pierpao.lo (listening) 20:28, 22 gen 2020 (CET)

text:  completamente.--Mrtb (msg) 17:09, 22 gen 2020 (CET)
replies: text: Rollbacker e mover non hanno alcuna similitudine. Il rollbacker reverta una pagina ed il tutto gli è trasparente; può anche non sapere cosa avviene tecnicamente: se la pag. annullata viene rimossa fisicamente, se viene aggiornato un puntatore di pagina ed altro. Il livello è funzionale al contributo (contenuto pagina). Il mover compie un'azione sulle pagine funzionale ad esse e deve avere un minimo di infarinatura. Che poi appaiono simili perché se ne ha talmente padronanza da considerarli banali può darsi. Detto ciò, la proposta va verso una direzione semplificante uniformante, che non può che essere .--☼Windino☼ [Rec] 17:19, 22 gen 2020 (CET)

text: --Leo0428 (msg) 20:55, 22 gen 2020 (CET)
replies: text: Ipotizzo che la differenza fra mover (sysop) e rollbacker (burocrate) possa essere dovuta al fatto che in realtà fino al 2015 il mover era solo un file mover cioè poteva solo spostare file e quindi aveva IMHO incombenze e poteri limitati, dopo ha avuto anche la possibilità di cancellare il redirect al momento dello spostamento di una voce ma non si è pensato di variare anche il livello autorizzativo.  ad unificarli entrambi al livello di burocrate. --Antonio1952 (msg) 22:34, 22 gen 2020 (CET)
replies: text: Onde evitare discussioni come questa, anch'io sono  ad unificarli entrambi al livello di burocrate.--3knolls (msg) 22:41, 22 gen 2020 (CET)
replies: text:  --Dimitrij Kášëv 22:53, 22 gen 2020 (CET)
replies: text: , anzi ho sempre pensato che sia più facile far casini massicci come mover che da rollbacker, quindi che su quest'ultimo ci voglia un burocrate e per l'altro basti un admin non mi pare il caso, probabilmente dipende da anni fa, come detto da Antonio1952. Sono indifferente sul fatto che ci voglia un burocrate per dar la funzione aggiuntiva o basti un admin.--Kirk Dimmi! 23:07, 22 gen 2020 (CET)
replies: text: Va bene, ma scegliamo con sicurezza a chi dare e a chi togliere il diritto. Il cambiamento richiede un task su Phabricator per la modifica al file di configurazione--Sakretsu (炸裂) 23:48, 22 gen 2020 (CET)
replies: text: I favorevoli sono per attribuire per entrambi ai soli burocrati l'attivazione della funzione. D'altronde, il burocrate nasce proprio per gestire i flag utente. Il fatto che alcuni flag possano essere gestiti dagli admin è, questa si, una semplificazione che si utilizza nei casi di meno conto che tutti conosciamo.  anch'io. Apriamo questo phabtask. --.avgas 00:25, 23 gen 2020 (CET)
replies: text: --GC85 (msg) 00:32, 23 gen 2020 (CET)

text: Task creato. --.avgas 12:28, 23 gen 2020 (CET)
replies: text: Modifica effettuata, pagine di servizio aggiornate. --.avgas 10:59, 13 feb 2020 (CET)

text: Scusa , potresti chiarire meglio la tua proposta? Attualmente un admin perde il flag dopo sei mesi di non-uso delle funzioni di amministratore, un rollbacker perde il flag dopo sei mesi di non-uso del tasto rollback, mentre un mover perde il flag dopo un anno di totale inattività (=zero modifiche in qualsiasi namespace, indipendentemente dall'uso o dal non-uso del flag stesso). Tu cosa proponi esattamente? Sei mesi di non-uso delle funzioni di mover o sei mesi di totale inattività?--3knolls (msg) 20:35, 24 gen 2020 (CET)
replies: text: Intendo sei mesi di non utilizzo delle funzioni di Mover.--Luca•M 21:05, 24 gen 2020 (CET)
thread_title:  Equiparare Rollbacker e Mover 

message: Uniformiamo a 6 mesi anche per i Mover (come Admin e Rollbacker)?--Luca•M 18:26, 24 gen 2020 (CET)
replies: text: Scusa , potresti chiarire meglio la tua proposta? Attualmente un admin perde il flag dopo sei mesi di non-uso delle funzioni di amministratore, un rollbacker perde il flag dopo sei mesi di non-uso del tasto rollback, mentre un mover perde il flag dopo un anno di totale inattività (=zero modifiche in qualsiasi namespace, indipendentemente dall'uso o dal non-uso del flag stesso). Tu cosa proponi esattamente? Sei mesi di non-uso delle funzioni di mover o sei mesi di totale inattività?--3knolls (msg) 20:35, 24 gen 2020 (CET)
replies: text: Intendo sei mesi di non utilizzo delle funzioni di Mover.--Luca•M 21:05, 24 gen 2020 (CET)
thread_title:  Revoca per inattività 

message: Ho pensato molto ultimamente al fatto che, spesso e volentieri, sia amministratori che Rollbacker debbano, per evitare di fare danno col [rollback], tenere attivo questo accessorio (il quale richiede all'utente una ulteriore conferma prima di annullare le modifiche selezionate). Non si potrebbe quindi metterlo attivo "di serie" a tutti i nuovi Rollbakcer e Admin?--Luca•M 10:36, 12 apr 2020 (CEST)
replies: text: Ma no, il rollback serve proprio per fare alla svelta. --Buggia 10:41, 12 apr 2020 (CEST)
replies: text: Che lo attivi chi ne sente il bisogno ;-) A margine e in piccolo vorrei esprimere immensa e imperitura gratitudine a  per la creazione di quel tool <3 --Civvì  (Parliamone...) 10:43, 12 apr 2020 (CEST)
replies: text: Per quanto anche io debba ringraziare per l'esistenza di quel gadget, credo che per altri potrebbe essere un fastidio, essendo (come dice Buggia) il rollback una funzione pensata per fare in fretta. Si potrebbe però pubblicizzare maggiormente il gadget, ad esempio in Aiuto:Rollback. A margine, a differenza della funzione "ufficiale" attivabile qui, il gadget di Valerio ha una simpatica funzionalità aggiuntiva: cliccando col pulsante centrale del mouse il rollback viene effettuato senza chiedere conferma! --Daimona Eaytoy (Scrivimi!) 15:01, 12 apr 2020 (CEST)
replies: text: La vedo come Civvì: personalmente vado subito ad abilitarmi la funzionalità (ad avercela già avuta, mi avrebbe evitato un po' di clic accidentali legati all'"assestamento" delle pagine), ma non sono favorevole a una sua imposizione generalizzata, perché per fortuna non tutti hanno il dito tremulo come il mio :-) --Vale93b Fatti sentire! 15:16, 12 apr 2020 (CEST)
replies: text: Anch'io preferisco rimanga una scelta. Però mi vedo d'accordo con Daimona Eaytoy sul pubblicizzare di più l'accessorio, io infatti non lo conoscevo e (per fortuna!) mi è stato consigliato :D --GryffindorD 15:42, 12 apr 2020 (CEST)
replies: text: Come sopra. --Dimitrij Kášëv 16:07, 12 apr 2020 (CEST)
replies: text: Nono, che resti una scelta: personalmente preferisco fare danni in tutta fretta :-D--Equoreo (msg) 16:35, 12 apr 2020 (CEST)

text: PS: Devo riconoscere che questo strumento mi sarebbe tanto di intralcio al PC quanto utile le rare volte che edito da mobile (schermo piccolo + dita grandi = pastrocchi enormi). Sarebbe mica possibile avere un opzione per attivarlo solo per gli edit da mobile?--Equoreo (msg) 16:35, 12 apr 2020 (CEST)

text: Condivido completamente quanto detto da Equoreo, io il 99% del lavoro lo faccio al computer, invece stamattina ho iniziato con cellulare, poi per sbaglio ho rollbackato Luca M (quindi credo sia per "colpa" mia se ha aperto questa discussione) ;), e allora sono passato subito al PC per non fare altri danni, infatti è stata la prima volta che ho annullato qualcuno per errore, ma solo perché ero con il cell--Luke Stark 96 (msg) 17:42, 12 apr 2020 (CEST)
replies: text: Anche secondo me, deve rimanere una scelta personale. Vero che se si è dal pc può essere un intralcio, ma da mobile (mi) è fondamentale per evitare click involontari quando pensi di clickare qualcosa e invece la pagina si muove ancora e fai la frittata! Se, come dice Equoreo, fosse possibile attivarlo solo per gli edit da mobile, tanto tanto meglio! --GC85 (msg) 18:14, 12 apr 2020 (CEST)
replies: text: A renderlo obbligatorio sarei contrario anch'io, ma potrebbe essere utile abilitarlo di default ai nuovi rollbacker, che potranno però poi disattivarlo quando si sentiranno più sicuri. IMHO potrebbe essere utile per un rollbacker alle prime armi, lasciando comunque la possibilità di toglierlo anche subito a propria discrezione. Altrimenti anche pubblicizzarlo di più (come ad esempio nella pagina WP:Rollbacker), sarebbe una buona idea. --PercyMM(msg) 19:26, 12 apr 2020 (CEST)
replies: text: Certo che è possibile attivarlo solo su mobile :) Anzi, basta copiare l'opportuno gadget da enwiki. --Daimona Eaytoy (Scrivimi!) 20:05, 12 apr 2020 (CEST)
replies: text: Mi pare più utile per mobile e dovrebbe rimanere una scelta, da pc capita, ma molto di rado, di annullare per sbaglio, e come diceva Buggia, il tastino serve a velocizzare, altrimenti, ad esempio, per annullare il vandalo seriale (come quello sui generi musicali) si perde solo ulteriore tempo per nulla.--Kirk Dimmi! 20:17, 12 apr 2020 (CEST)
replies: text:  Sarei un pochettino contrario alla creazione di un ulteriore gadget da mantenere ma molto favorevole alla possibilità di aggiungere una piccola opzione personale per poter attivare solo su mobile il gadget già esistente (motivo per cui questo gadget è stato ideato! penso). Stasera qualche bozza a riguardo. --The quick brown fox (msg) 09:41, 14 apr 2020 (CEST)
replies: text:  Ho buttato giù due righe in una pagina di spiegazione su Aiuto:Accessori/SureSureSure con questa precisa funzionalità di disabilitazione su desktop. Ora è solo documentato. Se piace l'idea, affinchè funzioni proporrei di caricare questa versione in MediaWiki:Gadget-SureSureSure.js (a margine, nè l'ho testato e n'è posso caricarla, ora scappo ciaao asd) --Valerio Bozzolan (msg) 11:38, 19 apr 2020 (CEST)

text: Parlando con Valerio abbiamo convenuto di mettere un doppio controllo, uno sull'UA e uno sulla larghezza dello schermo. Rimarrebbe da implementare "fisicamente" la modifica, cosa che spero di poter fare prima o poi, ma non garantisco. --Daimona Eaytoy (Scrivimi!) 13:34, 29 mag 2020 (CEST)
replies: text: Segnalo gli ultimi sviluppi su WP:Officina. Chi desidera che l'accessorio funzioni solo su mobile può seguire le istruzioni in Aiuto:Accessori/SureSureSure#Disabilitare su desktop--Sakretsu (炸裂) 11:54, 19 ago 2020 (CEST)
thread_title:  Sicuro sicuro sicuro? di serie per Rollbacker e Admin 

message: Tempo fa, in seguito a questa discussione, si era deciso di aggiungere l'AV come requisito necessario per poter richiedere il flag di rollbacker. Tra gli attuali requisiti, però, viene ancora richiesto (punto 2), che il richiedente sia in possesso dei requisiti di voto. Eppure i requisiti di voto sono richiesti per l'assegnazione del flag di autoverificato. Essendo ora l'AV tra i requisiti, non ha senso chiedere separatamente anche che l'utente soddisfi i requisiti di voto sugli utenti. Chiedo quindi se posso procedere con la rimozione di tale requisito da questa e questa pagina (ovviamente se siete d'accordo). Grazie in anticipo a chi si esprimerà :) --PercyMM 17:39, 3 ago 2020 (CEST)
replies: text: . --.avgas 11:14, 4 ago 2020 (CEST)
replies: text: L'ho rimosso anche da WP:Rollbacker#Modalità di assegnazione. Grazie! --Civvì  (Parliamone...) 13:44, 4 ago 2020 (CEST)
replies: text:  Grazie a entrambe :) --PercyMM 14:35, 5 ago 2020 (CEST)
replies: text: E ci mancherebbe, power girls sempre a disposizione. --.avgas 11:51, 8 ago 2020 (CEST)
replies: text: Marco LOOOL--Parma1983 14:41, 8 ago 2020 (CEST)
thread_title:  Requisito rollbacker ridondante 

message: Ora è già la seconda volta in 5 minuti che non vedo il  a causa dei "favorevole in ritardo". Ok, non c'è nulla di male nello scriverlo, ma potremmo regolarci evitando di usare i template, indentando di un livello in più rispetto ai normali commenti e utilizzando il tag small?--ValeJappo【〒】 11:52, 21 nov 2020 (CET)
replies: text: Sì, hai ragione, scusa. Mi capita talvolta di lasciare il favorevole in ritardo se mi capita di visionare la "candidatura" dopo che la richiesta è stata evasa, ma hai ragione sul fatto che bisognerebbe come minimo indentarli, per non creare confusione. Anche riporre il commento tra i tag  sarebbe IMHO opportuno in questo senso. --PercyMM 12:01, 21 nov 2020 (CET)
replies: text: Essendo la discussione chiusa basta metterli prima del  semplicemente con un --Pierpao (listening) 12:16, 21 nov 2020 (CET)
replies: text: Basta aggiungere il  come ha detto Pierpao --Ap7189ap 01:39, 22 nov 2020 (CET)
thread_title:  Favorevole in ritardo 

message: Trovo abbastanza priva di senso l'archiviazione delle richieste AV con il copia incolla quando è molto più semplice linkare il diff al fatto/non fatto. Ho provato a fare un esempio qui con la richiesta di Syphax98. Sarebbe bene cercare di semplificare e velocizzare le attività non primarie ai fini dell'enciclopedia. Sintetici pareri?  --Civvì  (Parliamone...) 14:06, 21 nov 2020 (CET)
replies: text: Mi stupisco che questa bell’idea non sia stata adottata prima.  Ruthven (msg) 14:08, 21 nov 2020 (CET)
replies: text: Condivido, in questo modo snelliamo ed evitiamo di ricopiare l’intera discussione, eliminando sottopagine pesanti e inutili. Sarei anche per archiviare al massimo, ma proprio al massimo, 48 ore dopo il fatto, è inutile tenere le richieste per una settimana. Se una richiesta è stata evasa significa che c’era il consenso/l’ovvietà e i commenti successivi difficilmente andranno a smentirne il risultato. Superpes15(talk) 14:13, 21 nov 2020 (CET)
replies: text: Condivido anch'io, vedo poco pratico archiviare (perdendo tempo) con copia/incolla. Molto meglio linkare il diff per velocizzare il tutto --Mtarch11 (msg) 14:21, 21 nov 2020 (CET)
replies: text: Trovo anch'io che una settimana sia un tempo eccessivo prima dell'archiviazione, 48 ore sarebbero sufficienti. Per il copia-incolla condivido il fatto che è veramente superfluo: fa perdere tempo e appesantisce inutilmente le sottopagine. IMHO sarebbe più efficace, anziché il diff, linkare l'oldid. Facendo sempre l'esempio di Syphax98, io metterei questo link.  che ne pensi? :) --PercyMM 14:45, 21 nov 2020 (CET)
replies: text: Concordo sull'oldid (abbiamo un template?), chi assegna il flag lo mette nel campo oggetto e già che c'è aggiorna l'elenco. Poi 48 ore dopo si rimuove dalla pagina delle richieste. --Civvì  (Parliamone...) 15:02, 21 nov 2020 (CET)
replies: text: Sì, penso anche io sia meglio e più ordinato inserire il link permanente, ma il senso della discussione è comunque quello di capire se sia opportuno cambiare metodo di archiviazione o no. Vediamo in che direzione andrà il consenso. --Superpes15(talk) 15:07, 21 nov 2020 (CET)
replies: text: Esiste il template:Oldid, ma penso che ormai sia obsoleto visto che si può scrivere semplicemente Syphax98 → Syphax98. L'idea comunque mi pare buona--Sakretsu (炸裂) 15:20, 21 nov 2020 (CET)
replies: text: Effettivamente basta un link permanente, si potrebbe anche pensare a un rimando alla PU (inutile imho anche perché diversi utenti non l'hanno creata, basta fare come ha detto Sakretsu). Qui 3 opzioni (penso che la migliore sia quella di "AlfaWikiBeto"). --Superpes15(talk) 15:33, 21 nov 2020 (CET)
replies: text: L' "opzione AlfaWikiBeto', quella del permalink mi pare ottima. Le vecchie procedure invece si lasceranno così?--ValeJappo【〒】 15:54, 21 nov 2020 (CET)
replies: text: Favorevole anch'io all'opzione AlfaWikiBeto. Più pratica anche per chi deve consultare. --ΞLCAIRØ♭ 15:58, 21 nov 2020 (CET)
replies: text: Anche per me va bene la versione di AlfaWikiBeto, tenere le segnalazioni una settimana è inutile, al massimo 24/48 ore --Ap7189ap 01:38, 22 nov 2020 (CET)
replies: text: +1 sulla versione AlfaWikiBeto di Superpes15 --Civvì  (Parliamone...) 07:58, 22 nov 2020 (CET)
replies: text:  pure io sulla versione AlfaWikiBeto. --PercyMM 11:23, 22 nov 2020 (CET)

text: --Luca•M 13:20, 22 nov 2020 (CET)
replies: text: Ok sul diff, ma i byte mica pesano: una settimana è un tempo adeguato se qualcuno vuole porre obiezioni a posteriori. --Cpaolo79 (msg) 19:10, 22 nov 2020 (CET)

text: Stiamo adottando questa soluzione per semplicità, penso che applicarla alle procedure già archiviate sia un controsenso, possono benissimo restare così come sono--ValeJappo【〒】 12:29, 26 nov 2020 (CET)
replies: text:  Secondo me così va benissimo (ottimo lavoro, grazie :D) e si potrebbe procedere con la cancellazione delle sottopagine. Per gli AV concordo che sarebbe un lavoraccio e anche abbastanza inutile, quindi direi di lasciar stare e limitarsi ad archiviare con il nuovo metodo d'ora in poi. Sarebbe meglio distinguere in qualche modo le revoche dalle abilitazioni oppure non serve? In caso sarei per adottare una soluzione semplice (tipo usare per le revoche il corsivo). --PercyMM 17:23, 26 nov 2020 (CET)
replies: text:  Stavo effettivamente pensando a un modo per separarle per le vie brevi. Direi che si potrebbe usare il corsivo/il testo cancellato oppure mettere le revoche alla fine, scrivendo priva "Revoche:" in grassetto senza creare colonne o righe inutili. --Superpes15(talk) 17:29, 26 nov 2020 (CET)
replies: text: Mi piace l'ipotesi del testo cancellato--ValeJappo【〒】 17:38, 26 nov 2020 (CET)
replies: text:  Concordo sull'applicare una soluzione semplice. Ho fatto dei test in anteprima e secondo me il corsivo non è un'ottima soluzione perché a colpo d'occhio quasi non si nota. Ti dirò che invece il barrato mi piace come idea: è immediatamente distinguibile ma lascia comunque il nome utente ben leggibile. Altrimenti anche indicare tutte le revoche in fondo precedute da un "Revoche:" in grassetto andrebbe bene, però IMHO il barrato è più immediato e permette di seguire anche per le revoche l'ordine cronologico generale. --PercyMM 17:41, 26 nov 2020 (CET)
replies: text: Supporto anche io l'idea del barrato per le revoche. --Lollo Scrivimi 17:42, 26 nov 2020 (CET)
replies: text: Ho riorganizzato l'archivio dei rollbacker dei 2020 secondo la nuova metodologia di archiviazione (indicazione dell'oldid tramite link permanente), andando anche a indicare con il barrato le revoche, mantenendo quindi intatto l'ordine cronologico. L'archivio si trova qui (così si può vedere applicato praticamente il barrato per le revoche).  visto che IMHO c'è sufficiente consenso sul nuovo metodo di archiviazione, io direi di andare a cancellare le sottopagine degli archivi sistemati (questa e questa), che ne dici? Per gli altri anni comunque direi che andare a sistemare tutti gli archivi (sia per rollbacker che per mover) sarebbe una gran faticaccia, e anche abbastanza inutile. Quindi direi di lasciarli così, ma di iniziare già da ora ad archiviare con il nuovo metodo. Che ne pensi? --PercyMM 22:28, 27 nov 2020 (CET)
replies: text:  Ottimo lavoro, per me può andare, per i precedenti ormai si può lasciare così ma d'ora in poi si cambia metodo e si snellisce il tutto :D Vediamo che ne pensano gli altri --Superpes15(talk) 00:26, 28 nov 2020 (CET)

text: Concordo, dato che per gli AV la sottopagina del periodo corrente è rimasta potrebbe essere confusionarlo non scriverlo. --PercyMM 18:49, 30 nov 2020 (CET)
replies: text:  Ha risolto brillantemente (e pazientemente) Superpes: ha eliminato la sottopagina delle richieste del secondo semestre, che ha archiviato direttamente qui con il nuovo metodo, cosicché sia tutto più chiaro. Ho aggiornato l'incpit specificando del grassetto e del barrato (dal secondo semestre 2020 in poi). --PercyMM 13:46, 3 dic 2020 (CET)
thread_title:  Archiviazione 

message: Qui --Civvì  (Parliamone...) 11:49, 4 dic 2020 (CET)
thread_title:  Segnalo 

message: Di recente, alcuni utenti registrati, wikipedianamente giovani, ma ben a conoscenza del funzionamento di wikipedia (perché magari istruiti da altri o informati sulle pagine di servizio), si stanno dedicando con costanza all'attività di patrolling. Il numero di utenti si conta sulle dita di due mani, ma l'apporto di annullamenti effettuati è elevato.
L'origine di questo intervento è che gli utenti in questione non sono AV e pertanto non possono verificare le modifiche che annullano, risultando così in un patroller che "segue" un altro, verificando le sue modifiche annullate in stile Pollicino.
La mia proposta è la creazione di un flag intermedio tra autoconvalidati e autoverificati, denominato pattuglia (per evitare di chiamarlo patroller) che si configura così:
*Gli utenti autoconvalidati possono fare richiesta di abilitazione nell'apposita pagina di servizio; non sono ammesse candidature da parte di terzi.
*L'utente deve partecipare all'attività di patrolling
*L'utente non deve essere autoverificato
*La pattuglia, similmente al rollbacker, contrassegna in automatico come verificate le modifiche che annulla. Modifiche di altro tipo continueranno a presentare il patrolmark.
Il flag può essere assegnato da un amministratore (ma non a propria discrezione come il flag di AV) e può essere rimosso da un amministratore in caso di:
*Abuso dello strumento.
*Se l'utente diventa autoverificato, in tal caso i due flag sono ridondanti.
--Lollo Scrivimi 18:12, 8 dic 2020 (CET)
replies: text: Idea interessante, forse non necessaria? Comunque, patrolmarks è il permesso di segnare le modifiche come verificate,mentre patrol di averle automaticamente modificate. I permessi non si applicano alla singola modifica , ma agli utenti (cioè, tutte le modifiche saranno automaticamente verificate); di default quindi ciò che proponi non credo sia fattibile, anche se forse mettendo mano a qualche configurazione di mediawiki si può fare. Prima di discuterne chiederei un parere agli amministratori d'interfaccia--ValeJappo【〒】 18:19, 8 dic 2020 (CET)
replies: text: proposta interessante, ma che a mio avviso complica le cose. Se ci possiamo fidare della buonafede dei loro annullamenti, non vedo perché non farli semplicemente AV. Anche perché, come hai detto, si "contano sulle dita di due mani".--EnzoEncius (10.000!) 19:11, 8 dic 2020 (CET)
replies: text:  in realtà mi riferisco a utenti che non soddisfano i criteri per essere AV, quindi meno di 60 giorni dalla prima modifica e/o meno di 500 modifiche (ma principalmente la prima). Quindi la problematica maggiore è proprio la verifica delle modifiche che annullano, e non la verifica delle loro modifiche. Mi capita spesso di passare per modifiche annullate da utenti non-AV che si dedicano al patrolling, che verifico io, ma che l'utente che ha compiuto l'annullamento non può verificare. Gli utenti sono pochi, ma la loro contribuzione è notevole, e un flag di questo tipo sarebbe utile ai patroller. --Lollo Scrivimi 20:58, 8 dic 2020 (CET)

text: Che sia completamente inutile è discutibile, ma di fatto come detto da Superpes15 sarebbe un flag di breve durata e quanto descritto sopra sarebbe un lavoro eccessivo per la gestione dei permessi. Speravo fosse possibile evitare di passare due volte sulla stessa modifica. Grazie ugualmente. --Lollo Scrivimi 00:19, 9 dic 2020 (CET)
replies: text: Il mio inutile non era riferito ai flag intermedi in particolare, ma ai flag intermedi su itwiki, considerando i diritti e i gruppi di cui disponiamo. Bisognerebbe comunque creare un nuovo usergroup, l'impatto sull'enciclopedia non è da poco, per ora imho è meglio rimanere così. Ma resta un mio parere personale tranquillamente opinabile --Superpes15(talk) 00:39, 9 dic 2020 (CET)

text: Vi ringrazio, il mio voleva essere un tentativo di risoluzione delle modifiche non verificate sulle quali i patroller passano spesso due volte. Utilitaristicamente il lavoro è maggiore del beneficio, meglio lasciare perdere. --Lollo Scrivimi 01:17, 9 dic 2020 (CET)
replies: text:  Comunque si tratta di neoutenti, quindi è utile verificare i loro edit e quelli che a loro volta annullano, oltre agli avvisi che lasciano nelle talk dopo i revert. E poi se dovessero apparire utenti appena iscritti e già espertissimi di tutte le procedure che riguardano il patrolling, le segnalazioni, gli avvisi, le linee guida, ecc... beh, un punto esclamativo rosso vicino all'edit può essere un'ottima occasione per dare quell'occhiata in più che è sempre utile, considerando che molte reincarnazioni di utenti infinitati hanno iniziato a contribuire proprio dal patrolling --Mtarch11 (msg) 03:26, 10 dic 2020 (CET)
thread_title:  Flag intermedio 

message: Ho notato che ci sono numerosi utenti autoverificati che sono stati bloccati reiteratamente o all'infinito. Non sarebbe il caso di rimuoverli da questa lista? Mi riferisco in particolare a: Cuchillo, Fausta Samaritani, Fioravante Patrone, Frazzone, Gabrasca, Ghibellin Fuggiasco, Guido Magnano, HominisCon, Indil77, Jon de Visser, Nevermindfc, Ottaedro, Triple 8, Xinstalker, Zele72 (spero di non essermene persi per strada). --Lo Scaligero 12:32, 23 mar 2021 (CET)
replies: text: una volta bloccati a tempo indeterminato è indifferente che siano autovertificati o meno. Tanto più che alcuni di questi utenti non sono stati bloccati in quanto problematici bensì su loro stessa richiesta: qualora chiedessero di ritornare, li accoglieremmo a braccia aperte :) --Ombra 13:21, 23 mar 2021 (CET)
replies: text: Indifferente o no, non ha comunque senso che un'utenza bloccata a tempo indeterminato sia autoverificata, a maggior ragione se il blocco è stato comminato non su sua richiesta, pertanto almeno per questi ultimi sono  alla revoca. --Gce ★★★+2 22:14, 23 mar 2021 (CET)
replies: text: Personalmente come Gce. --Popsi (msg) 08:56, 24 mar 2021 (CET)
replies: text: Sono assolutamente d'accordo con Gce. Penso sia corretto distinguere i blocchi volontari con quelli per problematicità;  alla revoca per questi ultimi. GA16   […] 08:58, 24 mar 2021 (CET)
replies: text:  Ma ragazzi, sono utenti infinitati, anche da anni. Quali edit volete controllare dal momento che non possono farli? Sarebbe solo un avvitamento burocratico.--Luca•M 12:13, 24 mar 2021 (CET)
replies: text: Ma se mi fate una lista di infinitati problematici non ho problemi a levarli, però diciamo che non è che mi sembri una questione sulla quale valga la pena spenderci più di 30 secon... --Vito (msg) 12:15, 24 mar 2021 (CET)
thread_title:  Utenti bloccati/infinitati 

message: Ciao, ho notato che mentre le richieste per gli utenti autoverificati, i rollbacker, i mover, i creatori di utenze e i convalidati vengono archiviate per diff, dopo questa discussione, a partire dal 2022 non si potrebbero archiviare allo stesso modo gli esenti dal blocco IP per conformità agli altri flag? --Andr€a (talk) 08:02, 20 dic 2021 (CET)
thread_title:  Modalità archiviazione esenti dal blocco IP 

message: A seguito di quanto accaduto qui, con un chiarimento da parte dell'admin  che aveva bloccato l'utenza, che sarebbe stato molto utile avere in prima battuta, e notando anche un altro caso (N.B. lo linko a titolo puramente esemplificativo! ),  in cui un utente ha avuto la revoca dei flag solo 5 giorni prima della scadenza del blocco di un mese, e suppongo che  se ne sia accorta per caso, perché non mi pare di aver visto alcuna richiesta di revoca né da parte di  né da altri... Ebbene, mi chiedo e vi chiedo se sarebbe possibile introdurre una consuetudine che sicuramente aiuterebbe i burocrati, magari anche scritta nelle linee guida, ma basterebbe anche per buona e semplice collaborazione tra chi deve gestire blocchi e diritti utenti, e cioè che l'admin che blocca e che quindi conosce bene tuti gli aspetti della problematicità, si occupi anche contestualmente di sottoporre la richiesta di revoca ai burocrati, adeguatamente e chiaramente motivata soprattutto quando il blocco avviene al di fuori di una UP o RdP. Fermo restando la possibilità prevista dalle linee guida che chiunque può fare richiesta, una richiesta presentata più celermente direttamente dall'admin "bloccatore" eviterebbe quelle provenienti da utenti in qualche modo coinvolti o inesperti, e quindi poco chiare. 
Altro punto da chiarire una volta per tutte, secondo me, è l'automaticità della revoca dei flag in caso di blocco, che al momento non è prevista dalle linee guida. --Euphydryas (msg) 15:20, 3 set 2022 (CEST)
replies: text: Io preferirei veder fatto uso del buon senso in qualsiasi situazione. Concretamente: non si levano i flag a meno che il blocco non sia scaturito per diretto abuso del relativo privilegio, caso più raro del più frequente blocco per motivi X che non c'entrano, quanto meno direttamente, con il flag Y o Z. Insomma, nessuna nuova ennesima (e in questo caso inutile) policy. --.avgas 18:55, 3 set 2022 (CEST)
replies: text:  La vedo diversamente: i flag, oltre ad assegnare funzioni aggiuntive, indicano un livello di fiducia da parte della comunità. Fiducia che viene a meno nella maggior parte dei casi quando un utente subisce un blocco. Le revoche sono quindi spesso giustificate anche in assenza dell'abuso di tali funzioni. ×°˜`°×ηαη¢у×°˜`°× 19:45, 3 set 2022 (CEST)
replies: text: Se è così anche i miei flag dovrebbero essere rimossi...--UltimoGrimm (msg) 20:00, 3 set 2022 (CEST)
replies: text:  Il tuo ultimo blocco risale a quasi 3 anni fa. Da allora, i ruoli di rollbacker e mover ti sono stati revocati per inattività nel 2020, prima di essere riassegnati il mese scorso. Le persone cambiano e maturano, e hai chiaramente riottenuto la fiducia della comunità dopo che le problematiche che hanno portato al tuo blocco sono state superate. È una situazione completamente diversa rispetto a quella che ha portato a questa discussione, che vede invece coinvolto un utente che è stato spesso richiamato in passato per avere abusato delle sue funzioni aggiuntive: senza un cambiamento nel suo atteggiamento, questa conseguenza è stata inevitabile. ×°˜`°×ηαη¢у×°˜`°× 21:17, 3 set 2022 (CEST)
replies: text: Ti ringrazio per la fiducia, ma quello che volevo sottolineare è che secondo me dovremmo prendere una decisione per evitare discussioni del genere in futuro. Se una persona viene bloccata, il flag va levato? Se si, in futuro può ottenerlo di nuovo o no? Dopo quanto? Vediamo di prendere una decisione così evitiamo altre discussioni in futuro--UltimoGrimm (msg) 01:08, 4 set 2022 (CEST)
replies: text: Nel complesso condivido le parole di : credo che un automatismo blocco--->rimozione dei flag sarebbe sbagliato, perché la situazione può essere molto diversa da caso a caso e un blocco dovuto a cause completamente indipendenti dai flag (ad esempio, un blocco breve per attacchi personali in una discussione) non vedo perché dovrebbe implicarne la rimozione--Parma1983 01:39, 4 set 2022 (CEST)
replies: text:  Automatismo no, ma  giustamente propone che sia l'admin stesso a occuparsi della richiesta di revoca, anche in assenza di una linea guida. Una breve linea guida per gli admin a mio avviso sarebbe utile, per chiarire almeno l'opportunità (non obbligatorietà) di provvedere alla richiesta e l'affidamento al buon senso (può essere citato un esempio come quello che hai fatto tu). La linea guida non è ridondante né burocratica, perché gli admin non nascono imparati e perché hanno un'interpretazione a testa: lo vediamo nelle cancellazioni immediate, l'abbiamo visto con il debutto del namespace Bozza ecc. Poi va da sé che non dev'essere una linea guida casistica, capillare, stringente e che lega le mani. Anche perché l'admin sottopone una semplice richiesta al burocrate e può anche permettersi di sbagliare: mal che vada, il burocrate la respinge --Actormusicus (msg) 08:44, 4 set 2022 (CEST)

text: Io vedrei meglio che l'admin si impegnasse - come già deve fare e in effetti si fa - a specificare a chiare lettere le motivazioni del blocco. Così facendo chiunque altro può ragionare sull'eventuale rimozione del flag senza ulteriori sovrastrutture. Wikipedia è collaborativa. Al di là di questo, tenete conto che se c'è da deflaggare, la situazione di solito è assai evidente. --.avgas 10:12, 4 set 2022 (CEST)
replies: text: Condivido i commenti di Merynancy. Mio modesto parere: credo che l'automatismo blocco=deflag possa essere utile a tutela del progetto. Se un utente ha fatto qualcosa di talmente grave da esser stato bloccato (perché se è stato addirittura bloccato vuol dire che c'è stato davvero un problema grave), significa che la sua contribuzione generale necessita di verifiche più approfondite da parte degli altri utenti. Questa condizione IMHO non è mai compatibile con il flag di AV, che secondo me andrebbe rimosso d'ufficio dopo un blocco (e, di conseguenza, rimossi tutti gli altri flag che richiedono l'AV). Se poi l'utente riprende una condotta regolare, può essere riproposto come AV e successivamente riottenere anche gli altri flag di cui ha bisogno. Del resto la problematicità non è "eterna" e credo che la comunità non si sia mai fatta problemi nel riflaggare utenti validi per il progetto che si sono "corretti", anche se in passato hanno fatto qualcosa di sbagliato e sono stati bloccati/deflaggati. --Mtarch11 (msg) 13:42, 4 set 2022 (CEST)
replies: text:  Attento, però, perché pensata così anche un blocco di 5 minuti per attacchi (dai quali negli anni non sono stati esenti nemmeno degli admin) comporterebbe la revoca di ogni flag. Un blocco per definizione non dev'essere punitivo, mentre con un'impostazione del genere lo diventerebbe--Parma1983 14:59, 4 set 2022 (CEST)
replies: text: Vero anche quello, probabilmente c'è da aggiungere qualcosa al punto 3, nel caso di blocchi brevi (anche una settimana) per attacchi, di quelli da parte di utenti esperti se ne sono visti tanti, ma non di rado non hanno nulla a che vedere con le voci e col tastino, nel casi di blocchi relativamente corti per quel motivo forse si potrebbe effettivamente lasciare. Poi concordo che l'admin che blocca potrebbe/dovrebbe far lui la richiesta.--Kirk Dimmi! 15:06, 4 set 2022 (CEST)
replies: text:  personalmente non la vedo come una punizione, anzi se l'attacco arriva da parte di un'utenza flaggata che viene bloccata per quello, credo che la cosa sia ancora più grave :) --Mtarch11 (msg) 15:21, 4 set 2022 (CEST)
replies: text:  Ehhhh, se guardi i log dei blocchi puoi constatare che avremmo già qualche admin in meno rispetto agli attuali ;) Comunque, se posso essere d'accordo che un blocco di qualsiasi genere possa essere grave per un admin (anche se comunque continuo a pensare che si debba valutare da situazione a situazione), per un autoverificato ci sono blocchi che non fanno minimamente perdere la fiducia nelle sue azioni legate a quel flag, la cui perdita peraltro creerebbe più problemi ai patroller che all'utente stesso. Tra l'altro, riottenere un flag non è poi così immediato...--Parma1983 15:37, 4 set 2022 (CEST)
replies: text: Soprattutto l'AV , visto che non può richiederlo lui stesso, non è certo immediato. Il primo che mi viene in mente ha storia lunga di blocchi, ha fatto una mezza EW anche l'altro giorno, ma è ancora AV, ce ne sarebbero allora da controllare perché magari fanno quel che gli pare nelle voci (dove invece gli AV non vengono controllati molto)..--Kirk Dimmi! 18:48, 4 set 2022 (CEST)
replies: text: Certo che è ancora più grave, , ma non per questo si deflagga. Semplicemente a me non va a genio dover perdere tempo nel patrollare le modifiche di uno che sa quello che fa ma che semplicemente gli si è inibita Wikipedia per un periodo perché, ad esempio, ha combinato qualche malanno di natura squisitamente disciplinare.Non perdiamo di vista la ratio delle cose, per favore. --.avgas 19:04, 4 set 2022 (CEST)
replies: text:  non ho perso di vista nulla, grazie, ho solo espresso il mio parere.  speriamo che non abbia altri flag :) comunque, si può benissimo lasciare anche tutto così com'è, appellandoci al buon senso, anche se rimango dell'idea che blocco e AV non siano assolutamente compatibili. --Mtarch11 (msg) 04:29, 5 set 2022 (CEST)
replies: text: Personalmente starei attento ad automatizzare blocco -> rimozione permessi speciali, in quanto la maggior parte dei blocchi di utenti affidabili derivano da screzi in qualche discussione o da qualche comportamento controproducente, raramente legati agli strumenti aggiuntivi forniti. Visto che è stato già citato, il caso di @Demiurgo, è controverso, il blocco sarebbe potuto scattare anche bilateralmente admin/utente visto che i toni sono sfuggiti da entrambe le parti e soprattutto a me pare assurdo che vengano revocati degli strumenti ad un utente affidabile, causa attriti in una discussione specifica, che va avanti da anni e già problematica di suo. Quindi assolutamente per me la rimozione dei permessi deve essere valutata di volta in volta. O.T. infatti non ho capito come mai a pochi giorni dallo sblocco @Civvi abbia rimosso qualunque gruppo a Demiurgo, quando non è previsto da linee guida. --Vgg5465✉ 09:27, 5 set 2022 (CEST)

text: Questa è una pagina di servizio, non un tribunale in cui avanzare arringhe . Il tema deflag in seguito a blocchi è una dinamica squisitamente tecnica su cui la comunità avrà modo di esprimersi, ma rimane un aspetto marginale per il quale non deve esserci alcun effetto psicologico. Se tale effetto esiste, evidentemente è a causa di una mancanza di serenità che deve sempre, inderogabilmente, esserci da parte di tutti.Il rollback può tornare in tempi brevi e con esso l'autoverifica che comunque non influisce certo nel carico generale di lavoro quando riguarda un singolo utente, sempre identificato da un nickname che i patrollatori e altri utenti esperti ben conoscono.Ulteriori messaggi di questo tipo il cui scopo è evidentemente quello di minare la stabilità e la quiete della comunità saranno oggetto di limitazioni.L'ns0 è il nostro obiettivo ed è buon senso farvi ritorno in momenti come questo. Quando si perde l'ago della bussola, sebbene per errori non di per sé legati direttamente al namespace principale, esso è l'unico nord a cui puntare per avallare nuovamente la propria buona fede. --.avgas 10:58, 6 set 2022 (CEST)
thread_title:  Revoca utenze bloccate