Discussioni Wikipedia:Amministratori

Archivio

---

• Archivio 1 (12/2003 — 10/2004)
• Archivio 2 (11/2004 — 06/2005)
• Archivio 3 (01/2006 — 09/2006)
• Archivio 4 (09/2006 — 08/2008)
• Archivio 5 (09/2008)
• Archivio 6 (10/2008 — 12/2008)
• Archivio 7 (12/2008 — 11/2009)
• Archivio 8 (11/2009 — 07/2011)
• Archivio 9 (09/2011 — 10/2011)
• Archivio 10 (10/2011)
• Archivio 11 (10/2011)
• Archivio 12 (10/2011 - 11/2011)
• Archivio 13 (12/2011 - 06/2012)
• Archivio 14 (07/2012 - 06/2015)
• Archivio 15 (12/2015)
• Archivio 16 (03/2017)
• Archivio 17 (03/2017 - 12/2024)
• Archivio 18 ...

---

come archiviare  ·  modifica questa lista

Blocco del mio IP

Buongiorno a tutti, stamane volervo aggiungere sulla mia pagina utente il nome di due persone per le quali vorrei fare la voce in italiano e sorpendentemente non mi è stato permesso perché mi è apparso un avviso che il mio IP era stato bloccato da Jon Kolbert dal 12 novembre 2023 al 12 novembre 2026. Non mi sembra di aver ricevuto nessun avviso, se seguo i link non capisco neanche il motivo. Lavoro senza problemi per wiki con il mio PC e non ho mai avuto problemi. Ancora ieri sera ho fatto dei contributi, il problema è apparso solo stamane. Per scrivervi ho dovuto utilizzare un altro PC perché a quanto pare il problema è legato all'IP non all'utente. E' una cosa stranissima. Avete qualche idea o consiglio? Devo risolvere il problema se voglio continuare a contribuire a Wiki. Grazie a chi vorrà aiutarmi. --Bettylella (msg) 13:27, 8 mar 2025 (CET)

[@ Bettylella] tecnicamente non so perché ma se chiedi anche in WP: OFFICINA e WP:RAA forse avrai risposta più accurata e celere --Il buon ladrone (msg) 13:33, 8 mar 2025 (CET)

Due proposte di snellimento delle procedure di assegnazione e rimozione flag

Ciao a tutti, nell'ottica di snellire le procedure, ho pensato a due proposte (una mi sembra quasi una formalità mentre l'altra secondo me può essere oggetto di discussione, come lo è stato in passato, ma i tempi ora sono più maturi secondo me). Vi chiederei di commentare singolarmente sotto l'apposita sezione. Ecco le proposte:

Proposta 1: Rimozione del flag nei casi previsti da parte dei burocrati senza passare da metawiki

La possibilità di far rimuovere il flag da parte dei burocrati, invece che passare dagli steward su Meta, snellisce la procedura anche in caso di richiesta di deflag per inattività o dimissioni. Attualmente il tutto viene gestito dagli steward non provenienti da itwiki, bisogna fare una richiesta lì, e poi lo steward di passaggio effettua l'azione comportandosi da mero notaio. Tale ruolo imho può essere facilmente svolto dai nostri burocrati, basta creare una pagina per le richieste di deflag, dopodiché sono i nostri a effettuare tecnicamente l'azione. Parlando dal lato tecnico, si tratta di un'inezia, io stesso mi sono occupato pochi giorni fa della stessa richiesta da parte della comunità di Wikipedia in polacco. Bisogna dire che questa possibilità viene concessa solo ai progetti molto grandi, con un numero sufficiente di burocrati attivi, e solo di fronte a un buon consenso. Il nostro progetto rientra nei requisiti di base, ora serve solo un consenso, secondo me non ha molto senso dover passare da meta quando i nostri burocrati possono farlo direttamente. Rimane ovvio che i criteri di rimozione non cambierebbero in alcun modo, e che le richieste di dimissioni avrebbero sempre il tempo di attesa di 24 ore, non ci sarebbe nulla di nuovo da questo punto di vista tranne il fatto che la richiesta verrà inserita e archiviata su itwiki (inclusi i log dei deflag che al momento risultano su meta). Attualmente i progetti in cui i burocrati rimuovono il flag di admin, anziché fare il passaggio ultroneo su meta, sono diversi (per citarne alcuni: bawiki, dewiki, frwiki, enwiki, enwiktionary, fiwiki, huwiki, plwiki, ptwiki, simplewiki, ruwiki e altri). Chiedo un vostro parere a riguardo! --Superpes15^(talk) 13:55, 15 apr 2025 (CEST)

