Discussioni Wikipedia:Rollbacker/Archivio02

Funzioni del gruppo Rollbacker

A seguito di ripetute richieste, riapro una questione portata all'attenzione un po' di tempo fa, e cioè l'aggiunta di una o due funzioni a questo gruppo.

Circa un anno fa proposi l'aggiunta al gruppo della funzione unwatchedpages, ossia la possibilità di visionare un elenco composto da (decine di migliaia di) pagine non inserite negli osservati speciali degli utenti. Tuttavia, come fu fatto notare, l'inserimento di questa funzione può far cambiare la ratio per la quale il gruppo stesso era stato creato: il rollbacker, nato per essere un utente attivo nel patrolling di prima linea (ossia delle modifiche recenti - RC), avrebbe accesso a una funzione che invece è propria del retropatroller, estendendone dunque il raggio d'azione a un campo proprio a diversi altri utenti, per i quali in passato era stato negato il flag proprio perché non attivi nel RC patrolling.

Personalmente non ho particolari obiezioni a un cambio di rotta all'interno di questo gruppo (nel senso che non spingo né per la modifica né per lo status quo, la cosa per me cambia poco), ma a questo punto si dovrebbero prendere in considerazione anche altre cose e soprattutto le eventuali conseguenze che ciò comporta.

• Oltre all'unwatchedpages, sarebbe opportuno aggiungere il suppressredirect, anch'esso utile nel retropatrolling in caso di spostamenti di matrice vandalica, specialmente nelle pagine non osservate, con la creazione di inutili redirect.
• Coloro ai quali in passato fu rifiutato il flag perché non attivi nel RC patrolling possono fare una nuova richiesta di abilitazione che dev'essere però valutata ex novo.
• Occorre rivalutare il metodo per l'assegnazione, dato che entrano in gioco altri parametri, perché occorre capire chi si occupa di retropatrolling.
• Valutare, in subordine, se confermare gli attuali rollbacker nel ruolo, se lo si ritiene necessario.

Il gioco vale la candela? Pareri, grazie. --Roberto Segnali all'Indiano 11:23, 14 feb 2012 (CET)

Più che altro l'unwatchedpages è poco utile perché tronca i risultati a 5000 pagine. Il suppress quante volte servirebbe? Cioè quanti richieste di C9 abbiamo dai rollbacker? Avrebbe più senso per gli autoconfirmed a questo punto. --Vito (msg) 11:27, 14 feb 2012 (CET)

(conflittato) Per le "unwatched" ripeto quanto già dissi un anno fa: inutile. --Retaggio (msg) 11:28, 14 feb 2012 (CET)

per quanto riguarda l'unwatched mi unisco alle opinioni di Vito e di Retaggio, quella funzione è inutile perchè non permette di avere una visione globale delle pagine non osservate e pericolosa perchè permette di sapere quali sono osservate e quali no (anche se in minima parte), per quanto riguarda il suppressredirect sono titubante. Per deformazione professionale sono dell'idea che si abilitano funzioni solo quando si crea un'esigenza concreta e non quando ve ne è richiesta. --Ask21 (msg) 11:40, 14 feb 2012 (CET)

Da un punto di vista meramente commerciale, se non c'è domanda non ha senso fare un'offerta... E se le unwatched pages sono così ingannevoli tanto vale lasciar stare. --Dry Martini confidati col barista 15:36, 14 feb 2012 (CET)

Beh, se non ha senso per i rollbacker allora si potrebbe allargare la funzione ai autoverificati (Vito: autopatrolled o autoconfirmed proprio), tanto bene o male anche loro, almeno la maggior parte è attiva nel (retro)patrolling, seppur non così assiduamente. In ogni caso se si concedesse la funzione anche agli autoverificati, in questo modo si potrebbero ridurre di molto le pagine non osservate, o comunque sarebbero più sotto controllo, visto che (mi sembra) che tra tutte le funzioni sysop che ci siano, l'unwatchedpages sia quella meno utilizzata, funzione tra l'altro abbastanza piccola, povera. Per il suppressredirect, in effetti anche lì non è che vi siano quelle code però può capitare (e non di rado) che il vandalo di turno sposti una pagina vandalizzandola o inserisca un redirect fuori luogo. Se consideriamo poi che i rollbacker (così come gli autoverificati) sono utenti affidabili e responsabili (fuorchè il sottoscritto naturalmente), penso che non dovrebbero esserci quei grandi problemi, anche perchè non stiamo parlando del protect, delete o movefile... Altrimenti continuiamo a rimanere "tradizionalisti" a non evolverci e a preferire i principi del principio, mai cambiando le disposizione.--Frigotoni (msg) 17:44, 14 feb 2012 (CET)

Contrario, cosa è cambiato rispetto a qualche paragrafo più sopra? --M/ 19:52, 6 mag 2011 (CEST) --M/ 17:47, 14 feb 2012 (CET)

Dare unwatchedpages agli autopatrolled non è pericoloso anzi costruttivo perché:

• Si aumenta chi guarda quelle pagine (attualmente appunto la query è bloccata -> ce ne è bisogno)
• È a basso rischio POV e danneggiamenti vari perché

• gli autopatrolled sono in genere affidabili
• essi lo sono a sufficienza per questo piccolo incarico poiché se quelle pagine non se le fila nessuno sono a bassissimo rischio POV, ma alto rischio vandalismi che permangono. -> utile a utenti attivi nel patrolling e retropatrolling -> rollbacker i primi e autoverificati i secondi.

