Discussioni Wikipedia:Richieste di permessi

• Discussioni Wikipedia:Autoverificati/Abilitazioni
• Discussioni Wikipedia:Rollbacker/Abilitazioni

Aggiungere le richieste per il flag di convalidato

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)

Già. Ma se attribuissimo il permesso per l'assegnazione del flag direttamente agli admin?... --Lucas ✉ 00:07, 14 set 2017 (CEST)

Io son d'accordo, ma non so se poi da meta la possano considerare "troppa libertà"... Martin ^(scrivimi) 14:49, 14 set 2017 (CEST)

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)

Quante richieste di convalida sono state fatte finora? --Vito (msg) 18:10, 15 set 2017 (CEST)

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)

[× Conflitto di modifiche] 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)

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)

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)

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)

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)

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)

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)

[← Rientro] Anche se forse le richieste sono e saranno bassissime il fatto che sia abilitata anche agli admin la possibilità di assegnare il flag potrebbe essere utile e portare qualche vantaggio. Inoltre non è che abilitandolo agli admin, Wikipedia corra rischi mortali a causa dei vandali :-) --Samuele2002 (Chiedi pure!) 21:50, 17 set 2017 (CEST)

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)

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)

Tiriamo le somme?

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)

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)

Non ritengo corretto avere dei criteri aggiuntivi segreto di Pulcinella che non sono ufficializzati, pertanto sono Fortemente favorevole 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)

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)

Favorevole, però poi non esageriamo con gli avvitamenti burocratici--Ferdi2005 _(Posta) 15:00, 27 set 2017 (CEST)

Contrario 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)

[× Conflitto di modifiche] Io lascerei le cose come sono, caso per caso, valutando le opinioni. E' un flag tecnico, all'utente non cambia nulla e non ha funzioni aggiuntive (a differenza per esempio del mover e dell'admin), non è un attestato di stima né di merito ma una cosa che serve esclusivamente a chi patrolla. Quindi una certa attenzione ci sta. Non mi metterei ad aggiungere criteri, ma manterrei l'attenzione di cui parla Hypergio. --Lucas ✉ 16:14, 27 set 2017 (CEST)

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)

Quoto Lucas parola per parola. --Retaggio (msg) 18:01, 27 set 2017 (CEST)

@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)

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)

Wikipedia:Oversight

Salve a tutti, ho notato l'esistenza del gruppo utente Wikipedia:Oversight e visto le mie innumerevoli richieste di pulizia della cronologia, potrebbe essermi molto utile. Quindi volevo sapere se è possibile candidarsi per tale flag o se ormai non si usa più. Distinti saluti --NewDataB (msg) 15:09, 21 dic 2018 (CET)

Temo tu abbia frainteso, quella funzione è, diciamo così, ancora superiore a quella degli amministratori locali, tanto è vero che è scritto esplicitamente sulla Wikipedia in lingua italiana non sono presenti utenti con funzioni di oversight e di rivolgersi agli steward per quei rarissimi casi in cui serva effettivamente :-)

Quella funzione non è per la pulizia di cronologie ma proprio per cancellazioni "profonde" e per i casi indicati in fondo ala pagina :-) Ciaooo --Pil56 (msg) 18:14, 21 dic 2018 (CET)

ahhh, non avevo capito niente, mio svarione :) --NewDataB (msg) 18:31, 21 dic 2018 (CET)

Archiviazione automatica

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)

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)

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)

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)

Richieste di flag temporanei

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)

Mi sembra una buona idea. Per quanto mi riguarda sono d'accordo. --НУРшЯGIO^{(attenti all'alce)} 22:04, 13 mar 2019 (CET)

+1 questa pagina nasce proprio per non disperdere l'assegnazione dei vari flag --Ombra 22:29, 13 mar 2019 (CET)

+1 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)

+1 idem come i precedenti. --Epìdosis 12:00, 14 mar 2019 (CET)

[↓↑ fuori crono] Come sopra. --Dimitrij Kášëv 13:41, 15 mar 2019 (CET)

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)

[@ Pierpao] 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)

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)

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)

Ordine delle sezioni

Ma c'è un ordine nelle sezioni che a me sfugge altrimenti mettiamole in ordine alfabetico altrimenti ancora, ihmo meglio, metterei in fondo esenz. blocco ip, autocovalidati e creatori di utenze ovverosia quelli meno richiesti e in cima quelli più richiesti--Pierpao.lo (listening) 19:25, 14 mar 2019 (CET)

Immagino che inizialmente fossero messere circa in ordine alfabetico e poi gli altri ruoli sono stati messi dentro in ordine +/- casuale. L'ordine attuale non mi urta, comunque. Alla fine è circa in ordine di frequenza di utilizzo. --Torque (scrivimi!) 22:48, 14 mar 2019 (CET)

Circa :) salvo gli esenti ip messi prima dei mover e gli autoconvalidati prima dei Bot. Entrambi praticamente mai utilizzati. Comunque non mi urta l'ordine semplicemente si perde tempo a scorrere tutta la pagina per vedere tutte le procedure più utilizzate. Se si mettono in fondo quelle meno utilizzate si fa prima :)--Pierpao.lo (listening) 11:19, 15 mar 2019 (CET)