• Favorevole Pensavo sinceramente che il passaggio tramite mediawiki fosse un obbligo per qualche policy globale, se è possibile fare in locale e mettere un po' al lavoro i nostri burocosi, tanto meglio.--Friniate ✉ 14:13, 15 apr 2025 (CEST)
• assolutamente sì, se uno è in grado di dare un flag allora è in grado pure di toglierlo --Mastrocom </> void ClickToInbox(); 14:15, 15 apr 2025 (CEST)
• Favorevole Quoto Friniate. --Phyrexian ɸ 14:22, 15 apr 2025 (CEST)
• Favorevole In effetti non capivo perché i burocrati potessero assegnare il flag ma non toglierlo.--Mauro Tozzi (msg) 14:38, 15 apr 2025 (CEST)
• Favorevole--Parma1983 14:42, 15 apr 2025 (CEST)
• Favorevole--Pierpao (listening) 15:57, 15 apr 2025 (CEST)
• Favorevole --Amarvudol (msg) 18:13, 15 apr 2025 (CEST)
• Favorevole --Ombra 18:28, 15 apr 2025 (CEST)
• Favorevole --Atlante (msg) 18:59, 15 apr 2025 (CEST)
• +1. pequod•••talk 19:04, 15 apr 2025 (CEST)
• Commento: Se non sbaglio l'ultima volta che era stata fatta questa discussione, poi chiusa con un non fatto, le motivazioni contro erano per mantenere una qualche "terzietà" passando per gli steward, soprattutto per eventuali deflag problematici. Nessuno dei casi previsti per la revoca mi sembra però possa essere problematico: sia dimissioni o decadenza per inattività, ma anche mancata riconferma o pure la revoca mi sembrano casi abbastanza netti, in cui o c'è una votazione o un'inattività oggettiva basata sulla policy. Non so quindi se il caso del deflag "di emergenza" per admin impazzito o account hackerato sia mai successo o anche solo possibile. Se sì, forse questo è l'unico caso in cui la "terzietà" potrebbe essere utile, anche per non far assumere ai burocrati nessuna "responsabilità". --PercyMM (msg) 19:47, 15 apr 2025 (CEST)

  @PercyMM un admin impazzito può essere bloccato é reso inattivo da qualsiasi admin come un qualsiasi altro utente, poi si deciderà il da farsi. Peraltro tra gli amministratori ci sono due steward più un terzo steward di lingua italiana é quasi sempre disponibile a portata di chat, questo nell'ipotesi fantascientifica che un amministratore perda completamente il senno e in qualche ipotesi che neanche riesco a immaginare ci sia tutta questa urgenza di deflaggarlo. Quindi anche nel mondo della fantasia più sfrenata siamo blindati. --Pierpao (listening) 20:42, 15 apr 2025 (CEST)

  A differenza di prima gli admin non possono più sbloccarsi. --Pierpao (listening) 20:43, 15 apr 2025 (CEST)

  Ricordo che un admin bloccato può comunque bloccare (solamente) l'admin bloccante. Deflag per emergenza mi sembra una cosa fuori dal comune, parliamo sempre di casi limite ed estremi, e comunque in caso di seria emergenza gli steward sarebbero autorizzati a intervenire ovunque (cosa che non succede praticamente mai visto che le comunità riescono ad autogestire il tutto facilmente). Gli steward, per quanto terzi, sono totalmente estranei alle questioni comunitarie, lo so perché io stesso ho assegnato e revocato un sacco di permessi in progetti esterni, limitandomi ad applicare le policy locali o il mero consenso senza scandagliare oltre. Tra l'altro, stessa cosa fanno i burocrati, prendono atto della situazione e agiscono di conseguenza. Il caso di de-sysop per emergenza imho rimane comunque vincolato agli steward, visto che non è affatto previsto dalla nostra policy e i burocrati locali non sono tenuti a prendersi questa responsabilità fuori dai casi previsti dalla policy di deflag, nel frattempo si potrebbe comunque bloccare un admin "impazzito" e aprire una richiesta di revoca come da nostra procedura se non viene richiesto (o viene negato) l'intervento di uno steward. --Superpes15^(talk) 21:07, 15 apr 2025 (CEST)

  Favorevole Ringrazio @Pierpao e @Superpes per i chiarimenti. Direi che possiamo gestire internamente tutte le possibili situazioni e anzi, effettivamente meglio che il consenso nelle varie situazioni venga valutato da un burocrate interno piuttosto che da uno steward non italofano e dunque non addentro alle varie politiche e situazioni. --PercyMM (msg) 21:31, 15 apr 2025 (CEST)

• Favorevole anche per me questo era uno dei grandi misteri :-) --ValterVB (msg) 22:20, 15 apr 2025 (CEST)
• Anch'io, come Friniate, ero convinto che il passaggio dagli stewards di Mediawiki fosse inderogabile per cui, in passato, mi sarei detto favorevole a portare in casa questo potere.

Purtroppo sei mesi fa, dopo che, su mia segnalazione, un sysop era stato deflaggato per inattività, un nostro burocrate, valutando male le azioni fatte dal sysop, gli ha riassegnato il flag e solo dopo l'intervento dello steward di Meta ha fatto un passo indietro. In conseguenza di ciò, ritengo opportuno lasciare ancora questa facoltà agli steward di Meta. --Antonio1952 (msg) 23:03, 15 apr 2025 (CEST)