Di problemi non ne vedo, fuorché qualche vizio formale sulla natura dei compiti (autoverificato è colui che semplicemente è "non-vandalo"), ma l'utilità di questa apertura mi pare indubbia, tanto più che penso che gli autoverificati siano unanimemente in grado di svolgere il compito, soprattutto se poi qualcuno passerà ad avvisarli sul fatto che possono aiutare la comunità con le unwatchedpages.--Nickanc ♪♫@ 18:55, 14 feb 2012 (CET)

Retaggio, Ask21: Anch'io direi che la funzione sarebbe inutile se avessi dei privilegi ulteriori oltre al rb, proprio perchè probabilmente sarei l'unico (se non insieme a qualcun'altro) a dovermi ritrovare a monitorare le unwatchedpages. Quindi preferirei lasciar stare e occuparmi di altre cose usando le altre "cento" funzioni che ci sono per un amministratore. La funzione è in mano a 104 utenti de iure, ma de facto proprio a nessuno, nel senso che pochissimi la usano, dunque rischierebbe anche, tra le altre cose, di diventare obsoleta (se non lo è già). Se tale funzione invece fosse abilitata ai rollbacker e ai autopatrolled, ci sarebbero molte più possibilità che la funzione diventasse realmente utile, dato che i privilegi di questi due gruppi sono molto più limitati. Poi se sono considerazioni solo mie, allora possiamo anche concluderla qua.--Frigotoni (msg) 18:48, 17 feb 2012 (CET)

Secondo me se, come scritto da Roberto Mura, il rollbacker, nato per essere un utente attivo nel patrolling di prima linea, la funzione potrebbe esser prevista per gli utenti autoverificati. Sul suppressredirect non mi esprimo. --Aleksander Šesták 20:08, 17 feb 2012 (CET)

Il rollbacker fa patrolling in prima linea, non retropatrolling. Mi sembra che le eventuali aggiunzioni vertano sul secondo.--Seics (ti pigliasse lo spread) 21:48, 17 feb 2012 (CET)

Se non si prevedono controindicazioni specifiche, una prova si potrebbe fare. Siccome questo tipo di controllo, a quanto dite, scarseggia, è bene cercare nuovi utenti interessati a controllare quella lista, e cercarli tra coloro (i rollbacker) che si interessano di lotta al vandalismo credo sia la scelta migliore. I rollbacker non sono admin ma comunque sono utenti fidati e noti, e il fatto che prima di passare alle RC perdano (se lo vogliono) tre minuti sugli OS non comporta rischi per wikipedia. ·· Quatar » posta « 11:00, 20 feb 2012 (CET)

Come dicevo, special:Unwatchedpages *non serve a niente* perché attualmente è inceppato alla lettera alb (su it.wiki), a 'sto punto troviamo ~60 volontari che se ne prendano 5.000 ciascuno (considero di dare tre volte lo stesso pacchetto per ridondanza) e via, tempo due mesi azzeriamo la pagina. Sostanzialmente questo strumento è stato concepito per wiki di dimensioni assolutamente non paragonabili ad it.wiki (e suppongo che sia questa la logica per cui non viene aggiustato)...quello di en.wiki addirittura si pianta a 1000 risultati! Insomma concentriamoci su aiuti *concreti* al patrolling piuttosto che su roba priva di utilità pratica. --Vito (msg) 11:19, 20 feb 2012 (CET)

Al netto di ogni altra considerazione, il gruppo autopatrolled deve rimanere così come lo abbiamo concepito all'inizio, anche perché ci eravamo impegnati a non attribuirgli altri significati. --pequod ^..Ħƕ 12:20, 20 feb 2012 (CET)

Flag e retropatrolling

Premesso che la richiesta recente di Pequod ha a che fare con questa sezione solo perché mi ha fatto riflettere sul problema e perché mi ha fatto ricordare di altre richieste analoghe (oltre che della sezione qui sopra, inerente in qualche misura allo stesso problema ;-) ), credo potrebbe essere utile inserire nella pagina un paragrafuccio (una sottosezione di "Uso"?) che spieghi perché gli utenti dediti esclusivamente o principalmente al retropatrolling non hanno bisogno del flag e avranno delle difficoltà a ottenerlo. Qualcosa come

«Poiché comporta il solo accesso allo strumento di rollback, il flag non è particolarmente indicato per gli utenti principalmente o esclusivamente dediti al retropatrolling. Le modifiche oggetto di questo genere di controllo raramente sono le ultime effettuate sulla pagina e ancor più raramente sono palesi vandalismi: uno strumento di annullamento rapido, dunque, avrebbe poche probabilità di essere usato in quest'ambito. Un utente che dedichi pochi edit al patrolling in tempo reale non ha motivo di richiedere l'assegnazione del flag.»

potrebbe andare? A occhio ce ne sarebbe bisogno, visto che, se non va bene avere troppe regole, è invece un bene avere spiegazioni dettagliate sulle regole che già abbiamo. E in questo caso si è anche manifestata la necessità di queste spiegazioni ;-) --Dry Martini confidati col barista 17:36, 26 mar 2012 (CEST)