Non vedo un particolare vantaggio nel preferire l'uno o l'altro ordine (da desktop, quantomeno, basta cliccare la sezione sull'indice), ma volendo scegliere un criterio e pensando anche a chi consulta la pagina da mobile per me va bene riorganizzare le sezioni in ordine di "maggior richiesta": Autoverificati, Rollbacker, Mover, Creatori di utenze (in questo ordine), e poi tutto il resto in ordine anche casuale; magari lasciando i Bot in fondo, visto che la pagina apposita è un'altra. --goth nespresso 15:17, 15 mar 2019 (CET)

Concordo con Goth nespresso; basandosi sul numero di richieste, l'ordine indicato sembra essere quello più consono. --Scalvo98 (🏎🏎) 13:59, 16 mar 2019 (CET)

+1 su Goth nespresso. --Epìdosis 14:32, 16 mar 2019 (CET)

Favorevole anch'io; per completezza, metterei: Autoverificati, Rollbacker, Mover, Creatori di utenze, Esenti dal blocco IP, Amministratori dell'interfaccia, Convalidati e infine Bot--Parma1983 15:40, 16 mar 2019 (CET)

+1 ok, ma i flag temporanei? --Ombra 16:05, 16 mar 2019 (CET)

Ok, giusto: a parte che li rinominerei "Amministratori temporanei" per evitare ambiguità con gli altri flag, si potrebbero mettere dopo gli amministratori dell'interfaccia--Parma1983 16:10, 16 mar 2019 (CET)

Ho messo giù una bozza per la testata; sentitevi liberi di modificare come volete. Ho aggiunto il requisito di AV, e una durata massima del flag; a me sembrano punti necessari, ma se non c'è accordo al riguardo tirate via. Ciao!--Equoreo (msg) 17:14, 16 mar 2019 (CET)

Bisognerebbe aggiungere che la soppressione del redirect quando si effettua uno spostamento è eseguibile solo dai Mover --NewDataB (msg) 17:31, 16 mar 2019 (CET)

[@ Equoreo] mi sembra perfetto. Mi sono permesso di fare alcune limature sulla forma. Assurdo comunque che i mover mantengano anche il flag di AV nonostante l'AV sia tra i requisiti per diventare mover (cosa che giustamente non avviene per i rollbacker). Già che ci siamo, correggiamo anche questa sovrapposizione? --Ombra 17:55, 16 mar 2019 (CET)

[@ Ombra, Equoreo] Aggiungerei due altre limitazioni:

• di assegnazione delle funzioni di autoverificato agli utenti;
• di autoassegnazione delle funzioni di flood editor.--Parma1983 18:15, 16 mar 2019 (CET)

Condensandola in "di modificare i diritti degli utenti, sia propri sia altrui"? --Ombra 18:18, 16 mar 2019 (CET)

[@ Ombra] Sì, infatti, avrei voluto condensare anch'io, ma avevo distinto perché non ero sicuro al 100% della seconda--Parma1983 18:22, 16 mar 2019 (CET)

[× Conflitto di modifiche]Sì, vanno aggiunte tutte le variazioni di diritti, anche se permetterei (opinione personale) l'uso del flood (tanto più che questo flag va usato in casi massicci, quindi a maggior ragione da flood). In linea di principio ha anche ragione NewDataB sui mover.

[@ Ombra] Quella asimmetria rollbacker/mover mi ha sempre dato molto fastidio, ma potendo scegliere opterei per togliere il flag autopatrolled anche dal gruppo rollbacker... Preferisco più flag spezzettati, dosabili a piacimento, piuttosto che pochi gruppi utente con decine di flag. Esempio: se uno ha bisogno di un flag temporaneo per oscurare la cronologia, perché dobbiamo dargli tutti i poteri degli admin?! --Equoreo (msg) 18:31, 16 mar 2019 (CET)

[@ Equoreo] Sul flood editor infatti sono leggermente incerto, anche se tenderei ad escluderlo: infatti, se da un lato concordo con te, dall'altro, considerando che è la funzione per la quale è necessaria la maggior fiducia da parte della comunità, credo che sia meglio resti prerogativa dei soli amministratori "stabili". Sull'ultima considerazione, in linea di principio sono d'accordo con te, ma temo che troppi flag finirebbero per creare solo del caos; sull'asimmetria, per me l'importante sarebbe eliminarla, anche tra le due se sarei più per la proposta di [@ Ombra]--Parma1983 18:42, 16 mar 2019 (CET)

Io onestamente tutta la parte finale dei divieti la toglierei, scriverei meglio che al di fuori dell'incarico è vietato utilizzare qualsiasi diritto ottenuto col flag, perchè per esempio vi siete dimenticati la cosa più delicata, andare a guardare negli oscuramenti fatti da altri e chissà cosa altro. Si tratta di un incarico di estrema fiducia non deve neanche ipotizzarsi che non sia chiarissimo al candidato cosa può e cosa non deve fare. Non mi affiderei certo ad un quadretto. Secondo punto, un precisazione, scriverei: "il candidato deve essere già autoverificato oppure con diritto presente o passato di rollbacker". I casi più frequenti di assegnazione sono stati ad ex amministratori. Qualcuno mi spiega questa cosa dell'asimmetria per favore che mi sfugge?--Pierpao.lo (listening) 18:47, 16 mar 2019 (CET)

Il flood editor sarà permesso solo ce ne sarà necessità assoluta--Pierpao.lo (listening) 18:49, 16 mar 2019 (CET)

[@ Pierpao] Un rollbacker perde il flag di autoverificato, mentre un mover lo mantiene--Parma1983 18:52, 16 mar 2019 (CET)

[← Rientro] Non è solo la pagina del progetto Cococo a essere obsoleta, ma anche l'assegnazione temporanea del flag di admin. Nelle rarissime circostanze in cui sia necessario un intervento veloce o nessun admin sia in grado di svolgere un dato lavoro, i burocrati sono già in grado di decidere quando e a chi concedere diritti temporanei di propria iniziativa.--Sakretsu (炸裂) 18:54, 16 mar 2019 (CET)

Si certo sembra strano, ma forse è stato stabilito così perchè è più comodo per i patroller vedere a quali utenti viene annullato un edit però la stessa cosa andrebbe estesa anche agli amministratori che senso ha mezzi si e mezzi no. Oppure al contrario non dovrebbero perdere il flag neanche i rollbacker. Bisognerebbe chiedere a chi lo ha stabilito perchè.--Pierpao.lo (listening) 19:00, 16 mar 2019 (CET)

Quello che sice Sakretsu è giusto, si potrebbe benissimo scrivere che decidano i burocrati. Due righe le metterei comunque giusto per evitare mille domande sul come o segnalazioni che "ci siamo dimenticati" qua e là--Pierpao.lo (listening) 19:03, 16 mar 2019 (CET)

[← Rientro] [@ Pierpao] Se vogliamo togliere i divieti nessun problema: è che non volevo essere chiaro ma senza creare una pagina ad hoc (come invece esiste per tutti gli altri flag); però non mi sono dimenticato della visione dei contenuti oscurati: ho scritto "visualizzazione e ripristino delle revisioni cancellate".
[@ Sakretsu] Il flag temporaneo per CoCoCo sarà pure morto con l'introduzione del RevDel, ma a volte capita di averne bisogno per altro (come un paio d'anni fa per gli errori di lint); mi sembra comunque utile avere un luogo unico dove tenere traccia dei flag assegnati.--Equoreo (msg) 19:52, 16 mar 2019 (CET)

FC Si hai ragione Equoreo lo avevi scritto--Pierpao.lo (listening) 03:03, 17 mar 2019 (CET)

Come Equoreo: è un discorso non molto diverso dall'assegnazione del flag di amministratore dell'interfaccia. I burocrati (ma anche il resto della comunità "attiva") sanno benissimo chi sono i possibili candidati. La pagina serve più che altro per tenere traccia --Ombra 21:45, 16 mar 2019 (CET)

Scusate, vedo ora questa discussione. Se proprio si sente l'esigenza di cambiare l'ordine (personalmente non ne vedo la necessità) allora, per questioni di uniformità fra pagine, suggerisco di seguire l'ordine con cui sono elencati i diversi livello di accesso qui: Wikipedia:Livelli_di_accesso_degli_utenti. --Civvì (Parliamone...) 21:57, 16 mar 2019 (CET)

La pagina serve a sentire pareri, non a tenere traccia. C'è differenza tra un flag appioppato a sorpresa da un burocrate come nel caso di WP:REMEX e un flag assegnato su richiesta. Il secondo non si vede da anni e ha tutte le carte in tavola per tramutarsi in uno specchietto per le allodole.--Sakretsu (炸裂) 00:05, 17 mar 2019 (CET)

[@ Sakretsu] tu continui a basarti sulla tua esperienza personale, ma non è detto che quell'occasione (straordinaria) sia la regola. Per esempio, un annetto fa in mailing list si ipotizzava di assegnare il flag temporaneo a un certo utente impegnato in un lavoro noioso e non bottizzabile su una serie di tmpl protetti. Se l'avesse chiesto, probabilmente gli sarebbe stato dato invece che stressare a turno gli admin online. Insomma, la pagina può servire eccome, tanto più se si dovessero "spezzettare" ulteriormente i diritti degli utenti (penso al revdel). L'assegnazione temporanea di questo o quell'altro flag potrebbe diventare ben più frequente --Ombra 08:55, 17 mar 2019 (CET)

[@ Ombra] finché i diritti non saranno divisi, la fiducia richiesta per lavori ordinari non sarà proporzionale, perché nessuno può tenere d'occhio pseudo-admin per settimane. Per quanto si mettano per iscritto termini di uso, la realtà è che oggi non ci sono le condizioni per affidare il flag a chi non si ha nemmeno fiducia che capisca da solo cosa gli sia concesso di fare e cosa no. La procedura diventerebbe una sorta di autocandidatura a admin dal successo ancora più improbabile per via della valutazione dello specifico lavoro che ci si proporrà di fare.--Sakretsu (炸裂) 12:56, 17 mar 2019 (CET)

[@ Sakretsu] sono d'accordo, però non è molto diverso dalla pagina delle candidature ad admin (ma anche a rollbacker o mover). Ci sarà sempre qualche entusiasta che si autocandida alla cieca, ma nel complesso la comunità sembra abbastanza matura da aver capito quando (e perché) richiedere determinate funzioni aggiuntive. Una volta che si è chiaramente esplicitata la straordinarietà dell'evento nell'avviso IMHO non corriamo particolari rischi. O almeno, non più di quanto non succede già oggi. Piuttosto, credo che andrebbe approfondito il ragionamento di Pierpaolo: forse sì, meglio un avviso compatto che riporti che cosa si può fare piuttosto di uno che dettagli fino all'eccesso cosa non si può fare perché induce in tentazione :P Se davvero vogliamo percorrere questa strada credo che la creazione di una pagina di appoggio sui permessi temporanei sia inevitabile :/ --Ombra 13:18, 17 mar 2019 (CET)

[@ Sakretsu] Non ho capito. Remex sta per? --Civvì (Parliamone...) 00:19, 17 mar 2019 (CET)