Uhm, secondo me una piccola svista in totale buona fede, dovuta tra l'altro al fatto che il tool ragiona sul funzionamento di base di flag, e il suppressredirect viene considerato un permesso di base in mano ai sysop, poi esteso nei vari progetti a tanti altri gruppi utente (patroller, rollbacker, mover nel nostro caso, traduttori, ecc.) non può cambiare molto! La stessa svista sarebbe potuta accadere a uno steward, ed è successo più di una volta che qualche steward togliesse per poi ridare il flag immediatamente (malgrado ciò sia in teoria vietato dalle policy), io stesso ho consigliato a un altro di steward di farlo una volta, diciamo che è quella linea di flessibilità e buon senso che rimette le cose a posto dopo una piccola cavolata, non rimanendo burocraticamente attaccati alle regole. Con ciò non voglio far cambiare idea, anzi, rispetto totalmente il tuo parere pur ritenendo sproporzionata la reazione al singolo e unico fatto --Superpes15^(talk) 00:43, 16 apr 2025 (CEST)

• Su questa Favorevole, non ho mai capito perché se un admin vuole dimettersi debba andar su meta..--Kirk Dimmi! 01:28, 16 apr 2025 (CEST)
• Favorevole: in caso di (raro) errore nell'assegnazione di un flag, lo stesso errore potrebbe essere corretto da un altro burocrate --Mtarch11 (msg) 03:41, 16 apr 2025 (CEST)
• Favorevole --Smatteo499 chill!⭐⭐ 15:10, 16 apr 2025 (CEST)
• Favorevole --Geoide (msg) 15:48, 16 apr 2025 (CEST)
• Favorevole --SuperSpritz^{l'adminalcolico} 16:11, 16 apr 2025 (CEST)
• Commento: Visto che il consenso appare schiacciante, penso che si possa procedere a richiedere lo spostamento in locale.--Mauro Tozzi (msg) 20:22, 20 apr 2025 (CEST)
• :[@ Superpes15]--Mauro Tozzi (msg) 08:18, 10 mag 2025 (CEST)

---

Fatto, ho aperto il ticket T394752. --M/ 11:15, 20 mag 2025 (CEST)

Aggiungo che il ticket è stato chiuso oggi, ho verificato che la funzione richiesta è attiva. --M/ 16:58, 29 mag 2025 (CEST)

[@ M7] Allora dovresti comunicarlo anche sul Wikipediano.--Mauro Tozzi (msg) 14:28, 31 mag 2025 (CEST)

[@ Mauro Tozzi], l'ho scritto anche lì. Quando hai un attimo verifica che non ci siano ancora in giro rimandi alla vecchia procedura su meta.wiki. Grazie, --M/ 15:18, 31 mag 2025 (CEST)

Proposta 2: Riassegnazione del flag da parte dei burocrati in caso di rimozione per inattività non WP:CLOUD

Tale proposta mira a velocizzare la riassegnazione del flag nei casi di decadenza per inattività. Mi sembra illogico che un admin decaduto, che rientra poco dopo possedendo ancora la fiducia della comunità, e che quindi non ha alcun problema a riavere il flag da parte della comunità, debba ripassare da tutta la trafila classica (candidatura + elezione, porterei il mio esempio nel 2022, candidatura poco dopo il deflag). Personalmente, in questi casi, ritengo che la procedura classica vada anche ad alterare il quorum, perché è molto più facile avere più voti favorevoli, e quindi un innalzamento del suo valore. Proporrei che, nei casi in cui un admin venga rimosso per inattività (quindi 6 mesi di inattività), lo stesso admin possa fare richiesta di riassegnazione del flag entro i 6 mesi successivi al deflag. Qualcuno potrebbe obiettare che così l'inattività massima si sposta a un anno, ma non è affatto così, perché si aggiunge semplicemente un periodo di transizione senza flag che consente la richiesta di riassegnazione. La richiesta verrà processata dopo 7 giorni da un burocrate nel caso in cui non vi siano pareri discordanti della comunità riguardo alla singola richiesta, nel qual caso si dovrà passare dalla procedura standard, con una nuova candidatura. I burocrati possono anche respingere la richiesta prima dei 7 giorni e anche in mancanza di commenti contrari, chiedendo all'utente in questione di passare nuovamente dalla procedura classica, nel caso in cui ritengano che l'inattività sia avvenuta in seguito a circostanze o discussioni controverse sull'operato dell'admin (si veda WP:CLOUD). Che ne pensate? --Superpes15^(talk) 13:55, 15 apr 2025 (CEST)

• ha senso --Mastrocom </> void ClickToInbox(); 14:25, 15 apr 2025 (CEST)
• Favorevole Commento: io sono strafavorevole ma non so quanto sarebbe gradita alla comunità che spesso ha votato contro gli amministratori solo perché erano stati poco attivi anche se non decaduti--Pierpao (listening) 15:57, 15 apr 2025 (CEST)

  Ritengo stia alla sensibilità dell'admin, che dovrebbe essere equilibrato nel capire se è realmente disponibile a tornare attivo nei mesi successivi o meno. Essendo stato sia tra quelli che sono decaduti (e subito dopo sono rientrati) così come tra quelli che non hanno supportato gli admin inattivi, penso di poter dire che diventa una pura formalità chiedere il flag dopo un breve periodo di inattività, quindi la procedura mi sembra più logica così nei primi 6 mesi. Fermo restando che un admin che riacquisisce il flag e non poi non torna attivo non penso avrà una riconferma tranquilla, giustamente la fiducia va anche meritata --Superpes15^(talk) 16:13, 15 apr 2025 (CEST)

<si scherza>Ma prima di infliggere tutta questa enorme e spropositata massa di lavoro in più ai burocrati qualcuno ha chiesto ai burocrati cosa ne pensano i burocrati? Eh? Eh? -- Rappresentanza sindacale buro-unitaria 14:42, 15 apr 2025 (CEST) </si scherza (ma non troppo)>

Sindacato per i diritti dei burocosi In realtà la proposta è a favore dei diritti dei burocrati, perché con quelle 2-3 azioni in più l'anno (e forse nemmeno tutti gli anni) nessuno potrà più dire che lo stipendio da burocrate è rubato, poi discutiamo di un eventuale aumento dello 0,0000001% :P --Superpes15^(talk) 14:47, 15 apr 2025 (CEST)

• Rispetto alla corretta obbiezione di Pierpao sono dell'idea che chi non gradisce gli admin poco attivi possa vedere con favore l'iniziativa, proprio perché permetterebbe agli admin di operare più armonicamente rispetto ai propri cicli in RL. Cmq sono favorevole. pequod•••talk 19:08, 15 apr 2025 (CEST)
• la proposta è interessante e condivido anche il successivo commento di Superpes. Ho una proposta alternativa/integrativa che lancio. Si potrebbe pensare che l'admin che si aspetta un'inattività o che si ritrova inattivo può chiedere la sospensione del flag per un tempo definito od indefinito. Anche in questo caso i burocrati vaglierebbero la richiesta per evitare casi di inattività/sospensione del flag legata a circostanze o discussioni controverse. Il flag verrebbe restituito allo scadere del tempo concordato oppure verrebbe rimosso se l'admin permane in inattività. Chiaramente, si possono aggiungere delle semplici regole per evitarne l'abuso e per rimettere alla comunità la riassegnazione del flag in casi specifici. Penso sia una soluzione valida anche per chi voglia prendersi un momento di stacco o per chi si ritrova inaspettatamente a non poter contribuire. --Atlante (msg) 19:19, 15 apr 2025 (CEST)
• Favorevole Mi sembra una proposta di buon senso. In caso un admin decada per inattività e poco dopo rientri a regime e valuti di avere nuovamente tempo da dedicare alla comunità passare per candidatura ed elezione è un po' un avvitamento. Direi che comunque la comunità ha il filtro della riconferma successiva, in cui valutare se effettivamente l'attività è ripresa, se l'admin è rimasto "sul pezzo" nonostante l'inattività ecc., oltre al filtro iniziale dei burocrati, e di eventuali pareri, in fase di richiesta. Unico dubbio: @Superpes15 stavi pensando la cosa riferita solo ad admin decaduti per inattività o anche a quelli che si sono dimessi spontaneamente (sempre fuori dall'ipotesi di WP:CLOUD)? --PercyMM (msg) 21:36, 15 apr 2025 (CEST)

  Io, per non complicare le cose, per ora mi limiterei al deflag per inattività. Poi, in caso, se approvata vediamo se si può estendere ad altre casistiche (tipo deflag temporaneo per motivi di viaggio all'estero, per ragioni di sicurezza, per esempio). Sulle dimissioni manterrei un certo tempo di attesa personalmente. La proposta attuale verte solo sull'inattività comunque. --Superpes15^(talk) 00:33, 16 apr 2025 (CEST)

• Quindi se ho capito bene la domanda di riassegnazione sarebbe pressoché identica ad una riconferma tacita (anche come tempistiche) così da verificare la fiducia della comunità? In quel caso Favorevole per i casi di deflag da inattività --AsdaLol 23:48, 15 apr 2025 (CEST)
• [@ Superpes15] ti dispiace elencare alcuni casi pratici dove una nuova candidatura e rielezione (anche per WP:NEVE) abbia creato problemi? Sul quorum no, a mia memoria non è un problema visti i rari casi, cambia poco o niente.--Kirk Dimmi! 01:05, 16 apr 2025 (CEST) P.S. chi non gradisce gli admin poco attivi.. io non li gradisco Pequod, ma ciò non toglie che se tornano attivi, si mettano a disposizione e passino per una normalissima candidatura, non vedo il problema, in quel caso anche fosse una votazione bulgara alla fin fine ha sempre deciso la comunità.

  [@ Kirk39] A dire il vero non lo ritengo un problema, dico che la trovo una procedura macchinosa e burocratica (al limite dell'avvitamento) in questo semplice caso (passano almeno 16 giorni - dalla candidatura e non dal ritorno post-inattività - e bisogna rifare due procedure), nella mia idea il passaggio comunitario c'è comunque e, se ci sono stati problemi o ci sono pareri discordanti/dubbi, si ripassa dalla procedura standard, altrimenti si riassegna il flag in serenità. Più che vederla come un'estensione del flag io la vedo come una nuova procedura snella per ottenerlo nuovamente. Poi vero che i casi magari ora saranno pochi, ma non è detto sarà così in futuro, anzi, ciò imho apre le porte, come ipotizzava anche Atlante sopra in riferimento a un'integrazione, anche a una maggiore tranquillità rispetto un periodo di pausa del singolo admin. D'accordo sul quorum, era una cosa in più, i benefici sono prima di tutto e unicamente nello snellimento della procedura attuale in questo particolare caso. Inoltre da questa procedura imho trarrebbe beneficio anche chi si vede deflaggato, pur essendo stato attivo come contributore negli ultimi 6 mesi, e pianifica di poter usare i tastini nuovamente nel periodo successivo! --Superpes15^(talk) 01:32, 16 apr 2025 (CEST)

• Favorevole alla proposta in sè, però mi trovo Contrario a un periodo di tempo di sei mesi per la riassegnazione "veloce" del flag. Abbiamo avuto diversi casi di azioni "salva-flag" eseguite all'ultimo minuto per evitare la decadenza automatica, credo che non siano comportamenti da incentivare (sebbene non vietati). Penso che un tempo, ad esempio, di due mesi sia più che sufficiente per permettere al sysop che è stato temporanamente assente di poter rientrare senza dover attendere le tempistiche della procedura standard. --Mtarch11 (msg) 03:55, 16 apr 2025 (CEST)

• Favorevole e concordo con il collega qui sopra su periodo un po' più corto per usufruire della riassegnazione... --torsolo 09:20, 16 apr 2025 (CEST)

• Favorevole è una buona idea; anche io rimarrei su max. 2 mesi per la riassegnazione. --DelforT (msg) 11:12, 16 apr 2025 (CEST)

• Incerto non mi convince pienamente questa proposta, ecco perché. Il flag di amministratore è una cosa seria, molto seria: dev'essere la comunità a decidere l'elezione (o la non elezione) di un candidato. In soli sette giorni saranno pochi gli utenti che noteranno questa richiesta. Ritengo che sia più opportuno passare da una nuova candidatura come avviene ora. --Smatteo499 chill!⭐⭐ 15:15, 16 apr 2025 (CEST)

• Più che Incerto sarei Contraria. Un po' come @Kirk39 non vedo tutta la difficoltà a ripassare per una normalissima candidatura: se i deflag sono poco frequenti, o rari, non capisco dove sta il problema, o il perdere tempo... In questo modo è proprio "senza passare dal via". --Geoide (msg) 16:05, 16 apr 2025 (CEST)

• In linea di massima Favorevole ma metterei due varianti: un "periodo finestra" dopo la decadenza inferiore ai sei mesi (tre mesi?) ma soprattutto un limite alle volte in cui questa "riassegnazione dopo inattività" possa essere richiesta, proprio per evitare comportamenti che potrebbero essere scambiati, specie dagli utenti più critici, come una forma di "abuso" di una facilitazione. Diciamo: si può richiedere entro tre mesi e si può richiedere una volta sola. Se si decade due volte di seguito per inattività, forse in quel caso ha senso davvero ripassare per tutta la procedura completa candidatura-votazione.--SuperSpritz^{l'adminalcolico} 16:16, 16 apr 2025 (CEST)

  Sì, davo per scontato valesse per una sola inattività, effettivamente andrebbe specificato. Ok per me sul ridurre la proposta a 2-3 mesi in base all'eventuale consenso. --Superpes15^(talk) 22:47, 16 apr 2025 (CEST)

• Ammetto di non avere (ancora) una posizione definita sul tema. Se da una parte la proposta mi sembra di buon senso, dall'altro mi chiedo se i benefici siano tali da giustificare una deroga potenzialmente divisiva - mettere mano ai privilegi, di qualunque genere, provoca sempre mal di pancia. In altre parole: tolto SuperPes15 - non volermene! - quanti admin decaduti per inattività sono tornati a pieno regime già nei mesi immediatamente successivi? La mia non è e non vuole essere una domanda retorica: così a memoria io non ricordo nessun'altro caso, ma potei sbagliare. Ad ogni modo, proprio perché la proposta è incentrata sull'inattività, concordo con SuperPes15 sulla necessità di una finestra di applicabilità sufficientemente larga. Diciamo la verità: se sei stato inattivo per un intero semestre, è improbabile che la tua situazione cambi drasticamente proprio il settimo mese. All'atto pratico, il compromesso dei 2 mesi rischia perciò di rivelarsi solo un'indesiderata moratoria della decadenza. Per questo motivo, e sempre se del caso, io sarei tentato di estendere questa procedura accelerata di riassegnazione addirittura a 1 anno dal deflag :O --Ombra 23:48, 16 apr 2025 (CEST)

  Un anno dal deflag non si può leggere, quando altri pensano che sia meglio accorciare a un paio di mesi, se stai via un anno ripassi dal via :-P --Kirk Dimmi! 00:17, 17 apr 2025 (CEST)

  Sì, il problema è che riducendo saranno casi unici, mentre come dice giustamente Kirk estendendo si perde il senso, però penso che tipo 2-3 mesi vadano bene anche per chi ha subito il deflag pur essendo rimasto attivo su wiki come contributore senza usare i tastini, magari è interessato a riaverli per utilizzarli realmente, anche in quel caso sarebbe utile come misura. Poi ci siamo abituati a vedere alcune volte le famose azioni "salva-flag", in questo modo si possono evitare, perché l'admin in questione, se interessato e convinto di poter utilizzare i tastini, può richiederli accorgendosi che sono stati rimossi (si riceve comunque mail e notifica). Chiaramente non è una misura che può essere abusata, come dicevamo sopra, ci si aspetta che un admin che gode della fiducia comunitaria capisca questo senza problemi! PS Ma perché la P del mio username in maiuscolo? :O --Superpes15^(talk) 01:17, 17 apr 2025 (CEST)

• Non mi è chiaro questo:«La richiesta verrà processata dopo 7 giorni da un burocrate nel caso in cui non vi siano pareri discordanti della comunità riguardo alla singola richiesta, nel qual caso si dovrà passare dalla procedura standard, con una nuova candidatura». Quindi basta anche solo un parere discordante per passare alla procedura standard? Oppure funziona come una riconferma? --.agrimensore. (msg) 23:50, 16 apr 2025 (CEST)

  Un singolo parere magari di ripicca no, ma queste sono procedure che neanche dovrebbero necessitare di commenti favorevoli imho, è chiaro che se qualcuno porta una situazione concreta per cui si sospetti WP:CLOUD allora si debba passare dalla procedura comunitaria (non ci dovrebbe essere un numero rigido)! --Superpes15^(talk) 01:11, 17 apr 2025 (CEST)

• Non mi pare una necessità. Quando si torna, soprattutto dopo un periodo di pausa, secondo me un po' di rodaggio ci vuole e un passaggio di verifica con la comunità non guasta. --M/ 08:52, 17 apr 2025 (CEST)
• Neutrale da un lato apprezzo il desiderio di risparmiare avvitamenti e tempo-comunità per procedure dall'esito scontato, dall'altro a (pessima) memoria non ricordo una casistica così frequente... --Civvì (Parliamone) 14:22, 17 apr 2025 (CEST)
• Contrario L'idea non mi piace per niente, se un amministratore è decaduto per inattività ridargli i tastini con questa metodica significa solo tentare di aggirare le tempistiche datesi dalla comunità (e se si hanno problemi con esse è meglio ridiscuterle che aggirarle); ricordo, oltretutto, che la comunità quasi 9 anni e mezzo fa su una casistica simile (ma più complessa) non ha esitato a non eleggere l'amministratore, quindi a maggior ragione non ritengo opportuno portare avanti questa proposta. --Gce ★★★+2 00:44, 28 apr 2025 (CEST)
• Ho aspettato a commentare su questa proposta, perché non ne ero troppo convinto. Pensandoci sopra a lungo, concordo in generale con gli ultimi interventi, esprimendomi verso la contrarietà alla proposta. Al limite, per questi casi preferirei una votazione più snella, ad esempio riducendo la durata a una settimana senza quorum (mantenendo solo l'80% dei favorevoli)--Parma1983 02:20, 28 apr 2025 (CEST)
• Contrario Non vedo la necessità di attivare la procedura proposta: chi perde il flag per inattività, ritorna nel plotone degli autoverificati e come tale deve ripercorrere la procedura, dove la comunità lo potrà valutare nei tempi e nei modi canonici. Già ora nelle riconferme ci sono troppe blindature a favore degli admin. --Il Tuchino^{Amo la Pace, non fatemi la guerra!} 05:57, 28 apr 2025 (CEST)

Richieste di revoca

Ora che la funzione è a carico dei burocosi propongo semplicemente di:

1. aggiungere una sezione per la revoca a Wikipedia:Richieste di permessi
2. mantenere le stesse condizioni vigenti su meta, 24 ore di tempo dalla richiesta alla revoca.

Può andare? --Civvì (Parliamone) 18:40, 29 mag 2025 (CEST)

Favorevole --Sannita - L'admin (a piede) libero 18:42, 29 mag 2025 (CEST)

Una "bozza" di quanto scritto da Civvì è già stata messa qui e ho modificato un paio di rimandi a meta. Verificate e integrate se necessario casistica, procedure e grammatica. --M/ 18:45, 29 mag 2025 (CEST)

[↓↑ fuori crono] la bozza di M7 mi pare perfetta. --Civvì (Parliamone) 18:49, 29 mag 2025 (CEST)

+1, per me possiamo copiarla subito. --Sannita - L'admin (a piede) libero 18:51, 29 mag 2025 (CEST)

+1 --Jaqen [...] 18:45, 29 mag 2025 (CEST)

Favorevole --Superchilum^(scrivimi) 18:47, 29 mag 2025 (CEST)

Favorevole--SuperSpritz^{l'adminalcolico} 18:48, 29 mag 2025 (CEST)

Favorevole Ruthven (msg) 18:58, 29 mag 2025 (CEST)

• Favorevole --Atlante (msg) 19:00, 29 mag 2025 (CEST)

+1 --Buggia 20:13, 29 mag 2025 (CEST)

Favorevole. --Phyrexian ɸ 21:11, 29 mag 2025 (CEST)

• Favorevole --Threecharlie (msg) 22:44, 29 mag 2025 (CEST)
• Favorevole --Antonio1952 (msg) 22:46, 29 mag 2025 (CEST)
• Favorevole --Ombra 21:08, 30 mag 2025 (CEST)
• Favorevole --Torque (scrivimi!) 21:12, 30 mag 2025 (CEST)
• ok ok --Elwood (msg) 21:12, 30 mag 2025 (CEST)

[← Rientro] Probabilmente è già stato pensato/fatto. Attualmente BotRiconferme, in caso di esito negativo di una votazione di riconferma, inseriva direttamente la richiesta di deflag su Meta. È stata disabilitata questa cosa o reindirizzata sulla nuova sezione di WP:RP? Pingo [@ Daimona Eaytoy] --PercyMM (msg) 14:17, 31 mag 2025 (CEST)

[@ PercyMM] Grazie per la notifica! Ho aggiornato il bot, inclusi i messaggi e la documentazione. La parte delle richieste su meta rimane, ma limitatamente ai diritti di checkuser e burocrate. Devo precisare anche che non ho eseguito dei test completi per verificare se il codice funziona. Da una parte, al momento non posso eseguirli localmente (né tantomeno voglio farli su meta). Dall'altra, le richieste in oggetto sono talmente rare (per fortuna!) che da ora a quando la funzionalità dovesse servire, c'è una discreta probabilità che qualcosa da qualche parte cambi in modo tale da rompere comunque il bot. --Daimona Eaytoy (Scrivimi!) 17:05, 1 giu 2025 (CEST)

richiesta patrocinio

Buongiorno a tutti!

C'è qualcuno che mi voglia fare da tutore?

Io mi occupo di trasporto aereo e di compagnie aeree. --~2025-28680-62 (discussione) 12:18, 1 nov 2025 (CET)

Figline guarda che questa utenza temporanea l'hai già usata altre volte... --Murray Nozick (msg) 12:30, 1 nov 2025 (CET)

Stranezza

Buongiorno,

Per caso ho aperto la pagina Zingiber officinale e sono stata abbastanza sorpresa di vedere la foto di un uomo giovane inserita nella sezione Descrizione. Ho cliccato sulla foto per accedere a Commons, ma il link non portava a Commons ma una foto del rizoma []. Ho cliccato sulla linguetta Modifica wikitesto per trovare quale potesse essere l’errore. Il codice sembra apposto ([[File:Ginger Root.jpg|sinistra|miniatura|Radice di zenzero]]. Ho cercato un po’ più avanti e ho scoperto che la foto dell’uomo era la prima su questo sito: . Aggiungo che questa foto appare quando uso sia Firefox sia Safari, ma non quando uso l’app wikipedia. Mistero totale. Come si può rimediare? Saluti, —Msbbb (msg) 20:01, 5 gen 2026 (CET)

[@ Msbbb] E perché lo chiedi qui e non ai progetti Forme di vita o Cucina?--Mauro Tozzi (msg) 09:48, 16 gen 2026 (CET)

[@ Mauro Tozzi] già risolto proprio al DP:Forme di Vita: Discussioni_progetto:Forme_di_vita#Stranezza. --Syrio posso aiutare? 15:09, 16 gen 2026 (CET)

Richiesta di info e segnalazione

Salve, non so come funziona nello specifico, ma vorrei segnalare questa discussione e in generale il comportamento dell'utente TrinacrianGolem. Di recente ho iniziato a contribuire alle pagine sul "Medioriente" e ho notato un controllo ossessivo nel mantenere le pagine in un certo modo (a parte le situazioni di palese vandalismo in cui ci sta il rollback diretto e stop), anche in casi in cui la modifica di turno trovasse un consenso a seguito di discussione (esempio emblematico questo, condannato alle sabbie mobili della discussione eterna).

Nel caso specifico, era stato inserito da un IP nell'infobox di Guerra Israele-Hamas la specifica che l'ultima tregua fosse stata violata, modifica prontamente annullata da lui per "POV, fonte debole e decontestualizzato". Ora: 1) non so come sia possibile il fatto che la violazione acclarata di una tregua possa essere POV, 2) non era decontestualizzato ma semplicemente una frase inserita nell infobox, al massimo avrebbe potuto contestualizzare lui nella voce; 3) essendo un problema di fonte debole, ho poi provveduto ad inserire io stesso una fonte aggiuntiva (Aljazeera).

Segue un suo secondo rollback con la motivazione "POV, fonte poco autorevole e fuorviante". Ora si aggiunge il "fuorviante", anche se non vedo cosa ci possa essere di così fuorviante nel constatare una violazione di un cessate il fuoco. Questa è la prima volta che ripristina la mia modifica, dunque come da prassi gli chiedo spiegazioni in talk.

A quel punto l'IP (che lui crede sia sempre io: "ricordandoti anche di loggarti quando fai modifiche") ripristina la modifica aggiungendo una fonte OHCHR, che quindi doveva eliminare il problema sulle fonti, essendo agenzia delle Nazioni Unite. Segue invece un ulteriore rollback, in cui vengono anche coinvolte delle modifiche parallele di un altro IP sull'aggiornamento della sezione perdite dell'infobox. Di conseguenza mi metto a lavoro sulla sezione perdite, aggiornandola agli ultimi dati ufficiali disponibili, usando direttamente la funzione annulla e quindi ripristinando anche la parte sul cessate il fuoco. Tanto basta per chiamare alla EDIT WAR e lasciarmi il cartellino giallo in talk.

Ah ci tengo a precisare che in tutto ciò io avevo aperto una discussione anche nella talk della stessa pagina. Tuttavia, in assenza di motivazioni consone o proposte alternative e in attesa di consenso, non vedo perché debba essere mantenuta la versione precedente (dove non c'è scritto che la tregua è stata violata) piuttosto che quella con la specifica, la quale è corredata da fonti autorevoli e risulta soprattutto più informativa (in quanto scrivere che c'è un cessate il fuoco fa presupporre al lettore che siano cessate effettivamente le operazioni militari, cosa che invece non è accaduta nella realtà).

Grazie a chiunque si interesserà e deciderà di spendere del tempo per contribuire a sciogliere questi nodi in modo imparziale e metodico. --Astubudustu 14:27, 13 mar 2026 (CET)

gli amministratori non hanno e non devono avere alcun ruolo di merito. Prova a coinvolgere un progetto --ignis scrivimi qui 15:30, 13 mar 2026 (CET)

Nell'ordine:

• non comprendo quale possa essere il senso di scrivere qui - talk di pagina di servizio, laddove - com'è noto - gli amministratori in quanto tali non hanno particolari attribuzioni redazionali;
• nel merito ho segnalato sia in campo oggetto che, successivamente, scrivendo sulla talk dell'utente, cosa non andasse bene nella modifica da lui inserita ossia che il template sinottico {{conflitto}} è chiamato a riportare dati salienti e non dettagli, che in specie - come attestato da fonte autorevolissima (Britannica) - il "dato saliente" fosse che il cessate-il-fuoco di ottobre 2025 sia ancora lì vigente, che la fonte impiegata (l'Indipendente) fosse tutt'altro che terza e autorevole, ecc...
• basta controllare le cronologie per accorgersi che sia i messaggi che l'annullamento che infine il cartellino giallo seguono alla reiterazione delle modifiche da parte dell'utente, che stava andando in edit-war;
• evito, non essendo questa la sede idonea, di addentrarmi sull'esame di altra questione editoriale sulla medesima voce, limitandomi a rappresentare come proprio lo scrivente abbia cercato, aprendo apposita discussione sulla talk della voce, di addivenire a soluzioni condivise e comunque aderenti a fonti e criteri di neutralità;
• in ogni caso, in questo caso come in altri a prova di smentita, lo scrivente ha agito da utente e nel pieno rispetto dei pilastri e delle linee guida. Paventare perciò, scrivendo impropriamente qui, inesistenti abusi delle funzioni di servizio è del tutto gratuito.--TrinacrianGolem (msg) 15:39, 13 mar 2026 (CET)

Modifica della procedura

@Superspritz, da dove si evince il consenso a questa tua modifica della linea guida? --Antonio1952 (msg) 21:36, 15 mar 2026 (CET)