Il testo mi sembra adeguato, anche se è colpa mia se non ho capito da me la questione. Per qualcuno meno esperto sarebbe cmq utile. --pequod ^..Ħƕ 17:58, 26 mar 2012 (CEST)

(fc) Peq, tranquillo, tu c'entri solo in veste di mia musa ispiratrice, il problema c'era già ;-) --Dry Martini confidati col barista 18:53, 26 mar 2012 (CEST)

+1. --Roberto Segnali all'Indiano 18:23, 26 mar 2012 (CEST)

• +1 mapi (msg) 18:40, 26 mar 2012 (CEST)

Sempre stato sostanzialmente contrario a queste pensate un po' nostrane - mi riferisco al non dare il flag ai retropatrollatori (o almeno a quelli che non si dedicano solo ed esclusivamente a quello, volendo): porre il principio davanti all'esigenza pratica è pressoché sempre un controsenso nella vita e, ancor di più, su Wikipedia. Stante così le cose, comunque, il testo è sicuramente chiaro. --Gnumarcoo 20:18, 26 mar 2012 (CEST)

Scusa, Gnu, ultimamente sono un po' rinco: è chiaro il testo proposto o quello "in vigore" attualmente? --Dry Martini confidati col barista 20:45, 26 mar 2012 (CEST)

Il passaggio chiaro è il tuo - in "vigore" non c'è alcun testo che spieghi il concetto di cui sopra (anche perché se così non fosse non saremmo qui a commentare). --Gnumarcoo 21:03, 26 mar 2012 (CEST)

Ecco, come volevasi dimostrare: sono un po' rinco ;-) --Dry Martini confidati col barista 21:48, 26 mar 2012 (CEST)

Ora più che mai ti comprendo, figurati. --Gnumarcoo 22:11, 26 mar 2012 (CEST)

(rientro) Voilà. Ho scelto un'altra sezione rispetto a quella proposta perché si contestualizzava meglio. Spero non ci perdiate il sonno ;-) --Dry Martini confidati col barista 20:26, 29 mar 2012 (CEST)

Ora discutiamo il merito

Bene, ora che lo abbiamo scritto, vogliamo renderci conto che il patrolling in tempo reale, non potendo umanamente parare tutti gli edit da annullare con rollback secco, lascia passare cose che vengono analizzate solo per settori (cioè per OS, che si profilano secondo campi di interesse)? Nell'ambito delle voci di linguistica, io mi trovo diversi rollback secchi da fare. Alla luce di quale ragionamento io devo fare più strada per annullare questi edit? Solo perché sono pochi? Fegatini di mosca, si dice dalle mie parti. Un'opzione quasi punitiva, certo involontariamente. È come ha detto Gnumarcoo: poniamo un principio irriflesso davanti all'esigenza pratica. Ora è il momento di giustificare questa scelta e in assenza di giustificazioni, cambiare rotta. --pequod ^..Ħƕ 23:59, 29 mar 2012 (CEST)

Favorevole (come già detto) all'introduzione del flag anche ai RetroP™. Oltre all'aspetto pratico, si può rilevare anche un vizio di logica sul piano teorico, volendo proprio cercar il pelo nell'uovo, per cui non vedo perché ostinarsi. --Gnumarcoo 15:53, 30 mar 2012 (CEST)

Favorevole anch'io. Chiedo solo che il flag sia assegnato con la solita cautela (altrimenti rischi di diventare una replica di quello da autoverificato). --Nicolabel 16:03, 30 mar 2012 (CEST)

Un conto è concederlo con cautela (cosa su cui non si prescinde, ovviamente), un conto è darlo al primo Zaccaria (diavolo di terza categoria) che passa. --Gnumarcoo 16:31, 30 mar 2012 (CEST)

IMO non c'è problema, ma un po' di esperienza di patrolling (di qualsiasi tipo) e soprattutto nell'uso del tasto annulla ci deve essere, l'utente deve già avere un po' di casistica personale cui rifarsi. Comunque per me il buon senso è il criterio migliore: non è bene fare muro di gomma contro richieste di utenti scafati (e, a posteriori, se la linea guida non fosse stata così ferrea avremmo anche potuto ignorare le regole con Peq) come è da irresponsabili dare il flag al primo nabbo entusiasta che lo richiede. In conclusione? Rimaniamo sostanzialmente con i criteri di prima, mediati da una buona dose di buon senso, solo che accogliamo nella baby-cricca anche i retropatroller. --Dry Martini confidati col barista 18:24, 30 mar 2012 (CEST)

Sono d'accordo con Dry, l'esperienza (*solida*) di patrolling in generale non è prescindibile. --pequod ^..Ħƕ 21:56, 30 mar 2012 (CEST)

Potrei essere d'accordo pure io con Dry, ma prima di togliere il condizionale vorrei capire in che misura sia richiesta l'esperienza di patrolling.

Permettetemi di personalizzare: non sono mai stato dedito, se non in misura del tutto episodica, a occuparmi del patrolling di prima linea (quello con LiveRC, per intenderci). Tuttavia dopo diversi anni di contribuzione di alcune aree tematiche ho messo in watchlist intere categorie di voci (ad es. i comuni di una certa regione) facile oggetto di modifiche improprie e spesso palesemente vandaliche. Nella mia quotidiana presenza su Wikipedia ho quindi trovato non di rado in watchlist edit da rollbackare, vecchi anche di ore. Ciò nonostante, non occupandomi di patrolling di prima linea, ho ritenuto inopportuno chiedere il flag di rollbacker.