WP:RemexHTML, la discussione in cui è avvenuta l'ultima assegnazione temporanea del flag di admin. Nemmeno lì c'erano realmente urgenze o necessità, anzi avevamo tempo per fare le cose con molta calma. Il punto è che assegnazioni del genere a discrezione dei burocrati sono spensierate, non hanno l'impronta di una procedura dove un utente in buona fede deve spiegare in cosa il suo aiuto sia tanto necessario da spingerlo a richiedere tutto il mazzo di chiavi.--Sakretsu (炸裂) 01:49, 17 mar 2019 (CET)

[@ Sakretsu] Urgenza o meno che ci fosse, viste le vostre indubbie capacità Vito aveva fatto benissimo ad assegnarvi quel flag temporaneo e d'altra parte siete diventati entrambi admin più che meritatamente dopo pochissimo tempo; tuttavia, considerando il numero ridotto dei burocrati, non è sempre detto che questi partecipino alle discussioni e pingarli apposta per chiedere il flag sarebbe abbastanza inopportuno. Sinceramente dubito che si verificheranno molti altri casi simili, ma, se dovesse mai capitare una necessità come quella ma nessun burocrate partecipasse alla discussione, alla fine dei conti una pagina di segnalazione come questa potrebbe anche servire--Parma1983 02:19, 17 mar 2019 (CET)

Io scriverei un riquardo con un semplice promemoria o due righe nelle istruzioni in cima "I flag temporanei vengono assegnati su decisione dei burocrati a utenti di provata esperienza ed affidabilità in caso di sola urgente necessità" (o scritto come vi pare) e basta, senza prevedere che possano essere richiesti. Se anche questo diventa uno specchio per le allodole si elimina. Se ci sarà necessità si aprirà una semplice discussione al CoCoCo o nel luogo adatto e si segnala in giro. Tutti i rollbacker seguono quanto meno quel progetto. --Pierpao.lo (listening) 03:03, 17 mar 2019 (CET)

[← Rientro] La questione "specchietto per le allodole" non è infondata: il rischio che questa sezione diventi un ricettacolo di richieste irricevibili c'è; resto comunque dell'idea che sia meglio centralizzare le discussioni.
Proposta di compromesso: nei detti casi di necessità i burocrati (e solo loro), a loro giudizio, aprono una sezione dedicata al problema da risolvere, eventualmente pingando coloro che ritengono di candidare; le autocandidature sono ammesse solo nell'ambito di questi "bandi"; se non ci sono problemi aperti, nessuna candidatura può essere fatta.
Pareri?--Equoreo (msg) 09:49, 17 mar 2019 (CET)

Le sezioni degli esenti ip e dei convalidati sono state usate pochissimo, siamo sicuri che abbia senso mantenerle?--Mauro Tozzi (msg) 15:24, 16 ott 2019 (CEST)

E quelle poche volte dove si fanno le richieste? --94.34.151.145 (msg) 20:39, 16 ott 2019 (CEST)

Problema archivio

Ciao, è normale che la funziona "cerca negli archivi" del template {{archivio}} 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)

Immagino perché il template {{archivio}} 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)

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)

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)

Si praticamente quando si sono centralizzate le richieste non si sono centralizzati gli archivi--Pierpao.lo (listening) 18:49, 20 mar 2019 (CET)

Fatto 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)

Requisiti

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)

Favorevole 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)

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)

Favorevole Anche io penso sia opportuno inserirlo come requisito --Dave93b (msg) 14:12, 22 gen 2020 (CET)

Favorevole anch'io--Luke Stark 96 (msg) 14:13, 22 gen 2020 (CET)

Favorevole come Parma.--Luca•M 14:16, 22 gen 2020 (CET)

Favorevole come Parma. --Antonio1952 (msg) 14:29, 22 gen 2020 (CET)

Favorevole quoto Parma --goth nespresso 14:30, 22 gen 2020 (CET)

Favorevole, sono assolutamente d'accordo con Parma.--Ferdi2005_[Posta] 16:19, 22 gen 2020 (CET)

[← Rientro] Mah, d'accordissimo su quasi tutto, però a me sembra un pò strano che per diventare mover (o, se passerà questa proposta, per diventare rollbacker) occorra l'autoverifica, mentre per diventare amministratore non occorra essere autoverificati. Insomma, credo che di fronte a una situazione del genere, i newbies rimarranno un tantino esterrefatti, magari potranno pensare che l'autocandidatura di un utente non-autoverificato possa avere maggiori probabilità di successo se si ambisce direttamente all'adminship anziché ai ruoli di mover/rollbacker. Il che non è propriamente vero.. . --3knolls (msg) 18:29, 22 gen 2020 (CET)

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)

Favorevole 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)

Favorevole--Leo0428 (msg) 20:55, 22 gen 2020 (CET)

Interessante l'appunto di 3knolls, Favorevole ad aggiungere una nota per entrambi i flag. --Dimitrij Kášëv 20:58, 22 gen 2020 (CET)

Favorevole 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)

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)

Favorevole, come Sesquipedale. --GC85 (msg) 00:34, 23 gen 2020 (CET)

Visto che c'è unanimità al riguardo, chi si occupa di aggiornare le pagine?--Mauro Tozzi (msg) 08:49, 24 gen 2020 (CET)

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)

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

• Piccola nota storica da parte mia (oramai utente quasi ritirato da anni): mi fu spiegato (non chiedetemi da chi o quando) che il motivo per cui non bisognava essere AV per diventare amministratore era evitare un meccanismo di cooptazione: cioè, dato che per diventare AV ci vuole l'ok degli admin, mettere un vincolo del genere significa dare agli admin il poter di "bloccare la carriera" di un utente. Oggi non è così: un utente può diventare amministratore senza il consenso dei futuri colleghi, con i burocrati che certificano il consenso della comunità. --Cpaolo79 (msg) 16:11, 24 gen 2020 (CET)

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)

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)

Equiparare Rollbacker e Mover

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)

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 Favorevole ad uniformare anche questo aspetto--Parma1983 15:05, 22 gen 2020 (CET)

Anche io sono Favorevole ad equiparare.--Ferdi2005_[Posta] 16:19, 22 gen 2020 (CET)

Favorevole all'equiparazione --Lemure Saltante sentiamo un po' 16:44, 22 gen 2020 (CET)

Favorevole anche per me, condivido le riflessioni qui sopra --Dave93b (msg) 16:46, 22 gen 2020 (CET)

Favorevole 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)

Contrario 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)

[@ Pierpao] 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)

[↓↑ fuori crono]} 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)

Favorevole completamente.--Mrtb (msg) 17:09, 22 gen 2020 (CET)

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 Favorevole.--☼Windino☼ [Rec] 17:19, 22 gen 2020 (CET)

Favorevole--Leo0428 (msg) 20:55, 22 gen 2020 (CET)

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. Favorevole ad unificarli entrambi al livello di burocrate. --Antonio1952 (msg) 22:34, 22 gen 2020 (CET)

Onde evitare discussioni come questa, anch'io sono Favorevole ad unificarli entrambi al livello di burocrate.--3knolls (msg) 22:41, 22 gen 2020 (CET)

Favorevole --Dimitrij Kášëv 22:53, 22 gen 2020 (CET)

Favorevole, 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)

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)

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. Favorevole anch'io. Apriamo questo phabtask. --.avgas 00:25, 23 gen 2020 (CET)

Favorevole--GC85 (msg) 00:32, 23 gen 2020 (CET)

Fortemente favorevole, sarebbe ora. Anche la durata dell'inattività e la ridondanza con l'AV vanno IMHO equiparate --Ombra 07:19, 23 gen 2020 (CET)

• Favorevole, --Melquíades (msg) 10:40, 23 gen 2020 (CET)
• Favorevole --Epìdosis 12:20, 23 gen 2020 (CET)

Task creato. --.avgas 12:28, 23 gen 2020 (CET)

Modifica effettuata, pagine di servizio aggiornate. --.avgas 10:59, 13 feb 2020 (CET)

Revoca per inattività

Uniformiamo a 6 mesi anche per i Mover (come Admin e Rollbacker)?--Luca•M 18:26, 24 gen 2020 (CET)

Scusa [@ Luca M], 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)

Intendo sei mesi di non utilizzo delle funzioni di Mover.--Luca•M 21:05, 24 gen 2020 (CET)

