Discussioni Wikipedia:Richieste di permessi

Da Wikipedia, l'enciclopedia libera.
Jump to navigation Jump to search

Aggiungere le richieste per il flag di convalidato[modifica wikitesto]

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?[modifica wikitesto]

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 Symbol strong support vote.svg 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)
Symbol support vote.svg Favorevole, però poi non esageriamo con gli avvitamenti burocratici--Ferdi2005 (Posta) 15:00, 27 set 2017 (CEST)
Symbol oppose vote.svg Contrario/a 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[modifica wikitesto]

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[modifica wikitesto]

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[modifica wikitesto]

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[modifica wikitesto]

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)
Symbol support vote.svg 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[modifica wikitesto]

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[modifica wikitesto]

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)

Symbol support vote.svg 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)
Symbol support vote.svg Favorevole Anche io penso sia opportuno inserirlo come requisito --Dave93b (msg) 14:12, 22 gen 2020 (CET)
Symbol support vote.svg Favorevole anch'io--Luke Stark 96 (msg) 14:13, 22 gen 2020 (CET)
Symbol support vote.svg Favorevole come Parma.--Luca•M 14:16, 22 gen 2020 (CET)
Symbol support vote.svg Favorevole come Parma. --Antonio1952 (msg) 14:29, 22 gen 2020 (CET)
Symbol support vote.svg Favorevole quoto Parma --goth nespresso 14:30, 22 gen 2020 (CET)
Symbol support vote.svg 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)
Symbol support vote.svg 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)
Symbol support vote.svg Favorevole--Leo0428 (msg) 20:55, 22 gen 2020 (CET)
Interessante l'appunto di 3knolls, Symbol support vote.svg Favorevole ad aggiungere una nota per entrambi i flag. --Dimitrij Kášëv 20:58, 22 gen 2020 (CET)
Symbol support vote.svg 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)
Symbol support vote.svg 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[modifica wikitesto]

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 Symbol support vote.svg Favorevole ad uniformare anche questo aspetto--Parma1983 15:05, 22 gen 2020 (CET)
Anche io sono Symbol support vote.svg Favorevole ad equiparare.--Ferdi2005[Posta] 16:19, 22 gen 2020 (CET)
Symbol support vote.svg Favorevole all'equiparazione --Lemure Saltante sentiamo un po' 16:44, 22 gen 2020 (CET)
Symbol support vote.svg Favorevole anche per me, condivido le riflessioni qui sopra --Dave93b (msg) 16:46, 22 gen 2020 (CET)
Symbol support vote.svg 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)
Symbol oppose vote.svg Contrario/a 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)
Symbol support vote.svg 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 Symbol support vote.svg Favorevole.--☼Windino☼ [Rec] 17:19, 22 gen 2020 (CET)
Symbol support vote.svg 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. Symbol support vote.svg Favorevole ad unificarli entrambi al livello di burocrate. --Antonio1952 (msg) 22:34, 22 gen 2020 (CET)
Onde evitare discussioni come questa, anch'io sono Symbol support vote.svg Favorevole ad unificarli entrambi al livello di burocrate.--3knolls (msg) 22:41, 22 gen 2020 (CET)
Symbol support vote.svg Favorevole --Dimitrij Kášëv 22:53, 22 gen 2020 (CET)
Symbol support vote.svg 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. Symbol support vote.svg Favorevole anch'io. Apriamo questo phabtask. --.avgas 00:25, 23 gen 2020 (CET)
Symbol support vote.svg Favorevole--GC85 (msg) 00:32, 23 gen 2020 (CET)

Symbol strong support vote.svg 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)

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à[modifica wikitesto]

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)
  • Symbol support vote.svg Favorevole--Leo0428 (msg) 16:20, 13 feb 2020 (CET)
  • Symbol support vote.svg 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)
  • Symbol support vote.svg Favorevole--Parma1983 23:22, 13 feb 2020 (CET)
  • Symbol support vote.svg Favorevole, --Melquíades (msg) 10:19, 14 feb 2020 (CET)
  • Symbol support vote.svg Favorevole --Ombra 13:37, 14 feb 2020 (CET)
  • Symbol support vote.svg Favorevole --Epìdosis 13:41, 14 feb 2020 (CET)
  • Symbol support vote.svg Favorevole--Sakretsu (炸裂) 13:50, 14 feb 2020 (CET)
  • Symbol support vote.svg Favorevole --Dimitrij Kášëv 21:48, 14 feb 2020 (CET)
  • Symbol support vote.svg Favorevole--GC85 (msg) 21:49, 14 feb 2020 (CET)
  • Neutrale 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)
  • Symbol support vote.svg Favorevole--TriggerOne (msg) 20:20, 19 feb 2020 (CET)
  • Symbol dot dot dot violet.svg Commento: Nessuno ha ancora proceduto con la modifica?--Mauro Tozzi (msg) 15:10, 10 mar 2020 (CET)
  • Symbol dot dot dot violet.svg 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)
  • Symbol dot dot dot violet.svg 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... :-)
  • Symbol dot dot dot violet.svg 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)
  • Symbol dot dot dot violet.svg 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)
  • Symbol oppose vote.svg Contrario/a 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)
  • Symbol dot dot dot violet.svg 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)
  • Symbol support vote.svg 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)
  • Symbol support vote.svg 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)
  • Symbol support vote.svg 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)
  • Symbol dot dot dot violet.svg 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 Symbol support vote.svg 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[modifica wikitesto]

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[modifica wikitesto]

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[modifica wikitesto]

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[modifica wikitesto]

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[modifica wikitesto]

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)

Symbol support vote.svg 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)