Oggi, con le modifiche alla funzione di cui stiamo discutendo, un utente di lunga esperienza e affidabile (come potevo essere ritenuto io prima di diventare admin), ma mai dedito al patrolling di prima linea e mai stato admin sarebbe o no legittimato a chiedere questo flag? --Nicolabel 02:19, 31 mar 2012 (CEST)

Credo che il criterio attuale possa comunque essere tenuto: se hai dovuto fare revert in misura tale da farti rimpiangere di non avere il tastino e hai l'esperienza per capire quando va usato allora ok, il flag può essere assegnato. Il caso dell'utente espertissimo con zero esperienza in prima linea va valutato caso per caso in base a quanta esperienza ha in "retro-linea". Per me dovremmo iniziare a dare più valore alla motivazione espressa in fase di candidatura (e, magari, a chiedere più dati): chiedere al richiedente di esporre il suo CV di patroller è una cattiva idea? Questo perché spesso si candidano utenti che uno magari non ha mai visto e un piccolo sunto dell'esperienza accumulata potrebbe essere d'aiuto nella valutazione. --Dry Martini confidati col barista 14:11, 31 mar 2012 (CEST)

Cattiva magari no, ma non è di certo una volpata: non è distante la logica del ruolo di rollbacker come medaglietta, a quel punto. Comunque penso stiate trascurando un paio di cose. Rispondendo a Nicolabel: è semplicemente probabile che il tuo numero di OS non ti abbia mai permesso di avere un buon numero di rollback da fare, d'altronde il fatto stesso che un utente come Pequod (che possiamo definire un buon campione analitico in questo senso) lo richieda, vuol dire che in presenza di molte pagine osservate esso è utile e questo è, a mio avviso, sufficiente. @Dry: da sempre, c'è la consuetudine di non dare il flag ai retropatroller - dunque una regola non scritta. Aggiungendo che ora è stata aggiunta la nuova dicitura sopra elaborata, non è comprensibile quando dici: "teniamo il criterio/i (a cosa ti riferisci, per altro?) di prima", è necessario avere del consenso per il cambiamento di rotta e per l'abolizione di quelle poche righe che risulterebbero non poco fuorvianti. Perdonami se per caso ho tralasciato qualcosa e dunque non ho compreso a pieno quello che volevi dire. --Gnumarcoo 15:00, 31 mar 2012 (CEST)

Il criterio attuale è che ai retropatroller non si affida questo tasto, di solito con l'argomentazione "tanto non lo utilizza". Ci si propone di cambiare questo approccio.

Una solida esperienza sul campo del patrolling si matura a tutte le velocità, sia in tempo reale sia in seconda linea. Ovviamente in prima linea si fa più esperienza in meno tempo. Ma la cosa da apprendere rimane sempre saper distinguere un vandalismo luminoso da uno dubbio. A questo proposito, segnalo edit della pagina di aiuto. Non mi sembra che un utente che stia qui da diversi anni e a cui consensualmente si riconosce la sufficiente esperienza per utilizzare il tastino debba avere maggiori difficoltà di un altro utente che magari fa tantissima prima linea ed è più giovane (pedianamente). --pequod ^..Ħƕ 18:43, 31 mar 2012 (CEST)

Favorevole, anzi abbiamo bisogno di molti retropatroller agguerriti. --Bramfab Discorriamo 23:09, 1 apr 2012 (CEST)

favorevole anch'io. --Superchilum^(scrivimi) 23:11, 1 apr 2012 (CEST)

Favorevole anche io come già detto.--l'etrusco (msg) 23:20, 1 apr 2012 (CEST)

Assolutamente Favorevole, vedo già molti utenti che potrebbero farne un ottimo uso. Faciliterebbe il loro compito notevolmente e non vedo alcuna controindicazione. Anzi, visto il consenso fino a qui, direi che si potrebbero già cambiare le linee guida.--Mark91it's my world 20:15, 2 apr 2012 (CEST)

Favorevole anch'io, chi ha una solida esperienza di retropatrolling può trovare dei vantaggi, espressi già da altri, nel avere questo tastino in più. Restu²⁰ 08:19, 3 apr 2012 (CEST)

Ed anch'io sono Favorevole. --Aleksander Šesták 18:24, 4 apr 2012 (CEST)

Sull'attribuzione del flag (segue)

Sto segnalando al bar, perché si tratta di una discussione da mettere in evidenza. Per chi viene dal bar, la discussione inizia nella sezione precedente. --pequod ^..Ħƕ 18:56, 31 mar 2012 (CEST)