• Favorevole--Leo0428 (msg) 16:20, 13 feb 2020 (CET)
• Favorevole - anche se le operazioni di mover potrebbero essere meno frequenti rispetto ad altre, penso che in sei mesi debba normalmente capitare più di un'occasione per usare i tasti extra. ×°˜`°×ηαη¢у×°˜`°× 16:58, 13 feb 2020 (CET)
• Favorevole--Parma1983 23:22, 13 feb 2020 (CET)
• Favorevole, --Melquíades (msg) 10:19, 14 feb 2020 (CET)
• Favorevole --Ombra 13:37, 14 feb 2020 (CET)
• Favorevole --Epìdosis 13:41, 14 feb 2020 (CET)
• Favorevole--Sakretsu (炸裂) 13:50, 14 feb 2020 (CET)
• Favorevole --Dimitrij Kášëv 21:48, 14 feb 2020 (CET)
• Favorevole--GC85 (msg) 21:49, 14 feb 2020 (CET)
• Neutrale Per me va bene ridurre a 6 mesi, ma mi va bene anche così. Questo solo se la situazione rimane così com'è. Se nel futuro dovessero diventare più numerosi i mover, non tutti avrebbero "lavoro tecnico da svolgere" (come anche detto in precedenza, le operazioni da mover non sono così frequenti rispetto ad altre), pertanto, secondo me, il tempo si dovrebbe riallungare a 12 mesi. --HominisCon {Scrivimi} 22:30, 18 feb 2020 (CET)
• Favorevole--TriggerOne (msg) 20:20, 19 feb 2020 (CET)
• Commento: Nessuno ha ancora proceduto con la modifica?--Mauro Tozzi (msg) 15:10, 10 mar 2020 (CET)
• Commento: Secondo me per i mover è meglio resti 1 anno, mentre per i rollbacker 6 mesi. Questo perché teoricamente ci sono innumerevoli più vandalismi da rimuovere con un rollback che voci o file da spostare. --Lemure Saltante comitato d'accoglienza! 15:16, 10 mar 2020 (CET)
• Commento: Esiste il rischio che ci si possano inventare voci da spostare per evitare di perdere il diritto utente? Oppure che si tengano da parte voci da spostare per i tempi di magra? --ElleElle (msg) 16:30, 10 mar 2020 (CET) PS tenendo conto del fatto che io non sposterò MAI una voce di un calciatore o di un cantante rap... :-)
• Commento: Mi aggancio al commento sopra di @3knolls, sarei favorevole ai 6 mesi ma inteso come 6 mesi di totale inattività (=zero modifiche in qualsiasi namespace, indipendentemente dall'uso o dal non-uso del flag stesso) --GryffindorD 16:40, 10 mar 2020 (CET)
• Commento: chiedo agli attuali movers, ma ci sono tutte queste voci da spostare su it.wikipedia? a me in quasi 12 anni di attività sarà capitato di incontrarne sì e no una decina... se gli spostamenti sono rari, a me pare che una modifica a sei mesi possa generare effetti deleterei, tipo perdere movers competenti per inattività forzata o costringere i movers a cercarsi col lanternino spostamenti magari non necessari solo per non perdere il flag. --Cavarrone (msg) 09:49, 11 mar 2020 (CET)

  Non mi porrei un problema che non esiste. In Categoria:Spostare si trovano sempre richieste inevase. Al progetto coordinamento si discute ogni giorno di eventuali spostamenti. La manutenzione di questo sito tiene conto di milioni di pagine in costante crescita. In sei mesi chiunque sia attivo 1 voce con titolo errato o inversione di redirect la troverà di sicuro anche senza cercarsela col lanternino, altrimenti la funzione o non gli serve o nelle sue mani, per quanto competenti siano, è di utilità effimera.--Sakretsu (炸裂) 12:46, 11 mar 2020 (CET)

  La proposta di GryffindorD/3knolls mi sembra la migliore, 6 mesi di inattività totale facilitano anche il conteggio per il periodo di decadenza. --Lemure Saltante comitato d'accoglienza! 14:06, 11 mar 2020 (CET)

• Tendenzialmente contrario Non vedo la necessità di restringere così tanto il periodo di revoca, sia perché il ruolo non è così delicato (un rollbacker può cambiare anche in modo rilevante il contenuto di una voce, il mover al massimo il titolo) sia perché, come evidenziato, gli spostamenti ci sono ma non sono così frequenti se non si vanno a cercarli nelle categorie specifiche o si sia creatori di portali (richiedono di spostare molte sottopagine), pertanto può anche essere che limitando così l'inattività ci si ritrovi con 1/4 dei mover attuali senza alcun vantaggio effettivo; potrei essere favorevole, al massimo, a restringere a 6 mesi di inattività totale o 12 mesi senza aver usato le funzioni ma non di certo alla proposta iniziale. --Gce ★★★+4 16:12, 11 mar 2020 (CET)
• Contrario Totalmente d'accordo con Gce, 6 mesi di inattività totale o 12 senza usare le funzioni da mover. Non abbiamo infinite pagine da spostare.--torqua 16:39, 11 mar 2020 (CET)
• Commento: [@ Gce] le azioni di un rollbacker si possono annullare con un click, se invece un mover sposta in maniera arbitrale una voce "grossa" incasina in maniera drammatica categorie e link in entrata, da correggere uno per uno e a mano (si veda il recente caso di Prato). Ad ogni modo, sono indifferente sul termine di decadenza però per motivi di praticità tenderei a equiparare i due flag --Ombra 17:19, 11 mar 2020 (CET)
• Favorevole a equiparare. Chi dice che le pagine da spostare sono pochissime, sbaglia. Quando sono stato mover di lavoro ne trovavo a sufficienza e in modo continuativo. --НУРшЯGIO^{(attenti all'alce P.U.B.)} 17:48, 11 mar 2020 (CET)
• Favorevole se proprio non sapete cosa spostare ci sono migliaia di immagini da spostare al titolo corretto :) --Pierpao.lo (listening) 17:54, 11 mar 2020 (CET)
• Favorevole Anch'io quando ero mover ne trovavo in abbondanza di voci da spostare (talvolta dopo verifica era da annullare lo spostamento), ce ne sono 8 di cui 4 inversioni di redirect anche in questo momento (senza contare i file), e come dicevo nella discussione sopra a questa e come ripetuto da Ombra qui sopra, anche pochi spostamenti talvolta fanno perdere tempo e possono essere delicati (tra puntano qui e rischio di far casini, più lunghi da correggere che dei rb sbagliati).--Kirk Dimmi! 18:01, 11 mar 2020 (CET)
• Commento: quando ho scritto sopra non avevo visto tutti quei contrari comunque se andate qua e mettere una qualsiasi lettera a caso già nella prima pagina che trovate c'è almeno un file da spostare, altrimenti basta un click o due e se ne trovano decine [@ Cavarrone, Lemure Saltante, Gce, Jtorquy]. Volendo si può anche scrivere in WP:Mover--Pierpao.lo (listening) 19:03, 11 mar 2020 (CET)

  Replico al ping, non ero contrario, ponevo solo la questione "quantità" basandomi sulla mia esperienza personale (evidentemente lacunosa, e peraltro pur essendo mover su Commons non avevo pensato agli spostamenti dei file d'immagine). Viste le repliche di Sakretsu, Hypergio, Kirk e tua sarò meno preoccupato. Per il resto non mi spingo a votare favorevole in quanto in generale non trovo di per sè problematico che il detentore di un determinato flag non usi la relativa funzione per 7-8 mesi (magari perchè poco presente in generale) e poi riprenda. Parlo anche per "conflitto d'interesse", visto che su Commons mi sono preso più volte il lusso di prendermi delle lunghe pause senza perdere il flag, e non credo che questo sia stato un grande danno per il progetto. --Cavarrone (msg) 19:49, 11 mar 2020 (CET)

  [@ Pierpao] Quella pagina in realtà dovrebbe elencare tutti i files caricati su it.wiki. Di solito però io guardo la categoria File da spostare, che manco farlo apposta, al momento è vuota - sarà una sfortunata coincidenza. Poi fate vobis. --Lemure Saltante comitato d'accoglienza! 11:03, 12 mar 2020 (CET)

  Io NON sono competente su tutto, quindi il mio campo d'azione è per mia scelta limitato. Tra le numerose voci che ci sono indubbiamente da spostare, o categorie, o file diversi, in molti casi non mi azzardo ad intervenire per non far danni. Meglio perdere il diritto utente che contribuire in un modo per me innaturale. In ogni caso, nulla da dire su qualsiasi decisione verrà presa.--ElleElle (msg) 11:49, 12 mar 2020 (CET)

  Ho dato una rapida occhiata a Speciale:Prefissi ed ho già fatto spostare circa 10 file, e comunque nel giro di 6 mesi si troverà ben qualcosa in Categoria:File da spostare --ValeJappo^『msg』 12:01, 14 mar 2020 (CET)

  Questa però non l'ho capita. Quale sarebbe l'utilità pratica per il Progetto di togliere anticipatamente il flag a utenti che magari sono momentaneamente in pausa, se lavorano bene, come dice Cavarrone sopra - visto e considerato che su it.wiki gli utenti attivi sono pochi? --Lemure Saltante comitato d'accoglienza! 15:30, 14 mar 2020 (CET)

  Effettivamente però è vero, se un utente lavora bene, a nessuno da problemi se è inattivo per un po'. Forse bisognerebbe addirittura "ribaltare" questa proposta e portarli entrambi a un anno di inattività, magari totale e non dell'utilizzo del flag --ValeJappo^『msg』 15:38, 14 mar 2020 (CET)

  Ad equiparare ad un anno entrambi non condivido, mi spiego: i rollbacker fanno un lavoro che IMHO richiede più serenità di quello dei mover, se sono inattivi sul Progetto oltre sei mesi è probabile che non ricordino appieno la WP:Wikiquette. Al tempo stesso, capisco il discorso "discreta inattività = flag non necessario" - ma se si vuol considerare i flag un premio, aggiungo questa proposta: dimezzare il termine di decadenza dei sysop, portandolo a 3 mesi, dato che a rigore di logica un sysop può effettuare molte più attività di sua competenza rispetto a mover e rollbacker.--Lemure Saltante comitato d'accoglienza! 09:41, 15 mar 2020 (CET)

  Cortesemente rimaniamo in topic, stiamo discustendo se equiparare i mover agli altri se si vuole rivoluzionare tutto si apra una altra discussione e si segnali al Bar. Comunque per chi teme che non ci siano pagine da spostare oltre ai file ho aggiunto questo] nella categoria spostare--Pierpao.lo (listening) 19:51, 16 mar 2020 (CET)

  Cortesemente si tenga conto del fatto che non è possibile avere sempre tutte le competenze necessarie su sigle (di una due o più lettere), cantanti, titoli di film e o brani musicali, avvenimenti e personaggi storici, edifici religiosi, militari e civili, eventi sportivi, fatti scientifici, e mi fermo. In altre parole io so muovermi, seppur timidamente, solo in certi ambiti ben delimitati. --ElleElle (msg) 20:13, 16 mar 2020 (CET)

• Non so se la discussione sia ancora aperta, ma in caso mi trovo Favorevole ad equiparare, per i motivi espressi da Ombra. --PercyMM^(msg) 21:23, 12 apr 2020 (CEST)

Sicuro sicuro sicuro? di serie per Rollbacker e Admin

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)

Ma no, il rollback serve proprio per fare alla svelta. --Buggia 10:41, 12 apr 2020 (CEST)

Che lo attivi chi ne sente il bisogno ;-) A margine e in piccolo vorrei esprimere immensa e imperitura gratitudine a [@ Valerio Bozzolan] per la creazione di quel tool <3 --Civvì (Parliamone...) 10:43, 12 apr 2020 (CEST)

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)

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)

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)