@Gnu e Peq: mi sa che ho fatto un po' di casino. Posto che non è sbagliato dare il flag anche a chi fa retro-P (ed è di questo che si sta discutendo, di cambiare la linea guida, con la necessità conseguente, a consenso emerso, di adattarne i vari pezzi, mi pare ovvio), anche in quest'ottica il criterio di assegnazione dovrà restare, con i dovuti adattamenti, quello di adesso: il richiedente deve avere esperienza di patrolling, non si scappa (solo che d'ora in poi vale sia il retro sia il live patrolling). Onestamente, non vedo il pericolo di "mitizzare" il flag: il "CV" io lo vedo solo come un modo di semplificare la procedura, di farsi un'idea del livello di esperienza dell'utente senza conoscerlo a fondo da prima, bastano poche righe, eh. Può essere che abbia saltato qualche pezzo a mia volta, nel caso fatemelo notare. --Dry Martini confidati col barista 22:30, 31 mar 2012 (CEST)

No, ma secondo me abbiamo frainteso il tuo discorso. Io ero certo che ti stavo fraintendendo, per cui ho voluto ribadire l'ovvio (certo che fosse ovvio anche per te). Penso che la premura di Gnumarcoo fosse quella di evitare fraintendimenti sul rapporto tra questa discussione e la crono della pagina di cui stiamo discutendo.

Ok, dunque, quello che abbiamo sempre fatto è stato di valutare le richieste. E va benissimo così. Il curriculum sta nella pagina dei contributi, quello che uno fa su wp, e la talk dell'utente. Con il buonsenso, cioè con fiducia nel fatto che persone di cui ci si fida assumano in modo onesto decisioni importanti (ma di fatto solo relativamente importanti, poiché anche un errore non è pregiudiziale per il progetto nel suo complesso), ce la siamo sempre cavata quanto a flag di rollbacker. Insomma, eviterei la presentazione del cv, lo trovo fuorviante, perché una valutazione seria prescinderebbe per forza di cose di quella presentazione. L'unico aspetto di cui dobbiamo discutere è questo edit sulla faccenda dei retropatroller. Siccome tra gli intervenuti c'è accordo, mi pare, sulla possibilità di accordarlo ai retropatroller, purché, con i soliti mezzi (una valutazione) si vagli la conoscenza del mondo del patrolling, aspetterei altri pareri dopo la segnalazione al bar. --pequod ^..Ħƕ 02:29, 1 apr 2012 (CEST)

Sì, in effetti il cv sarebbe un po' un avvitamento burocratico. L'unica cosa che resta da fare è rivedere la linea guida: certamente il mio edit va rivisto (non lo toglierei del tutto, alcune considerazioni, dopo una smorzatura, sono ugualmente valide, IMO, ma ditemi pure la vostra), assieme però a tutta la pagina, che era stata comunque scritta nell'ottica di dare il flag solo ai live-patroller. --Dry Martini confidati col barista 21:31, 1 apr 2012 (CEST)

Sono favorevole all'allargamento del flag anche ai retropatroller, senza dover modificare l'attuale procedura di attribuzione (basata su una breve presentazione personale, che può essere ampliata se il burocrate chiede maggiori dettagli). In una frase concisa: il flag può essere assegnato a coloro che hanno spesso bisogno di effettuare annullamenti delle modifiche e che abbiano maturato una buona [esperienza nel patrolling / conoscenza dello strumento "annulla"]. ·· Quatar » posta « 11:44, 3 apr 2012 (CEST)

L'attuale procedura di attribuzione non è mai stata in discussione.

Visto il consenso, ho modificato la linea guida. --pequod ^..Ħƕ 15:50, 3 apr 2012 (CEST)

Ben fatto. Ho sistemato con una precisazione per evitare un'apparente contraddizione, ma la tua formulazione, Peq, era comunque chiara. --Dry Martini confidati col barista 17:09, 3 apr 2012 (CEST)

Critica meramente di forma: @Dry: la specifica la trovo poco fluida sintatticamente e comunque poco utile visto che, si spera, uno la pagina la legga per intero dato che non è nemmeno molto lunga. Io taglierei... ora fate vobis. --Gnumarcoo 17:43, 3 apr 2012 (CEST)

IMHO la poca fluidità era ascrivibile alla mia formulazione e l'osservazione di Dry corretta. Ho cercato di riformulare così. --pequod ^..Ħƕ 03:00, 4 apr 2012 (CEST)

rollbacker e js

Su IRC si è discusso del fatto che con i javascript si possono facilmente fare azioni che si possono fare con il flag di rollbacker. Premesso che qualunque effetto che potrebbe avere su Wiki un rollbacker, lo può ottenere anche un utente normale, sin da prima che esistesse il flag di rollbacker era liberamente possibile usare js che permettevano con un click la medesima cosa e non c'è mai stato problema. Mi si dice che oggi, poiché esiste il flag di rollbacker, questi strumenti in js (es. i popup, twinkle) non sarebbero da usare se non si ha il flag di rollbacker, perché imitano la funzione di questo flag. Faccio alcuni rilievi:

• Wikipedia è una società aperta in cui si presume la buona fede: io direi che se uno si avvale di uno strumento potente ne risponde in caso di errore: si arresta chi uccide col coltello, non chi ha un coltello...
• Anche limitando i js qui, non conterebbe nulla, poiché se uno davvero volesse avere la possibilità di fare rollback con un click:
  • se uno vuole, trova un qualunque metodo di interrogazione delle API alla portata della sua utenza e con un script sul suo PC, lavora come i rollbacker e non glielo possiamo impedire;
  • eventualmente se si limitassero i js qui e uno volesse comunque usare il browser, si possono fare script per Greasemonkey e non lo possiamo impedire;

Pertanto io direi che limitare i js solo perché altrimenti si farebbero le stesse cose che si fanno con un diritto del software sarebbe un autogol, a noi interessa la crescita del sito (e la sua protezione in questo caso), mica la costruzione di una struttura sociale piramidale con i rollbacker fra i gradini. :) Chiedo vostri pareri.--Nickanc ♪♫@ 18:54, 25 giu 2012 (CEST)