Come sopra. --Dimitrij Kášëv 16:07, 12 apr 2020 (CEST)

Nono, che resti una scelta: personalmente preferisco fare danni in tutta fretta :-D--Equoreo (msg) 16:35, 12 apr 2020 (CEST)

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)

[← Rientro] Penso dipenda molto dal dispositivo con cui si usa, al PC immagino sia più "difficile” rollbackare per sbaglio e magari, come già detto, potrebbe essere un fastidio per un utente più attento che non ne ha realmente bisogno. Per me è utilissimo comunque contribuendo quasi esclusivamente da tablet. --LittleWhites (msg) 16:54, 12 apr 2020 (CEST)

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) P.S. ne approfitto per fare a tutti gli auguri di buona Pasqua :)

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)

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)

Certo che è possibile attivarlo solo su mobile :) Anzi, basta copiare l'opportuno gadget da enwiki. --Daimona Eaytoy (Scrivimi!) 20:05, 12 apr 2020 (CEST)

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)

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)

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)

[← Rientro] Mi piacerebbe dire di aver revisionato la modifica sopra, ma purtroppo il diff di MediaWiki per gli script JavaScript non è proprio il massimo... OK al mantenere uno script solo, la cosa del gadget separato era solo per rendere più semplice ai non tecnici scegliere quando abilitare il gadget. Tra l'altro, due gadget non necessariamente significa due script. Basterebbe spostare il codice proposto sopra a MediaWiki:Gadget-SureSureSure-core.js (per es.), e avere due gadget per desktop e mobile, che si limitano a includere lo script core passando opportuni parametri. --Daimona Eaytoy (Scrivimi!) 12:26, 19 apr 2020 (CEST)

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)

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)

Requisito rollbacker ridondante

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)

Fatto. --.avgas 11:14, 4 ago 2020 (CEST)

L'ho rimosso anche da WP:Rollbacker#Modalità di assegnazione. Grazie! --Civvì (Parliamone...) 13:44, 4 ago 2020 (CEST)

[@ .avgas, Civvì] Grazie a entrambe :) --PercyMM 14:35, 5 ago 2020 (CEST)

E ci mancherebbe, power girls sempre a disposizione. --.avgas 11:51, 8 ago 2020 (CEST)

Marco LOOOL--Parma1983 14:41, 8 ago 2020 (CEST) P.S. [@ PercyMM]

Inserire link automatico a "Percentuale di compilazione campo oggetto" nelle richieste

Salve a tutti. Volevo sapere se fosse possibile inserire in automatico il link alla voce relativa alla percentuale di compilazione del campo oggetto assieme ai vari parametri relativi all'utente candidato (quantomeno nel caso dei candidati al flag degli autoverificati). E' un dato che viene preso in considerazione in ogni occasione, e trovo sinceramente curioso che non compaia in automatico, costringendo a cercarlo manualmente ogni volta. Sarebbe possibile aggiungerlo in modo che diventi accessibile in modo più agevole? --Marcodpat (msg) 20:15, 18 nov 2020 (CET)

Dove sta questa statistica?--Pierpao (listening) 20:20, 18 nov 2020 (CET)

Il link è questo, digitando poi il nome dell'utente--Luke Stark 96 (msg) 20:23, 18 nov 2020 (CET)

In realtà non so se sia davvero utile. Già c'è il rimando all'edit count dal quale si arriva in un attimo al campo oggetto. Poi il template è lo stesso anche per le richieste degli altri flag, nei quali il campo oggetto non conta praticamente nulla ai fini della valutazione, quindi inserirlo sarebbe inutile. Ad avere template separati per le varie richieste ci starebbe pure ma, alla fine, fare tutto questo per arrivare ad avere un link già facilmente raggiungibile con il template attuale, beh, imho non è cosa necessaria. Comunque dal punto di vista tecnico si può fare in un attimo --Superpes15^(talk) 21:12, 18 nov 2020 (CET)

Beh, non ho mica la presunzione di star scoprendo l'acqua calda. Ma essendo uno dei parametri di riferimento aveva senso che fosse reperibile senza inserire il link. Ad ogni modo, (premesso che quello accessibile dall'edit count fa riferimento solo alle modifiche nel namespace principale e non a quelle globali) non sempre è linkato, il che costringe ogni votante ad andarselo a guardare. Se ovviamente è più complesso modificare l'impostazione che inserirlo di volta in volta manualmente, lasciamo pure stare. --Marcodpat (msg) 22:06, 18 nov 2020 (CET)

Ma guarda che io ho solo messo un dubbio sull'effettiva utilità. Ti ho dato del presuntuoso scusami? Ti chiedo scusa se l'hai interpretata così, ma non mi pare proprio di averlo fatto, né era mio pensiero o intenzione. Sull'inserimento di un nuovo parametro nel template ti ho già detto che non è affatto complesso, anzi ci si mette solo un istante, il dubbio che sollevavo riguardava il fatto che andremmo ad avere due link esterni in un template che rimandano alla medesima cosa. Effettivamente però non è la stessa, dato che così vediamo il campo oggetto totale e non quella del ns0, come intendevi tu. Diciamo che nel namespace discussioni la statistica conta e non conta (scrivere "re" o "commento" o "fav" non è poi così fondamentale ai fini dell'AV), però sugli altri namespace sarebbe giusto averla (per esempio quando si modifica un template o se viene ritoccata una pagina di aiuto o di servizio). Sul fatto degli altri flag basterebbe omettere il parametro campo oggetto, il punto è che utilizziamo un template standard per tutte le richieste di flag, quindi il parametro andrebbe poi rimosso manualmente dalle altre richieste oppure andrebbero creati dei diversi template in base al flag che si richiede o, ancora, si lascerebbe il campo oggetto anche negli altri. Nel frattempo ho creato il parametro, per farti capire come verrebbe la richiesta, sarebbe una cosa di questo genere, sempre che si voglia inserire solo il ns0 nelle statistiche. Che ne pensate? --Superpes15^(talk) 05:06, 19 nov 2020 (CET)

[↓↑ fuori crono][@ Superpes15] Noooo, scusami davvero! Non l'ho assolutamente presa in questo modo: d'altra parte capisco benissimo chi, vedendo questa proposta, si interroghi sull'effettivo rapporto costo-beneficio. Tra l'altro era anche ben curioso che la proposta venisse da un utente da poco autoverificato e quindi non coinvolto in procedure di proposta/voto, che quindi non ne trarrebbe "personalmente" alcun vantaggio, per così dire (tra l'altro, mi tocca ammetterlo, nemmeno un grande esperto di compilazione del campo oggetto). Per quanto riguarda il tuo template mi sembra vada benissimo: più che altro, già che ci siamo, mi domando se la compilazione del campo oggetto non possa essere un parametro da prendere in considerazione, sia pure come parametro secondario, anche per gli aspiranti rollbacker. Se un utente in procinto di votare dovesse notare un trend in discesa delle percentuali, magari avvenuto dopo l'autoverifica, potrebbe essere più tiepido nella valutazione. --Marcodpat (msg) 09:20, 19 nov 2020 (CET)

[@ Marcodpat][↓↑ fuori crono] Non preoccuparti, è stato solo un malinteso :) La proposta potrebbe venire anche da un IP, il bello di Wiki è che tutti possono collaborare per renderla migliore, assolutamente non cambia il mio parere in base all'autore, penso lo stesso possano dire tutti gli altri. Riguardo al rollback, beh, chi fa patrolling utilizza spesso il tasto annulla o scrive "rb" nel campo oggetto. Direi non sia più un criterio da guardare in quanto le modifiche già non necessitano di verifica. Certo che tutti dovrebbero compilare e in modo corretto il campo oggetto. Vediamo che ne pensano gli altri della proposta comunque :) Formulata in modo che ogni gruppo abbia il suo template direi che, imho, ci sta pienamente la proposta! --Superpes15^(talk) 09:36, 19 nov 2020 (CET)

[← Rientro] Ripensandoci e riguardando il tutto un attimo l'ipotesi di creare template diversi in base al ruolo non è così complessa, anzi, si potrebbe fare facilmente. Per esempio nelle richieste per i rb andrebbero il numero degli "undo" e il registro delle modifiche verificate, mentre per i mover il registro degli spostamenti, di modifiche all'interno del ns file, ecc. --Superpes15^(talk) 07:23, 19 nov 2020 (CET)

Effettivamente dei link extra per ogni flag sarebbero molto utili; sono d'accordo con quanto appena scritto da Superpes. Non dovrebbe essere un problema complicare un po' l'inserimento del template, perché chi propone qui utenti ha di sicuro conoscenza avanzate di wiki --ValeJappo【〒】 15:58, 19 nov 2020 (CET)

Concordo con chi mi precede. Sono comunque parametri che vengono presi in considerazione per valutare un candidato, quindi sarebbe comodo accedervi rapidamente. Anche se si dovesse un po' complicare la procedura di candidatura di un utente, essendo essa solitamente fatta da utenti wikipedianamente abbastanza esperti, non penso rappresenti un problema. --PercyMM 19:31, 20 nov 2020 (CET)

La percentuale di per sé penso valga poco e niente e abbia il difetto di contribuire a impressioni errate. Occorre sfogliare i contributi dell'utente e valutare se nell'ultimo periodo compili il campo oggetto dove davvero serve.--Sakretsu (炸裂) 23:56, 20 nov 2020 (CET)

[@ Sakretsu] Certo, sono d'accordissimo con te e difatti quando vado a lasciare un parere su una proposta di AV, ad esempio, non mi baso mai sulla percentuale ma sui contributi ed eventuali interazioni con l'utente. Però è un dato di fatto che moltissimi utenti la percentuale la vanno a guardare, quindi o si disincentiva la cosa o rendere l'informazione più accessibile non mi sembra una gran brutta cosa. Spero sia noto a tutti che una percentuale, di compilazione del campo oggetto ad esempio, non definisce un utente né di per sé se questo sia pronto o meno a un determinato flag. Quindi, visto che l'informazione viene usata come strumento di valutazione, tanto vale renderla facilmente accessibile. --PercyMM 11:57, 21 nov 2020 (CET)

Se condividiamo che non sia un valido strumento di valutazione perché fuorviante, non c'è motivo di renderlo più facilmente accessibile. Cerchiamo piuttosto di aiutare chi è valutato a capire che le considerazioni sono anche sul modo di compilare l'oggetto.--Sakretsu (炸裂) 13:41, 21 nov 2020 (CET)

IMHO sebbene le valutazioni da fare per concedere il flag di AV - come scritto sopra - siano molteplici, quindi non solo limitate al campo oggetto, ritengo che la sua compilazione (che porta via veramente poco tempo e pochissimi sforzi fisici :D ed è utilissima a tutti) sia indispensabile da parte di tutti gli utenti, anche di quelli già in possesso di "altri" flag. Per questi motivi sono favorevole alla modifica proposta e trovo molto interessante lo stub creato da Superpes15 --Mtarch11 (msg) 14:11, 21 nov 2020 (CET)

Non vorrei che ci fosse un fraintendimento. In altre discussioni ci siamo confrontati sul se il campo oggetto vada valutato o meno. Qui stiamo discutendo invece dell'utilità di uno strumento preciso che mostra una serie di percentuali che non indicano né come è stato compilato l'oggetto né in che occasione. In altre parole, cosa mi significa ad esempio un 80%? Che l'utente puntualmente spiega ogni suo annullamento? Che spiega sufficientemente in ogni namespace il senso delle sue modifiche, specie le più opinabili? E invece un 40%? Non può essere dovuto, come è accaduto a volte, a un'enorme quantità di edit in sandbox senza oggetto? :-) Allora mi chiedo cosa ce ne facciamo della percentuale se, previa opportuna visione dei contributi, rende più giustizia un commento del tipo "ottima compilazione del campo oggetto"?--Sakretsu (炸裂) 14:54, 21 nov 2020 (CET)

Mi sembra che, come spesso accade su WP anche tra utenti navigati, si stia perdendo il focus. Ognuno è ovviamente libero di pensare che la percentuale di compilazione del campo oggetto non sia un parametro da considerare, o che il suo peso nella valutazione vada ridiscusso o bilanciato, ma in tal caso mettiamo in pausa questa discussione e affrontiamo quest'ultima tematica in altra sede (o banalmente in una discussione a parte). Qui il punto è: dovendo utilizzare la percentuale del campo oggetto come XTools la mostra, perchè non richiamare la pagina in modo più agevole?