Ehi, io non ho mai fatto un ragionamento basato su principi di casta, ho semplicemente notato che, dato che si ritiene che lo strumento "rollback" è critico e quindi va regolamentato (per adesso, infatti, ce l'hanno solo admin e rollbacker, ci sarà un motivo), non ha molto senso lasciare platealmente campo libero a chi il flag non lo ottiene (magari perché si ritiene che non sia in grado di usarlo correttamente), ma sarebbe meglio limitare la disponibilità dello strumento (i popup e twinkle restino accessibili, per carità, parlo solo dello strumento di rollback simil-admin). Certo, se uno proprio ci si mette riesce a ottenere gli stessi risultati, ma dare in mano al primo utente che passa (perché tutti gli utenti possono usare quegli strumenti, anche chi è arrivato su Wikipedia da pochissimo) uno strumento che è un po' più che un semplice annullamento è un'altra cosa: per proseguire la tua analogia, si tratta o di girare con un cesto di coltelli per la città e lasciare che chiunque peschi a piene mani o di distribuire coltelli personalmente facendo attenzione che bambini e pregiudicati non li ricevano; ovvio che il pregiudicato o il bambino può comunque mettere le mani su un coltello. Se invece partiamo dal presupposto che questo strumento non è critico, a questo punto credo sia un bene estenderlo a tutti gli autoverificati e abolire il flag di rollbacker. E mi starebbe anche bene, purché si ritenga unanimemente che non si tratta di uno strumento che necessita di esperienza (e allo stato io non sono dell'opinione).--Dry Martini confidati col barista 19:32, 25 giu 2012 (CEST)

Aggiunta di una funzione al gruppo rollbacker

Negli ultimi tempi mi sono dedicato assiduamente al patrolling e ho visto all'opera la macchina di difesa di it.wiki nei confronti di chi non ha nient'altro da fare che modificare impropriamente il duro lavoro di molti. L'integrazione di sysop, rollbacker e patroller è tale che il conflitto di edizione è la regola, non l'eccezione e più spesso l'utente si ritrova con avvisi doppi piuttosto che senza avvisi; la comunicazione tra utenti è abbastanza efficace e la gestione della modifica impropria effettuata è, secondo me, ben strutturata. L'unica situazione che mi pare possa dirsi certo non inefficiente, ma migliorabile, è la prevenzione di ulteriori modifiche improprie da parte dallo stesso utente, ed è per questo che mi chiedo se non sia possibile attribuire ai rollbacker la possibilità di effettuare blocchi brevi, della durata massima di un giorno, solamente a contributori anonimi. Vedo in questa proposta due argomenti a favore:

• Attualmente la procedura prevede di segnalare il vandalismo nell'apposita pagina, un sysop prende in carico la segnalazione, controlla le modifiche ed eventualmente blocca. Tutto questo può durare da diversi secondi a qualche minuti, durante i quali il vandalo può arrivare a modificare anche decine di altre voci. Il ripristino è senza dubbio rapido, ma rimane il fatto che quelle modifiche possono essere e sono effettuate. La possibilità di bloccare da parte dei rollbacker azzera questo intervallo temporale, riducendo sensibilmente il numero di modifiche vandaliche.
• La presenza di sysop è pressoché continuativa durante la giornata, tanto che non è la regola che un vandalo scorrazzi libero, facendo ciò che vuole. Però è innegabile che ci sono volte in cui questo succede, e me ne sono accorto recentemente durante gli Europei di Calcio. Rollbacker con la funzione di blocco aggiungerebbero numerosità ai sysop dediti al patrolling, riducendo la frequenza di periodi non coperti potendo rispondere essi stessi alle segnalazioni di vandalismo da parte dei patroller.

La possibilità di bloccare solo gli utenti anonimi deriva da due considerazioni:

• La grandissima maggioranza delle modifiche improprie è apportata da anonimi, soprattutto IP dinamici e condivisi e le cui modifiche sono spesso simili (basti pensare al solito anonimo che passa il suo tempo a rimuovere le classifiche del motomondiale.
• Il blocco di utenze è, secondo la mia opinione, prerogativa unica dei sysop, in quanto essi sono stati eletti proprio per utilizzare questa funzione in osservanza delle regole e delle politiche adottate dalla comunità. Vista la natura e le modalità di assegnazione del gruppo rollbacker, questo privilegio sarebbe improprio, dovendo da una parte necessariamente far rivedere le modalità di assegnazione, dall'altra attribuendo prerogative non proprie della funzione. Credo invece, ma questo è il punto su cui c'è bisogno inevitabile di discutere, che l'utilizzo di questa funzione nei confronti di palesi vandali anonimi, possa invece essere ritenuta coerente con l'attuale definizione di rollbacker.

Un altro dubbio riguarda la fattibilità tecnica, senza la quale discutere è inutile. --Aplasia 13:53, 7 lug 2012 (CEST)

Favorevole, quanto alla fattibilità, si apre una segnalazione sul nostro bugzilla: e i devs aggiungono la funzione. :)--Nickanc ♪♫@ 14:00, 7 lug 2012 (CEST)

Completamente d'accordo. --AndreaFox ^{bussa pure qui...} 14:03, 7 lug 2012 (CEST)

Le tanto conclamate limitazioni non sono implementabili, il principio di mettere i registrati su un piano "superiore" poi è abbastanza sbagliato. --Vito (msg) 15:33, 7 lug 2012 (CEST)

Contrario Non è la prima volta che viene fatta una proposta del genere. Dalle discussioni pregresse è emerso che la possibilità di bloccare debba essere data a chi ha ricevuto la fiducia da parte della comunità. Inoltre, credo di non sbagliarmi, il permesso block non fa distinzione tra IP e utente registrato. --Buggia 14:06, 7 lug 2012 (CEST)

(conflittato) Non mi esprimo, dico solo che non siamo stati flaggati per questo compito. Il blocco di un IP non è cosa da poco (si rischia di bloccare dal sig. Rossi ad un intero hotel passando per un proxy di un ufficio, magari della regione a cui sono connessi 600 terminali). Ergo, cambierebbe la procedura di assegnazione del flag, e con essa passo logico è sflaggarci tutti ed eventualmente riflaggarci.--Seics (ti pigliasse lo spread) 14:11, 7 lug 2012 (CEST)

Contrario Per disporre di altri permessi oltre quelli già accordati - e in particolare quelli di block/unblock - è indispensabile che vi sia il più ampio possibile consenso, codificato nello svolgimento di un'elezione, col raggiungimento di un quorum e di una maggioranza assai alta. --M/ 14:14, 7 lug 2012 (CEST)

Sono mesi che ogni tanto ci ragionavo sulla possibilità di brevi blocchi da parte dei non admin: in molti casi può essere sufficiente un paio d'ore di riposo forzato. Ancora più restrittivamente si potrebbe assegnare un "monte-ore" giornaliero dopo il quale la funzione è disabilitata fino al giorno successivo. Senz'altro un po' utopico (e magari se mi legge uno sviluppatore chissà cosa penserà...). Meno utopico, ben più concreto è invece il pericolo di bloccare un intero gruppo di utenti, forse un'intera città se non si sta attenti (e non si conoscono i dettagli tecnici degli IP). --Pracchia 78 (scrivimi) 14:14, 7 lug 2012 (CEST)

Contrario vedi Buggia ed M7.--Dome era Cirimbillo ^{A disposizione!} 14:16, 7 lug 2012 (CEST)

Contrario se un utente gode di sufficiente fiducia per effettuare un blocco, la ha per diventare amministratore. --Roberto Segnali all'Indiano 15:02, 7 lug 2012 (CEST)

Contrario Esattamente come Roberto, M7, ecc. --Veneziano- dai, parliamone! 15:04, 7 lug 2012 (CEST)

Contrario Quoto Roberto. --pequod ^..Ħƕ 15:24, 7 lug 2012 (CEST)

• fortemente favorevole: ottimo modo per dividersi i compiti. La limitatezza del blocco e la possibilità di darlo solo ad IP è una genialata che eviterà futili discussioni. — Questo commento senza la firma utente è stato inserito da Zerosei (discussioni · contributi) 15:29, 7 lug 2012 (CEST).
• Contrario per i motivi espressi sopra dagli altri utenti. --Aleksander Šesták 16:02, 7 lug 2012 (CEST)

Commento: Dal momento che Vito dice che non vi è la fattibilità tecnica, credo sia inopportuno continuare a discutere; questa funzione, qualora fosse stata implementabile, avrebbe a mio avviso garantito un'arma in più nella protezione di it.wiki dal vandalismo quotidiano. Le obiezioni riguardo la necessità di ampio consenso per la funzione sono perfettamente condivisibili e la questione rappresentava per me l'unico altro dubbio riguardo alla questione. La possibilità di errori è a mio avviso ininfluente, perché così come impara il sysop neoeletto, può imparare anche un altro utente. --Aplasia 16:10, 7 lug 2012 (CEST)

@ Aplasia. Comunque converrai che una simile possibilità comporterebbe anche una supervisione, cioè un controllo dell'operato del rollbacker e in ultima analisi un compito aggiuntivo per gli admin e categorie superiori. --Pracchia 78 (scrivimi) 16:25, 7 lug 2012 (CEST)

Inizialmente senza dubbio, ma con il tempo, se l'utente si rivelasse affidabile nel suo operare, la supervisione sarebbe superflua. --Aplasia 16:57, 7 lug 2012 (CEST)

Contrario Non sono molto convinto: bloccare impropriamente per 1 giorno un ip può essere molto più dannoso per wp che infinitare un utente registrato. Credo che la difficoltà maggiore nel patrolling non sia bloccare, ma piuttosto capire quando non bloccare. Un blocco può avere conseguenze imprevediblili sulla persona bloccata, che dipendono fortemente dalla sua personlità, e credo che che le azioni più difficili in questa mansione siano quelle in cui il dialogo riesce ad evitare il blocco: preferisco vedere un ip che vandalizza indisturbato per mezzora piuttosto che vedere un ip che contibuisce da anni smettere per sempre di editare per aver ricevuto un blocco ingiusto. Dato che abbiamo un sacco di bravi rollbackers penserei piuttosto quali flaggare ad admin :-) --^musaz † 19:18, 7 lug 2012 (CEST)

Contrario Ma scherziamo? non son cose da prendere alla leggera queste --Fabexplosive L'admin col botto 20:58, 7 lug 2012 (CEST)