Comunque si potrebbe anche provare a creare un template unico che, a seconda del tipo di flag che si vuole assegnare, mostra valori differenti, con una sintassi del tipo {{RichiestaPermessi|NomeUtente|FlagDaAssegnare}}, in cui il flag da assegnare è una sigla del tipo av/rb/ammint (o anche semplicemente un numero). L'uso del template potrebbe essere spiegato in maniera agevole da una guida in cima alla pagina. Dovrebbe essere non dico agevolmente programmabile, ma senz'altro fattibile (mi viene in mente il template "Cancella subito", che a seconda dei numeri inseriti ha esiti differenti e una resa grafica diversa). --Marcodpat (msg) 15:08, 21 nov 2020 (CET)

[↓↑ fuori crono] [@ Marcodpat] scusami, in realtà sono io ad essermi spiegato malissimo :) intendevo dire che siccome considero il campo oggetto importante e che spesso una volta ricevuto il flag di AV e di RB/Mover ci si dimentica della sua esistenza, potrebbe essere utile accedere alla pagina in modo più veloce --Mtarch11 (msg) 03:30, 22 nov 2020 (CET)

Per il template non c'è nessun problema a creare i vari parametri, il punto è se vi sia un consenso a farlo. Di certo, imho, per le richieste del flag di mover sarebbe utile avere un link diretto agli spostamenti e al namespace file, così come per il rollbacker ai "patrol" e agli annullamenti fatti. Se la discussione va in questo verso si crea facilmente una cosa del genere--Superpes15^(talk) 16:14, 21 nov 2020 (CET)

Ricordo che nel caso si cambi il template, va fatto in modo che non crei danni nell'archivio --ValeJappo【〒】 16:22, 21 nov 2020 (CET)

Semplicemente quelle rimangono come sono e senza i parametri aggiuntivi --Superpes15^(talk) 16:34, 21 nov 2020 (CET)

Favorevole in ritardo

Ora è già la seconda volta in 5 minuti che non vedo il {{Fatto}} 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)

[@ ValeJappo] 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 <small></small> sarebbe IMHO opportuno in questo senso. --PercyMM 12:01, 21 nov 2020 (CET)

Essendo la discussione chiusa basta metterli prima del {{fatto}} semplicemente con un {{Fc}}--Pierpao (listening) 12:16, 21 nov 2020 (CET)

Basta aggiungere il {{fc}} come ha detto Pierpao --Ap7189ap 01:39, 22 nov 2020 (CET)

Archiviazione

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)

Mi stupisco che questa bell’idea non sia stata adottata prima. Ruthven (msg) 14:08, 21 nov 2020 (CET)

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)

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)

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. [@ Civvì] che ne pensi? :) --PercyMM 14:45, 21 nov 2020 (CET)

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)

[× Conflitto di modifiche]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)

Esiste il template:Oldid, ma penso che ormai sia obsoleto visto che si può scrivere semplicemente [[Speciale:Permalink/116807104#Syphax98|Syphax98]] → Syphax98. L'idea comunque mi pare buona--Sakretsu (炸裂) 15:20, 21 nov 2020 (CET)

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)

L' "opzione AlfaWikiBeto', quella del permalink mi pare ottima. Le vecchie procedure invece si lasceranno così?--ValeJappo【〒】 15:54, 21 nov 2020 (CET)

Favorevole anch'io all'opzione AlfaWikiBeto. Più pratica anche per chi deve consultare. --ΞLCAIRØ♭ 15:58, 21 nov 2020 (CET)

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)

+1 sulla versione AlfaWikiBeto di Superpes15 --Civvì (Parliamone...) 07:58, 22 nov 2020 (CET)

+1 pure io sulla versione AlfaWikiBeto. --PercyMM 11:23, 22 nov 2020 (CET)

Ok anche per me --Ombra 13:12, 22 nov 2020 (CET)

Favorevole--Luca•M 13:20, 22 nov 2020 (CET)

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)

[← Rientro] Ho iniziato a sistemare l'archivio dei mover (2020), che ne pensate? Se va bene così iniziamo a cancellare le sottopagine, magari quelle degli AV più vecchie si potrebbero lasciare visto che sarebbe un lavoraccio ritrovare il diff esatto per ogni richiesta (e purtroppo molti nel concedere il flag non hanno messo il diff) --Superpes15^(talk) 12:10, 26 nov 2020 (CET)

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)

[@ Superpes15] 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)

[@ PercyMM] 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)

Mi piace l'ipotesi del testo cancellato--ValeJappo【〒】 17:38, 26 nov 2020 (CET)

[@ Superpes15] 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)

Supporto anche io l'idea del barrato per le revoche. --Lollo Scrivimi 17:42, 26 nov 2020 (CET)

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). [@ Superpes15] 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)

[@ PercyMM] 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)

[← Rientro] mettiamo un'avviso nell'ultimo archivio degli AV per segnalare che altre procedure non sono più archiviate lì?--ValeJappo【〒】 09:24, 30 nov 2020 (CET)

Concordo, dato che per gli AV la sottopagina del periodo corrente è rimasta potrebbe essere confusionarlo non scriverlo. --PercyMM 18:49, 30 nov 2020 (CET)

[@ ValeJappo] 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)

Segnalo

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

Flag intermedio

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)

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)

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)

[@ Enzo Encius] 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)

• Contrario come diceva una delle persone più intelligenti che abbia mai conosciuto: passiamo dal facile al difficile attraverso l'inutile. --Vito (msg) 22:20, 8 dic 2020 (CET)
• Contrario Condivido l'affermazione di Vito. Non c'è alcuna necessità di questo flag ora che abbiamo chiarito aggiornato i criteri per il flag di autoconvalidato e i permessi. Una sorta di "extendedconfirmed" o di "patroller" è del tutto inutile dato che abbiamo i rollbacker e gli AV che possono già patrollare verificando le modifiche e usando tools come LiveRC. Per gli utenti giovani c'è tempo per maturare e raggiungere l'AV senza avere flag intermedi. Un flag che sarebbe di brevissima durata, di passaggio, non lo condivido personalmente.
  OT A margine, [@ ValeJappo], come ho già ampiamente spiegato nel progetto patrolling, il patrolmarks è il diritto che permette di vedere quali modifiche non siano state verificate (punto esclamativo rosso per le modifiche e sfondo giallo per le nuove pagine) ma non consente di verificarle, il patrol invece ha gli stessi diritti del patrolmarks ma permette anche di verificarle. Quello che permette di averle automaticamente verificate è l'autopatrol. --Superpes15^(talk) 22:31, 8 dic 2020 (CET)

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)

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)

Non sarebbe inutile ma visto tutto il tran tran conseguente non vale la pena di avere un altro gruppo Pierpao (listening) 00:47, 9 dic 2020 (CET)

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)

[↓↑ fuori crono] 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)

• Contrario pure io, come Superpes. È vero che ci sono dei validi patroller non AV per cui dobbiamo stare a verificare le modifiche che annullano, oltre che le loro, ma non essendo questa fascia di utenti molto estesa sarebbe secondo me inutile (nel senso che il lavoro richiesto per mettere in piedi questo user group intermedio sarebbe più dispendioso, IMHO, di quello che eviterebbe agli AV). Quindi secondo me va bene la situazione attuale (autoconvalidati con patrolmarks e AV con patrol e autopatrol). Grazie comunque per la proposta! --PercyMM 15:06, 9 dic 2020 (CET)
• Contrario Il problema è nella premessa:
  «Alcuni utenti registrati ben a conoscenza del funzionamento di wikipedia si stanno dedicando con costanza all'attività di patrolling. [...] L'origine di questo intervento è che gli utenti in questione non sono AV»
  Se sono a conoscenza delle regole non sono vandali, dunque sono da autoverificare senza se e senza ma. --.avgas 20:40, 21 dic 2020 (CET)

  [@ .avgas] come detto sopra ad Enzo Encius, mi riferisco solo agli utenti privi di requisiti per diventare AV. --Lollo Scrivimi 02:21, 22 dic 2020 (CET)

  ...quindi da autoverificare senza se e senza ma. --.avgas 15:13, 24 dic 2020 (CET)

  [@ .avgas] Ma se sono privi dei requisiti? Non si possono autoverificare. La mia era una soluzione temporanea e provvisoria prima dell'autoverifica. --Lollo Scrivimi 15:32, 24 dic 2020 (CET)

  [@ Lorenzo Longo] Allora al 98% è bene che rimangano non autoverificati fintanto che non raggiungono i tutto sommato blandi criteri minimi richiesti. Se poi ci si trova davanti ad un fuoriclasse tipo Equoreo, si procede ugualmente con il flag come feci io con lui. Rimangono casi più unici che rari, per cui è bene tenerne a mente il motivo e continuare ad applicare WP:NEVE quando davvero necessario. --.avgas 15:45, 24 dic 2020 (CET)