Contrario Due motivi: 1) affinché non si ricada nel problema già discusso altrove dei mini admin, le modifiche previste andrebbero implementate a livello tecnico, ovvero andrebbero distinti il "blocco entro 24 h" ed il "blocco di utente non registrato", e relativi sblocchi, da "blocco/sblocco" generico, cosa attualmente non realizzabile e 2) il diritto di rollbacker attualmente è dato abbastanza "con leggerezza" proprio perché attribuisce diritti limitati, se dovesse attribuire diritti su utenti, andrebbe leggermente ripensato, bloccare un utente non registrato non è una cosa da prendere alla leggera. --Superfranz83 _{Scrivi qui} 22:06, 7 lug 2012 (CEST)

Non credo che questo flag venga dato abbastanza con leggerezza, altrimenti i rollbacker non sarebbero meno di 20. --Aleksander Šesták 00:25, 8 lug 2012 (CEST)

Contrario Non me ne voglia il bravissimo Aplasia ma non credo che sarebbe una buona idea. Bloccare un IP non è uno scherzo, nella marea di contributori occasionali, vandali, ragazzini ci sono diversi utenti non registrati che lavorano ottimamente e che sarebbe quanto di meno wikipediano perdere per un blocco dato con leggerezza. Un conto è rollbackare uno o più edit, pazienza, si recuperano se è il caso, altro è bloccare un utente con il rischio di scacciarlo a pedate da WP. Un rollbacker non è passato dal vaglio del consenso, alla discussione per l'attribuzione del flag si contano mediamente tre o quattro interventi, e prendere cantonate sugli utenti è facile (ne ho prese anch'io, non c'è bisogno che faccia esempi immagino).--l'etrusco (msg) 23:55, 7 lug 2012 (CEST)

Io credo si parli palesemente di IP (no utenti) vandalici. Il blocco sarebbe comunque arrivato. --Zero6 ✉ 01:22, 8 lug 2012 (CEST)

• Fortemente contrario: bloccare un utente è una funzione molto delicata, che non a caso è limitata ai soli amministratori. Creare "amministratori di seconda fascia" genererebbe una corsa a questo "flagghino" e potenzialmente porterebbe più danni che altro. --Sannita - L'admin (a piede) libero 12:28, 8 lug 2012 (CEST)

Per questioni relative ai "diritti dei gruppi utente" invito a dare un'occhiata a Speciale:ElencoPermessiGruppi: lì è chiaramente ed esattamente indicato chi può fare cosa (a meno di modifiche al software, s'intende). E dire che quella stessa pagina è stata linkata in una discussione "tecnica" abbastanza recente... a cui qualcuno degli intervenuti qui sopra ha pure partecipato. Segnatevela gente, segnatevela...--DoppioM 16:05, 8 lug 2012 (CEST)

Infatti giusto ieri ho chiesto che il permesso di inserire link esterni fosse scorporato. --Vito (msg) 17:43, 8 lug 2012 (CEST)

• Contrario Quoto Roberto Mura. --Retaggio (msg) 10:40, 9 lug 2012 (CEST)
• Commento: Tecnicamente non è fattibile, quindi questa è una discussione solo simbolica. Penso sia giusto che le funzioni di blocco restino prerogativa dei sysop, semmai si potrebbero aumentare i sysop in modo che presidino un po' tutti gli orari (anche quelli notturni). Se funzioni delicate venissero estese ai rollbacker alla fine l'accesso al flag diventerebbe molto più difficoltoso con danno alla stessa funzione del patrolling, che priverebbe più utenti di uno strumento utile (il flag con il relativo tastino) di quanti invece accederebbero alla funzione di blocco aggiuntiva. --IndyJr (Tracce nella foresta) 11:15, 9 lug 2012 (CEST)

Se si riserva la facoltà di blocco soltanto a vandali espliciti, con interventi volgari/scherzosi/ridicoli/senza senso/con battute casuali sulla tastiera, sarei assolutamente favorevole alla proposta, in modo da troncare sul nascere una quantità molto importante di vandali con il solo scopo di scrivere stupidaggini, falsità assurde e ridicole, insulti, bestemmie (lì so già che servirebbe la rimozione della differenza nella cronologia di una pagina così vandalizzata) e così via. Per il resto dei motivi di blocco, direi che debbano essere, per la loro buona fede e per la fiducia che la comunità ripone anche a categorie meno "moderatrici" dei sysop, come i rollbacker, di astenersi da decisioni che possono essere contestate (o comunque discusse) con probabilità molto maggiori rispetto ai rischi ai quali si può andare incontro con i vandalismi espressi in precedenza. Scusate l'italiano malcurato e zoppicante, ma ho una certa fretta. Saluti! Carlo (appassionato di Wikipedia) aka --82.60.94.100 (msg) 21:07, 11 lug 2012 (CEST)

Il problema di una scelta di questo tipo (della serie "diamo la funzione block ai rollbacker in tutta la sua interezza, ma devono usarla solo in certe situazioni") sarebbe a mio avviso ingestibile, poiché gli utenti dovrebbero controllare se il rollbacker non ha comminato blocchi a vandali non espliciti. Non vorrei che poi gli utenti dovessero controllare anche come vengono usati i blocchi dai rollbacker, perché ci sono molte altre cose da tenere sott'occhio su Wikipedia. :-) Restu²⁰ 02:40, 12 lug 2012 (CEST)