• Contrario Oggettivamente mi sembra una proposta non inutile, ma sarebbero notevolmente di più i costi dei benefici, e non penso che ci sia bisogno di ripetere quanto probabilmente già detto da altri. --C. crispus 🎄⛄ 15:40, 24 dic 2020 (CET)

Utenti bloccati/infinitati

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)

[@ Lo Scaligero] 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)

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 Favorevole alla revoca. --Gce ★★★+2 22:14, 23 mar 2021 (CET)

Personalmente come Gce. --Popsi (msg) 08:56, 24 mar 2021 (CET)

Sono assolutamente d'accordo con Gce. Penso sia corretto distinguere i blocchi volontari con quelli per problematicità; Favorevole alla revoca per questi ultimi. GA16   […] 08:58, 24 mar 2021 (CET)

Contrario 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)

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)

Espressioni di mero consenso

Premetto che avevo letto questa discussione molto velocemente dopo un mio periodo di scarsa attività, e avevo capito valesse solo per le richieste di autoverifica. Per regolarmi meglio in futuro, andrebbe evitato anche un parere favorevole motivato come questo? La faccenda del "mero consenso" l'avevo interpretata come un invito a evitare favorevoli immotivati e "pacche sulle spalle" varie. Mi pare di capire, invece, che si voglia lasciare questo spazio esclusivamente per mettere in luce eventuali criticità. Ho capito bene? Grazie. --Titore (msg) 21:00, 20 mag 2021 (CEST)

Se non sbaglio vanno evitati commenti del tutto non motivati e file di favorevoli.

Ad esempio, da come lo ho interpretato io: se sei favorevole ma nessuno esprime dubbi, non lo dici; se qualcuno esprime perplessità, allora - motivando adeguatamente - puoi esprimere il tuo parere. --ValeJappo (msg) 15:21, 21 mag 2021 (CEST)

Sono amministratori e burocrati a dover decidere se l'utente in questione va flaggato o meno, non è una votazione. In presenza di pareri contrari, l'amministratore/burocrate è perfettamente in grado di discernere quale sia la decisione da prendere. --LittleWhites (msg) 15:27, 21 mag 2021 (CEST)

WP:BUONSENSO. Se uno ha qualcosa di veramente rilevante da dire, lo fa. Approfitto per ricordare che questo non è stato deciso per sottolineare che decide il burocrate è non gliene frega degli utenti perchè se qualcuno si oppone deve scrivere ma solo che è per non incentivare la convinzione diffusa che i flag siano premi da conquistare.--Pierpao (listening) 12:17, 22 mag 2021 (CEST)

Modalità archiviazione esenti dal blocco IP

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)

Revoca utenze bloccate

A seguito di quanto accaduto qui, con un chiarimento da parte dell'admin [@ Actormusicus] 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 [@ Civvi] se ne sia accorta per caso, perché non mi pare di aver visto alcuna richiesta di revoca né da parte di [@ Phyrexian] 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)

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)

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)

Se è così anche i miei flag dovrebbero essere rimossi...--UltimoGrimm (msg) 20:00, 3 set 2022 (CEST)

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)

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)

Nel complesso condivido le parole di [@ .avgas]: 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)

[@ Parma1983] Automatismo no, ma [@ Euphydryas] 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)

Intanto abbiamo un V pilastro e quando si tratta di blocchi e deflag è stato più volte utilizzato, quindi il deflag automatico sarebbe un obbligo inutile perché poi saltuariamente disatteso come accaduto talvolta, come dicevo per altri casi di blocco e deflag, mentre d’altro canto i casi di revoca per abuso del flag sono rarissimi, parlo di quelli non A, non ho visto i due casi citati, ma in 5 anni di richieste serie ne ho vista 1. Questo perché uno dei nostri principi fondamentali è la rieducazione. Non ho studiato i due casi citati, ma la maggior parte dei blocchi dicevo riguarda comportamenti aggressivi e in questi casi A viene tolto quasi subito. Per quanto riguarda la richiesta da parte dell’amministratore c’è un altro problema, o scriviamo che è obbligatorio che sia l’amministratore che ha comminato il blocco a richiedere il deflag ma questo violerebbe il principio generale di libertà di discussione oppure qualsiasi altra previsione non deontica per esempio “sarebbe consigliabile che l’amministratore…” sarebbe inutile perché intanto che l’amministratore riflette scrive in chat all’amico per chiedere un parere, scrive in ml, uno dei 100o notai che abbiamo ha già fatto richiesta, cenato e goduto di una buona dormita, fiero di aver fatto cosa buona. Le richieste di flag o deflag non opportune o errate saranno sempre un problema, non risolvibile. Forse vista la discussione su Dennis io scriverei semplicemente che in caso di edit war il flag di rollback è revocato, i motivi sono tanti, il rollback va usato solo per i vandalismi, gli edit war raramente implicano vandalismi, il flag di rollback implica capacità di giudizio negli annullamenti che deve evitare gli ew, e non vedo perché facilitare la vita a chi fa edit war. Per il resto lascerei come è. Pierpao (listening) 09:10, 4 set 2022 (CEST)

Ah e poi perché la comunità percepirebbe giustamente come un abuso che chi fa ew sia un rollbacker. Pierpao (listening) 09:12, 4 set 2022 (CEST)

Comunque due righe in wp:ma per ricordare ai sysop nei casi gravi di fare richiesta si possono mettere. Pierpao (listening) 09:21, 4 set 2022 (CEST)

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)

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)

[@ Mtarch11] 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)

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)

[@ Parma1983] 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)

[@ Mtarch11] 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)

Soprattutto l'AV [@ Mtarch], 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)

Certo che è ancora più grave, [@ Mtarch11], 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)

[@ .avgas] non ho perso di vista nulla, grazie, ho solo espresso il mio parere. [@ Kirk39] 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)

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)

[← Rientro] Buongiorno e benritrovati. Ringrazio [@ Vgg5465] per avermi pingato. Rientro da un blocco di un mese per attacchi personali (condotta assolutamente non indicativa dell'affidabilità in ns0), con annessa revoca - a pochi giorni dalla scadenza - dei flag di autoverificato e mover (strumenti per operare in ns0, sull'uso dei quali non ho mai ricevuto la benché minima contestazione in tutta la mia non breve esistenza wikipediana). Il provvedimento dunque non solo non si traduce in alcun beneficio per la cura dell'enciclopedia, ma genera un danno in quanto adesso dovrò essere controllato edit per edit, come si fa con i niubbi pasticcioni e i potenziali vandali, e dovranno essere admin e mover a eseguire al mio posto gli spostamenti di voci e pagine.

[@ Merynancy] Proprio perché "i flag, oltre ad assegnare funzioni aggiuntive, indicano un livello di fiducia da parte della comunità", la revoca non può essere automatica quando il blocco non è deciso dalla comunità in una segnalazione UP bensì da un amministratore singolo, magari con diversi altri utenti - che non sono meno parte della comunità - in disaccordo con il blocco. In questo modo si eleva il singolo amministratore a unico e infallibile rappresentante della comunità, laddove la comunità è composta dalla generalità degli utenti.

Invito anche a considerare l'effetto psicologico di un provvedimento simile. Immaginate un utente storico che ha sempre lavorato bene in ns0, portato voci in vetrina ecc., che - appena ha iniziato a riprendere serenità dopo il blocco - improvvisamente si vede spogliato, senza alcun previo contraddittorio, di tutti i flag che indicano affidabilità in ns0 per una condotta che non incide minimamente su detta affidabilità. Non vi manca la sensibilità per una riflessione anche su questo aspetto. Grazie per l'attenzione.--Demiurgo (msg) 10:36, 6 set 2022 (CEST)

Questa è una pagina di servizio, non un tribunale in cui avanzare arringhe [@ Demiurgo]. 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)