Wikipedia:Bar/Discussioni/Contributi discutibili, come gestirli

Discussione iniziale

Sto osservando questa discussione. Siamo alle solite, un anonimo inserisce a manetta info "discutibili", e noi lasciamo giustamente correre fino a quando non ci si rende conto, troppo tardi, dei disastri compiuti. Sono il primo ad essere incappato in questo laissez-faire con quell'utente passato alla nostra storia come il "cabbalista fondamentalista". Vista la cronica mancanza di utenti, io e Monozigote pensavamo di recuperarlo a un contribuire più attento e meno "settario". Poi Pequod si accorse che il numero dei "disastri" compiuti era di gra-n lunga maggiore dei benefici che ancora non arrivavano... e ci rimproverò, giustamente, di averlo lasciato correre nonostante i ripetuti avvertimenti che gli "lanciavamo" contro. La storia si ripete e si ripete, da una parte aspettiamo nuovi contributori, dall'altra faticosamente cerchiamo di "formarci" e di "formare" al metodo enciclopedico, al contempo Wikipedia "attira" anche e vieppiù personaggi di ogni risma con intenzioni decisamente non wikipediane. Ne è ben consapevole la WikiDE, la Wikipedia in lingua tedesca, la quale in modo assolutamente tranchant ha chiuso di fatto la collaborazione agli utenti non verificati e lo ha fatto in modo subdolo: l'utente non verificato, anche se registrato, inserisce un contributo che, dopo aver salvato, vede solo lui, questo finché non viene validato da qualche utente "verificato"... La "soluzione" gli semplifica certamente la vita ma da una parte fa mancare a quel progetto lo spirito wikipediano e dall'altra non gli impedisce le papere. Tempo fa ho corretto un grossolano errore in quel progetto e mi sono vista la correzione sospesa..., passato un po' di tempo ho pensato che magari non li avevo convinti, quindi gli ho linkato la foto ufficiale del testo ufficiale dell'editore ufficiale dove era evidente la loro papera... niente e la papera troneggia ancora lì chissà tra quante e io su WikiDE non correggerò più una loro papera, e sì che ne becco di tanto in tanto anche se la WikiDE è ad oggi, in termini di contenuti, il progetto migliore, di gran lunga migliore, tra tutte le Wiki. Ecco... la soluzione della WikiDE non è certamente percorribile ma loro hanno scelto qualcosa che gli rende la vita infinitamente più facile con voci stabili a livelli più che decenti di qualità. Noi siamo pochi e non serve portare a livelli di decenza una voce quando poi, dietro l'angolo, si cela l'anonimo di turno che non scrive "cacca puzza", perché in quel caso il suo contributo viene subito cancellato, ma scrive anche di peggio facendolo magari fontare da qualcosa di peggio di quello che lui scrive. E la voce "decente".... diventa indecente e così rimane.... Gli utenti sono infatti pochi e gli admin e gli rb, fatto salvo i "cacca puzza", intervengono sui contenuti che conoscono... e non potrebbe essere altrimenti. Il disastro è certamente dietro l'angolo. Allora mi è venuta un'idea... non è che nella crono delle voci si possono evidenziare in giallo i contributi di utenti non-verificati di modo che passando di tanto in tanto ci si concentra su quei contenuti onde verificarli? E' anche un avvertimento, a chi la farà sempre e comunque franca, che i suoi contributi ancorché salvati e leggibili sono sotto osservazione. Boh magari la mia proposta fa acqua, ma qualcosa occorre fare. --Xinstalker (msg) 10:49, 2 feb 2016 (CET)

Che il sistema di default di wp non sia granché mi pare certo. Alludo alla visualizzazione (non solo in crono) dei contenuti da verificare. Si prendano gli Osservati Speciali: lì, un minuscolo punto esclamativo in rosso avverte che l'ultima modifica è da verificare. Invece nella crono questa informazione (ovviamente applicata a tutte le modifiche) non è più ritenuta di interesse. Mi sembra che un minimo di coerenza suggerirebbe soluzioni diverse. Sono d'accordo con la proposta di Xin: le modifiche da verificare vanno messe meglio in evidenza. Ad oggi è già possibile farlo, ma al prezzo di molesti "add-on" da installare tra le preferenze. Preferirei qualcosa di concordato che venga messo di default per tutti. pqd...Ƿƿ 15:02, 2 feb 2016 (CET)

l'idea di de.wiki è disastrosa, sulla voce di Totò c'è ancora un De Filippo al posto di Memmo Carotenuto nella foto: basta essere di origini italiane per capire l'errore grosso fatto, così in Germania i tanti oriundi magari lo staranno notando.. l'idea di Xin è ottima ma non basta perché bisogna rendere il più facile possibile il lavoro degli admin che così avrebbero più tempo per bloccare i vandali: un modo potrebbe essere quello di aumentare i filtri, in modo tale da ridurre certi vandalismi.. Comunque, ammettiamolo, in molti casi il lavoro ce lo complichiamo noi wikipediani. Non esiste un modo per (per esempio) di aggiornare con una sola modifica su wikidata o progetti analoghi carriere, discografie o filmografie che sono perciò a rischio vandalismi, tra le altre cose.. Oppure gli oltre 200mila superstub, oppure il tempo a volte sprecato fuori dall'ns0, potrei continuare per ore.. --79.34.147.233 (msg) 15:25, 2 feb 2016 (CET)

Già, questo continuare per ore è l'anticamera del non concludere mai nulla e sta al capitolo "benaltrismo", parente del "tuttismo". Possibile che non si riesca a discutere di una cosa alla volta? No, deve sempre esserci dell'altro, sembra quasi che importi sembrare fighi, io non capisco... E sullo sfondo l'immancabile e immortale "ns0ismo", ossia la religiosa convinzione che oltre il ns0 non c'è nulla, che non significa granché ma è più prudente che sostenere il contrario. Per favore, non rispondermi, attieniti al topic, una buona volta!! pqd...Ƿƿ 15:43, 2 feb 2016 (CET)

in poche parole bisogna adottare tutte e "100" le misure utili, non solo una, a caso o no. --79.34.147.233 (msg) 15:46, 2 feb 2016 (CET)

Purtroppo la filosofia wiki agevola queste situazioni di edit farlocchi, blocchi a priori sono stati proposti ma mai accettati se non in casi estremi. Non esiste/si potrebbe creare una pagina di servizio che elenchi tutte le voci di ns0 con modifiche non controllate? Ed eventualmente un tool che permetta di verificare le versioni precedenti, dopo ovvia verifica del contenuto? --Ghess-hu? (Indovina chi) 16:07, 2 feb 2016 (CET)

Certo, è stato discusso innumerevoli volte: Wikipedia:Bar/Discussioni/Affidabilità degli utenti calcolata in automatico, Wikipedia:Bar/Discussioni/Versioni stabili in de.wiki, Wikipedia:Bar/Discussioni/Lurkando in giro..., Wikipedia:Bar/Discussioni/Quality.wmf, Wikipedia:Bar/Discussioni/Proposta di nuova funzionalità ecc. ecc. Nemo 18:52, 2 feb 2016 (CET)

Sarà vecchia, ma il problema resta... a me interessa la soluzione del problema più che la freschezza o novità di una discussione. --Xinstalker (msg) 19:03, 2 feb 2016 (CET)

Non capisco bene di cosa si stia parlando. Se si tratta di vandalismi, non ci sono già pagine di servizio apposite? (E anche per casi che non sono vandalismi, ma comunque problematici ad esempio utente in write only) --62.19.43.168 (msg) 19:15, 2 feb 2016 (CET)

Allora mi è venuta un'idea... non è che nella crono delle voci si possono evidenziare in giallo i contributi di utenti non-verificati di modo che passando di tanto in tanto ci si concentra su quei contenuti onde verificarli? E' anche un avvertimento, a chi la farà sempre e comunque franca, che i suoi contributi ancorché salvati e leggibili sono sotto osservazione. Ecco di cosa si sta parlando. Xinstalker ha delineato un panorama e ha fatto una proposta. "bisogna adottare tutte e "100" le misure utili, non solo una" è il tuttismo di cui sopra, il vero disastro, che sta agli antipodi del meccanismo concreto di wp, un wip, una cosa che si migliora nel tempo. Stando all'anonimo dovremmo prima spendere dieci anni a individuare le 100 soluzioni perfette, per poi adottarle. Non è così che funziona. Quindi, per favore, ce la facciamo a commentare, a criticare, a migliorare la proposta? Non altro, ma la proposta che è stata fatta. Essa peraltro non è alternativa ad altre cose che possono eventualmente essere messe in piedi, ma che vanno discusse singolarmente, proprio per renderle al meglio (ciascuna proposta ha le sue problematiche tecniche, pratiche, teoriche ecc. e bisognerebbe discuterne con ordine). WP:Wikipedia non è un'ordalia. pqd...Ƿƿ 19:22, 2 feb 2016 (CET)

La proposta di evidenziare in crono i contributi non verificati mi trova favorevole, semplificherebbe non poco il lavoro di retropatrolling, che attualmente è piuttosto lungo e noioso (= quasi mai fatto)---l'etrusco (msg) 19:32, 2 feb 2016 (CET)

(Rientro) Pequod, la proposta va bene, l'ho detto, l'approvo :).. Volevo solo dire che oltre quella, giacché ci siamo, possiamo pensare anche a misure aggiuntive.. --79.34.147.233 (msg) 20:31, 2 feb 2016 (CET)

Per quel che posso, sottoscrivo: non è che nella crono delle voci si possono evidenziare in giallo i contributi di utenti non-verificati di modo che passando di tanto in tanto ci si concentra su quei contenuti onde verificarli?. Se possibile, sarebbe in realtà una cosa *estremamente* utile, faciliterebbe molto il retropatrolling. Gradirei solo un sistema meno invasivo dell'evidenziazione (e che non faccia a cazzotti conver il sistema delle scored revision). --Retaggio (msg) 20:35, 2 feb 2016 (CET)

Pieno appoggio alla misura proposta da Xinstalker, che si tratti di evidenziazione o di qualcosa di meno invasivo. --Epìdosis 21:05, 2 feb 2016 (CET)

[← Rientro] Scusate, leggo un po' di confusione nei termini, cerco di fare un po' di chiarezza. Innanzitutto non ci sono "utenti verificati" ci sono "utenti autoverificati", che è stata la traduzione per autopatrolled. Cosa vuol dire? In sostanza in itwiki è attiva l'estensione mw:Help:Patrolled edits. Questa funzionalità aggiuntiva consiste graficamente nell'evidenziare con un punto esclamativo (!) le modifiche in Speciale:UltimeModifiche da verificare, ossia quelle apportate da utenti non autoverificati. Ora l'estensione mette questi punti esclamativi solo in Speciale:UltimeModifiche non nella cronologia delle voci. Se quello che si vuole è che questi punti esclamativi (o una altra forma di evidenziazione) appaiano anche nella cronologia delle voci, credo che il posto giusto dove chiedere se possibile, non per farlo, sia innanzitutto la pagina di discussione di mw:Help:Patrolled edits. --Rotpunkt (msg) 22:10, 2 feb 2016 (CET)

Pienamente d'accordo. Credo che anche l'idea del punto esclamativo, per uniformità con le recentchanges, sia la soluzione migliore. Appoggio. --Retaggio (msg) 22:19, 2 feb 2016 (CET)

Dimenticavo una curiosità, per dovere di cronaca, visto che se ne parla e magari qualcuno non lo sa. Come scrissi una volta qui, questa funzionalità di evidenziare le modifiche dei non autoverificati è assolutamente rara nel panorama dei progetti wikipedia, non la usa nessuno a parte noi, frwiki, ptwiki e qualche wiki minore. Tutte le altre lo fanno solo per le nuove pagine. Con questo non voglio dire che non serva, ci mancherebbe, magari qui su itwiki è considerato un metodo ottimo, ma solo per informazione. --Rotpunkt (msg) 22:24, 2 feb 2016 (CET)

Scusate io non ne capisco molto, so solo che abbiamo un grosso problema e osservo che questo grosso problema crescerà sempre di più. Intendo dire che di persone che controllano i contenuti, non i vandalismi, che i contenuti validi inseriti a loro tempo con fonti valide rimangano tali e non vengano sostituiti da sciocchezze interplanetarie... beh questi utenti sono numericamente sempre di meno. O gli si dà una mano oppure la mole di lavoro li stritolerà e con loro devasterà il progetto. Piano piano senza che ce ne accorgiamo troveremo lì dove c'era qualcosa di più che decente un deserto di scemità. Piano piano senza che nessuno se ne accorge, sembrano ai più modifiche sensate con fonti decenti. No! non è così e non sarà così. Penso ai lavori di Monozigote, Tonii, DonatoD, etc.etc. che ora non ci sono e chissà se e quando torneranno, beh quelle voci curate da persone che hanno davvero studiato ogni giorno sono a rischio del "cabbalista fondamentalista" di turno se non di peggio. Occorre fare qualcosa, davvero io forse ho proposto una sciocchezza non lo so non ci capisco ma occorre che i pochi che sono rimasti possano aprendo la cronologia subito beccare ciò che va controllato e i vari "cabbalisti fondamentalisti" devono sapere che la loro devastazione sta lì segnalata pronta ad essere scaraventata fuori al primo controllo perché c'è qualcosa che chiede un controllo e questo deve essere evidente. Se no tutto quel lavoro di quelle persone andrà inesorabilmente a farsi friggere. Conosco la WikiDE e la WikiEN, i primi fanno la guardia alle voci e i secondi sono tanti. Noi siamo pochi e nessuno fa la guarda alle voci se non per cancellare "cacca puzza" che danneggia infinitamente di meno del "cabbalista fondamentalista" perché lo dice chiaramente cosa è... --Xinstalker (msg) 22:57, 2 feb 2016 (CET)

I dati importanti di Wikipedia, della nostra Wikipedia, non possono esaurirsi in: "numero delle voci", "Kb delle stesse" e "numero dei loro lettori". Non può essere così difendiamo anche quella qualità che faticosamente andiamo conquistando! Non posso pensare che alla fine noi ci trasformiamo in Nonciclopedia mentre i tedeschi adottando quel terribile metodo crescono i loro lettori nella qualità che hanno faticato a creare e poco faticato a mantenere! --Xinstalker (msg) 23:01, 2 feb 2016 (CET)

Complimenti a Xin per la lucidità della proposta e +1 convinto: anch'io sono per una soluzione che privilegi la standardizzazione, introducendo nella cronologia un punto esclamativo (come in Speciale:RecentChanges) o ancora meglio uno sfondo giallo (come in Speciale:NewPages). Perché la cosa sia davvero efficace, però, in cronologia e tramite popup occorrerebbe anche un pulsante per verificare agevolmente le modifiche. --Nicolabel 23:07, 2 feb 2016 (CET)

@Xinstalker mi dispiace per i problemi che affliggono le voci di cui ti occupi, che possiamo riassumere in "POV pushing", ossia dell'inserimento di informazioni non neutrali, ma ti assicuro che coinvolgono tutti i progetti, non solo gli argomenti di cui ti occupi tu. Se guardi le pagine di discussioni dei progetti, sono piene di "Controllate gli inserimenti di quell'utente perché sta inserendo informazioni errate ..." e si risolvono grazie all'aiuto di vari utenti competenti che vanno a fermare l'utente e correggere le pagine. Purtroppo probabilmente negli argomenti di cui ti occupi ci sono poche persone competenti. Però è difficile creare queste persone dal nulla, c'è da sperare che ne arrivino di nuove e che trovino il progetto dove discuterne e organizzarsi. Il lato tecnico, come questo in particolare, può dare sicuramente una mano ma se non ci sono le persone competenti che capiscono cosa correggere è comunque difficile. --Rotpunkt (msg) 23:20, 2 feb 2016 (CET)

Un'osservazione en passant: avevamo un ottimo strumento "umano", una raccolta di voci che, a giudizio della comunità, erano oggetto di un vandalismo particolarmente reiterato. Ricordo che c'erano, per ovvie ragioni, il bue, il gallo, il cane ecc., ma anche il verbo, l'avverbio... Per qualche ragione, un elenco di un centinaio di voci riesce a ricomprendere in sé la summa dei poli magnetici del vandalo simplex. In periodi particolari era possibile integrare la lista e poi eventualmente ritoccarla... Con un click sulle modifiche correlate alla lista si otteneva una panoramica ottima sullo stato delle cose. Cosa abbiamo fatto? L'abbiamo cancellata... Pensate che possa essere utile alla causa? Io sì! Allora fu inutile discuterne: con la cancellazione chissà cosa si voleva ottenere, un fatuo senso di pulizia? Boh. Invece la presenza in una lista del genere sarebbe un ottimo indizio per patroller e retropatroller.

Per il cabalista urge una soluzione mirata, bisogna bloccargli la tastiera.

Più in generale ci vorrebbero dei "punti di ripristino", in modo che sia facile per un retropatroller individuare una versione da raffrontare alla corrente.

Mi sta bene qualcosa di discreto, ma il punto esclamativo è un po' miserando... pqd...Ƿƿ 23:54, 2 feb 2016 (CET)

@Pequod76 Una volta che nella cronologia si avesse il punto esclamativo (!), tramite accessori, o tramite gli script globali, si può poi evidenziare in qualunque altro modo di voglia. Mi pare che per uniformità (e non invasività) è meglio partire da una situazione uguale tra Speciale:UltimeModifiche e la cronologia di una voce, sapendo che poi si può personalizzare come meglio si crede. Comunque ripeto, bisognerebbe innanzitutto chiedere nella pagina di discussione di mw:Help:Patrolled edits se è possibile aggiungerlo nelle cronologie. --Rotpunkt (msg) 00:05, 3 feb 2016 (CET)

Su phabricator ho trovato: Patrolled status in diffs and page history, Add patrol options in history page e "Mark as patrolled" gadget for Contributions and History. Si può commentare anche in questi. --Rotpunkt (msg) 00:54, 3 feb 2016 (CET)

Leggendo quei messaggi su phabricator ho trovato uno script JavaScript che inserisce i punti esclamativi nella cronologia delle pagine e nei contributi utente, andandoli a prendere dalle ultime modifiche. L'unico problema di questo approccio è che possono essere aggiunti solo per le modifiche non più vecchie di 30 giorni perché questo è quello che forniscono le ultime modifiche. Faccio qualche prova e poi scrivo come usarlo a chi è interessato oppure ne faccio un accessorio se preferite (sempre che vi vada bene questa limitazione dei 30 giorni, potrebbe aver senso in attesa magari di qualcosa di meglio). --Rotpunkt (msg) 10:44, 3 feb 2016 (CET)

Rotpunkt perdona ma io non ci capisco nulla quindi mi fido ciecamente di te, tieni presente che qui l'unica cosa "invasiva" sono i contributi "impropri" che vanno fermati. Ora siamo sempre di meno e il trend non si inverte, abbiamo quindi due obiettivi da raggiungere, consentire a quei pochi che rivedono le voci, anche mesi dopo, di accorgersi di contributi di utenti non verificati onde verificare questi contributi e cercare di evidenziare agli eventuali fraudolenti che il loro contributo sarà prima o poi verificato. Quindi giallo evidenziato e per sempre. E' solo nella crono e non significa "sei un fetentone" significa solo "vogliamo verificare". Altrimenti delle due l'una... o diventiamo Nonciclopedia oppure finiamo, prima o poi, come WikiDE. Quest'ultima ipotesi non è poi così peregrina e non riguarderà solo WikIT... credimi per favore....--Xinstalker (msg) 12:22, 3 feb 2016 (CET)

Ho appena aggiunto come accessorio quello script di He7d3r di cui parlavo, lo trovi in preferenze/accessori nella sezione Patrolling con nome MarkUnpatrolledContribs (che era il nome originario dello script). Aggiunge il punto esclamativo alle cronologie delle voci e ai contributi utente e utilizza un colore di sfondo giallo chiaro (era l'impostazione predefinita, si può personalizzare per-utente se serve). Come avevo scritto sopra c'è la limitazione che i punti esclamativi possono essere aggiunti solo per le modifiche non più vecchie di 30 giorni perché questo è quello che forniscono le ultime modifiche. Ma per iniziare è meglio di niente penso. --Rotpunkt (msg) 12:32, 3 feb 2016 (CET)

Abilitato; la prima impressione è moooooolto positiva (discorso relativamente a parte, se si potesse avere il pulsante per "verificare" una modifica anche senza dover visualizzare per forza la modifica stessa, sarebbe un'ulteriore agevolazione). --Pil56 (msg) 12:52, 3 feb 2016 (CET)

(confl.) Provato, ottimo, grazie! :-) --Retaggio (msg) 12:55, 3 feb 2016 (CET) PS - Pil... eh, no: per "verificare" devi almeno guardare... ;-)

Forse Pil intende quello che avevo scritto io: a volte per valutare la bontà di un edit basta vedere il diff col popup, senza caricare la pagina: in questi casi il pulsante a portata di mano sarebbe utilissimo --Nicolabel 13:11, 3 feb 2016 (CET)

Può essere anche utile verificare più di una modifica alla volta. Ma se mettiamo un tastino comodo mi accontento di cliccare n volte... :D

Proposta rivoluzionaria: vedi Speciale:ElencoPermessiGruppi. Spostare il permesso patrol da autoconvalidati (4 giorni) ad una soglia moooooolto diversa. In altre parole, per segnare un edit come verificato non va bene il sockpuppet del cabalista esecrando. pqd...Ƿƿ 16:38, 3 feb 2016 (CET)

Quoto pure questa (ma non si era detto una proposta alla volta? ;) ) --Nicolabel 17:13, 3 feb 2016 (CET)

(rientro)[@ Xinstalker, Pequod76] attenzione a un qui pro quo in cui mi sembra siate caduti a leggere le prime righe della discussione (non ho letto il resto) e il msg inviatomi da Pequod76: l'utente di cui parlo in Progetto:Religione è un anonimo geolocalizzato nell'alto Piemonte, incarnatosi come Piermark che interviene insistentemente su voci di avventismo, comunismo e anarchia.

Il cabalista di questa UP, noto come TorahPerson10 eccetera, è ancora attivo nel suo ambito ma è separato per attività e geolocalizzazione (ligure questa volta), gli ho scritto ieri qui all'ennesimo blocco.--Shivanarayana (msg) 17:42, 3 feb 2016 (CET)

Sì immaginavo... ma il mio era a mero titolo esemplificativo, cioè del fatto che imperversano mentre noi diminuiamo di numero... questo a prescindere da "chi" sono... --Xinstalker (msg) 19:02, 3 feb 2016 (CET)

Interessante proposta di Xinstalker, ho provato anch'io il "MarkUnpatrolledContribs", che può rivelarsi decisamente utile. Come scrive Nicolabel sopra, poter "verificare" le modifiche dal pop-up velocizzerebbe la verifica. Sarei favorevole inoltre anche all'altra proposta di Pequod. --Dimitrij Kášëv 19:33, 3 feb 2016 (CET)

Ho provato anche io l'accessorio e mi è proprio piaciuto. Certo che se si potesse estendere anche a più di un mese sarebbe ancora più utile...Anche io appoggio la proposta di Pequod.--l'etrusco (msg) 19:40, 3 feb 2016 (CET)

• Essendo un retropatroller, ho seguito con molta attenzione la discussione e sono davvero contento che certi problemi vengano affrontati. Purtroppo l'accessorio dell'ottimo [@ Rotpunkt] a me non funziona, ma di questo discuterò con lui in talk (lascio qui traccia se per caso qualcuno avesse lo stesso problema). Aggiungo che in realtà servirebbe guardare molto più indietro nel tempo: in alcuni casi possiamo essere di fronte a voci vandalizzate da tempo come capitato a Mao Zedong e la sua memorabile scuola Huntelaar, ma mi sorge un dubbio: per quanto tempo una modifica rimane non verificata? Perché non ricordo di aver mai dovuto verificare modifiche più vecchie di x mesi (con x relativamente piccolo) o sbaglio? Ovviamente sono favorevole alla proposta di [@ Pequod76]. Concludo dicendo che avere la possibilità di verifiche multiple sarebbe davvero utile: spesso gli utenti inesperti fanno una catena di edit uno dietro l'altro, per la quale è sufficiente confrontare la versione iniziale direttamente con l'ultima e valutare; mi rendo conto che ci sarebbe comunque una remota possibilità che saltando la catena possa scappare qualche versione da cancellare, ma penso che il beneficio valga il rischio. --Cpaolo79 (msg) 19:47, 3 feb 2016 (CET)

@Cpaolo79 Più vecchie di un mese non penso tu possa averle verificate perché Speciale:UltimeModifiche conserva al massimo un mese. Inoltre guardando più in dettaglio dove l'informazione della verifica della modifica è salvata sul database di MediaWiki, ossia rc_patrolled in recentchanges, mi sembra, se non mi sfugge qualcosa, che più di un mese non si possa ottenere, per come è concepito mw:Help:Patrolled edits. --Rotpunkt (msg) 20:21, 3 feb 2016 (CET)

Be', se lo ritenesse fondamentale it.wiki potrebbe chiedere di alzare RCMaxAge. Magari da 30 giorni si può portare a 60 o 90, non certo anni però. Nemo 20:42, 3 feb 2016 (CET)

@Nemo sì questo certo, quello che volevo evidenziare più che altro è che la funzionalità dei "patrolled edits" mi risulta legata solo alla tabella recentchanges, con una limitazione temporale (per quanto tu voglia aumentarla) e non infinita, più che di anni, come se esistesse un ipotetico rev_patrolled nella tabella revision, come qualcuno avrebbe potuto pensare. --Rotpunkt (msg) 20:54, 3 feb 2016 (CET)

Ho fatto delle prove ma anche l'accessorio ha i suoi problemi, anzi è molto limitato. Il fatto di avere 30 giorni di ultime modifiche disponibili, infatti non vuol dire che l'accessorio le vada a vedere tutte. Ho fatto qualche ricerca sul database è le modifiche nel namespace 0 da verificare degli ultimi 30 giorni mi risultano quasi 200.000. Certamente l'accessorio non le scarica tutte (fa 1 sola richiesta delle ultiime 5000), e con i mezzi a sua disposizione (mw:API:RecentChanges) non le può filtrare neppure per titolo della pagina. Esempio: prendo una pagina a caso, tutte le ultime modifiche di Blackshape sono da verificare ma l'accessorio non lo segnala, anche se sono del 10 gennaio, ma succede anche con voci di poche era fa, esempio Memoria di massa. Forse l'accessorio si può ottimizzare un minimo, filtrando almeno il namespace, ma comunque non ce la può fare con la cronologia delle voci, oltre un giorno. È una funzionalità che va richiesto che venga implementata lato server (in questo modo funzionerebbe), scrivendo su phabricator in quei task già aperti o in uno nuovo, lato client via JavaScript è limitatissima. --Rotpunkt (msg) 22:47, 3 feb 2016 (CET)

Fate qualche prova anche voi ma io sarei per rimuoverlo, l'avevo visto citato su alcune wiki e su phabricator e pensavo tenesse conto di questi fattori. Così come ora da informazioni troppo limitate per essere utili, rischiando di creare falsa sicurezza. --Rotpunkt (msg) 23:09, 3 feb 2016 (CET)

Rendere abbordabile l'informazione sui contiributi non patrollati sospesi è un'idea che sta nell'aria da molto. Guardate mi aveva ripreso giorni fa Fullerene in talk la storia del flag di patrolled. Semplicemente nel sistema wiki ci sono molti modi di iniziare a proporre lo stesso concetto, e non sai mai quando passa. Anche senza oscurare alla DEwiki (che poi su pro e contro del sistema "à la dewiki" si potrebbe dire molto di più, e credo che sono fra i pochi qui che l'ha sperimentato direttamente "scalando" i vari flag può dire che alla fine non è malaccio) si può sempre gestire tale informazione. Ora secondo me ci vorrebbe una discussione molto professionale, com già questa, dati alla mano, per vedere cosa è più facilmente implementabile. Mi ci devo rimettere anche io. Filtrare comunque non è impossibile. Per esempio se prima separi chi ha il potere di autorizzare una versione (che sia far scomparire un "!" o farlo vedere a tutti i non registrati, questi sono alla fine anche dei dettagli rispetto all'obiettivo) da chi ha quello di autorizzare come "buoni" solo i suoi edit, hai che tutta la massa di (retro)patrollatori contribuisce con un clic a sfoltire le pagine da controllare. Rimarrano dei casi vecchi non visti ma almeno nel presente si stabilisce un equilibrio o almeno si può procedere a stabilire come avvicinarsi a un equilibrio che poi è il punto di partenza per iniziare a aggredire il lavoro "storicizzato" (come con gli avvisi: garantita un'omeostasi su quelli nuovi è stato più facile iniziare a togliere quelli vecchi). Non solo: il numero di edit "autorizzati" di chi non è autopatrolled diventa un parametro essenziale per individuare i nuovi autopatrolled. Su alcune wiki è un flag automatico pensate, anche se a me piace l'occhio umani... da noi basterebbe un elenco "non AP con maggiore percentuale di modifiche approvate". Filtrato per un controllo cococo ti permetterebbe di trovare quasi tutti i buoni candidati AP, e quindi restringere ancora di più il blocco di edit da controllare ogni giorno più rapidamente.--Alexmar983 (msg) 01:10, 4 feb 2016 (CET)

Il problema e' serio e non limitato alle voci in wikipedia, ho gia' trovato dei contributi discutibili, se non vandalici, in wikidata, e le modifiche in wikidata, di elementi che sono automaticamente inseriti nelle voci, sono invisibili. Neppure e' fattibile raddoppiare il patrolling in wikipedia e wikidata. --Bramfab Discorriamo 09:47, 4 feb 2016 (CET)

In wikidata hanno sfasciato l'AP. Lasciamo perdere, ci devono sbattere il grugno da soli. Quegli item sono completamente indifesi. La fase di "interazione" con le wiki locali e di import diretto è sottotono e credo pure in ritardo ma prima o poi in qualche forma inizierà davvero se ne renderanno conto eccome...--Alexmar983 (msg) 13:58, 4 feb 2016 (CET)

@Alexmar983 ma cosa dici mai? Queste cose scrivile a Discussioni progetto:Coordinamento/Wikidata, non qui, poi intervengo. --Rotpunkt (msg) 14:22, 4 feb 2016 (CET)

In wikidata hanno sfasciato l'AP, sarebbe a dire? --Bramfab Discorriamo 21:04, 4 feb 2016 (CET)

[@ Bramfab] Forse fa riferimento al fatto che il flag di AP viene assegnato automaticamente dopo il 50° edit in qualunque namespace. --Epìdosis 22:11, 4 feb 2016 (CET)

esatto. Mi è già capitato di correggere cose bislacche, e non mi ci sono nemmeno messo a cercarle, mi chiedo se con altri mi ci fossi messo a immaginare come cercarle, tipo facendo un EGO specifico per certe classi di utenze come con alcuni fdQ qui, cosa si potrebbe trovare. Temo che solo quando la quotidianità di wikidata entrerà di più a livello locale ci si renderà conto che il problema è stato affrontato in modo leggero. Sul fatto che la fase di interazione sia sottotono, ne parleremo anche al progetto competente ma io non vedo tutta questa grande interazione a livello di metadati, vedo soprattutto potenzialità buone E fra l'altro la prudenza nell'uso di wikidata nemmeno mi dispiace, considerando che ci sono dubbi più o meno fondati sul modo con cui sono stati ottenuti. Non sto dicendo che finisce male o va strutturalmente male, sto solo dicendo che deve passare ancora dell'acqua sotto i ponti.--Alexmar983 (msg) 22:37, 4 feb 2016 (CET)

<OT> Vedrei molto bene una discussione più approfondita al progetto competente; per il momento aggiungo solo che gran parte dei problemi macroscopici, spesso causati dall'importazione di dati via bot dai vari progetti (l'importazione che ha causato più danni a mio parere è stata quella del parametro "nazionalità" del nostro {{bio}}, trasformato in "cittadinanza" indiscriminatamente ... noi sappiamo bene che quel parametro spesso e volentieri non coincide colla cittadinanza!), possono essere efficacemente affrontati con tool semiautomatici quali http://tools.wmflabs.org/autolist/index.php, che agendo principalmente in base alle categorie dei progetti locali o a combinazioni di proprietà presenti negli elementi permettono di risolvere problemi quali "cittadinanza:antica Grecia" (inesistente), "cittadinanza:Italia [Repubblica italiana]" per morti prima del 1946 ... Certo molti altri non sono così facili da scovare! </OT> --Epìdosis 22:52, 4 feb 2016 (CET)

Questo effetto di importazione da wiki locale + scarsa visione di controllo flag (cavolo sono i metadati centralizzati, dovrebbero a volte essere l'equivalente wiki del caveau di banca quasi come livello di accesso!) non è ottimale e certo anche io da mesi penso che se ne debba discutere. Mi è scappato, rispondendo di fretta ma non me lo sono "inventato", ecco. scusate tutti, sentitamente.--Alexmar983 (msg) 23:14, 4 feb 2016 (CET)

[@ Xinstalker] e [@ Pequod76] (Pequoduccio, te la sei cercata :p, vedi più sotto) se per i sondaggi (ma anche le pdc ed altro) s'impiegasse solo il tempo impiegato per scrivere favorevole o contrario spunterebbe il tempo per fare opera di proselitismo, cosa che invece non facciamo anche perché sprechiamo il tempo "stroppeandoci 'e mazzate", come è successo di recente :((.. --2.226.12.134 (msg) 08:48, 5 feb 2016 (CET)

2uccio, scusami, se fossimo morti avremmo un sacco di tempo. Io non ho alcuna voglia di fare "proselitismo". Hai ordini di priorità tutti tuoi, apparentemente autoevidenti ma IMVHO terribilmente superficiali. Per te pdc a voto secco, così possiamo fare "proselitismo" e avere più utenza con cui fare shoot'em up nelle pdc... Bello e sanguinolento! :D Tutti i tuoi appelli alla quaglianza sono, si potrebbe dire, momenti rubati all'agrins0. pqd...Ƿƿ 12:33, 5 feb 2016 (CET)

Taglio tecnico

(rientro) Mi accodo alla proposta "rivoluzionaria" di Pequod e ci ragiono su: in effetti, perché mai per avere "automaticamente verificate" le proprie modifiche bisogna diventare AV (che non è automatico, si ottiene con il placet comunitario, ricordo), mentre invece chiunque, automaticamente dopo 4 giorni, può verificare le modifiche degli altri? Non sarebbe più sensato che i diritti di "patrol" e "autopatrol" vengano dati insieme, contemporaneamente, come per avviene gli AV, dopo che l'utente ha mostrato una certa affidabilità? Io vedrei insomma una modifica del livello AV in una sorta "V-AV" (scusate il bisticcio, è per capirsi) con le stesse procedure di assegnazione e revoca attuali degli AV. Troppo dirompente come proposta? --Retaggio (msg) 09:37, 4 feb 2016 (CET)

Non credo. Inutile aggiungere altra burocrazia senza avere numeri che dimostrino un abuso della funzionalità. Il problema principale che abbiamo è semmai che la stragrande maggioranza dei contributi controllati non viene verificato, perché 1) non si dà l'autoverificato a gente i cui contributi nessuno considera necessario verificare; 2) c'è chi fa "annulla" invece di "rollback" e si dimentica di segnare anche come verificato; 3) non si dà il rollback a tutti coloro che (ce) ne beneficerebbero. Nemo 11:20, 4 feb 2016 (CET)

(confl.) dirompente? rivoluzionario? Bho, son che vengono studiate da molto tempo, semplicemente è adesso che si inizia a inquadrarne collettivamente il valore. Vediamo quanto ci si impiega a elaborare qualcosa di concreto, rimarrei stupito se si facesse adesso, quello sarebbe eccome rivoluzionario. in ogni caso non sarebbe utile che "patrol" e "autopatrol" siano dati assieme e la cosa, lo ribadisco usando aggettivi che impiego sempre, è "semplicistica ma non semplice". Saper gestire i propri contributi non ha relazione sretettissima con il sapere valutare i contributi altrui pregressi. In teoria l'autopatrolled avrebbe a che fare con il fatto che i propri contributi non sono annullati, per questo è in molte wiki (semi)automatico, e vale meno che da noi. Ma giustamente non c'è nulla di male nel valutarlo collettivamente basta porre davvero l'accento in modo riproducibile su aspetti più profondi come il copyviol (quello che adesso si fa "a chiazze", da cui minimo due pulizie di copyviol all'anno di utenti di lungo corso, ma contento chi se li becca). Ora anche controllando meglio i contributi singoli l'AV/AP non dà indice di attenzione al lavoro altrui. Come dimostra il caso di copyviol esso non dà gradissima garanzia nemmeno sui contributi del singolo a cui vengono dati. Un utente che fa correzioni ortografiche minori a randa è un perfetto AV/AP dopo anni ma non patrolla di fondo nulla. Esistono lavorosporchisti solidi nelle loro mansioni che non hanno competenze specifiche di copyviol, vi immaginate che succede se inserendo avvisi autorizzassero come verificate versioni copia-incollate? Va bene che ci sono decine di modi di ripescare sacche di porblemi critici o pregressi, ma se si studiano le dinamiche utenze il patrolling delle modifiche altrui sarebbe qualcosa che sta sopra l'AV e sotto l'admin (a cui è inevitabilmente concesso) come collocazine naturale.

Su itiwki non si ha la pazienza analitica di gestire tutto e si corre a appicicare le cose insieme "perché è semplice", strategia alquanto rischiosa. Soprattutto perché l'AV non è un flag "stabile". Ha una natura variabile che deriva dal negare il valore "strutturale" nel lavoro wiki. Non esistono vincoli qualitativi o quantitativi veri e proprio, è "la fiducia", perché se si ponessero "se ne tradisce lo spirito" o qualcosa del genere. Quindi funziona abbastanza bene a livello operativo ma ha delle grosse pecche ch lo rendono un po' instabile. Vi ricordo che già adesso per non aver fissato dei paletti minimi di edit a cui concedere eccezioni con il contaggocce gli AV si stanno estendendo a fasce di utenze con poche migliaia di edit, che sono abbastanza a rischio. Si arriva all'assurdo che utenze che hanno molti edit ma pochi negli ultimi mesi non vien dato "che ci vuole poco a verificare edit" (magari chi lo dice poi vota sysop chi fa poche azioni al mese perché "poco è meglio di zero", ma apparentemente questo non vale il tempo di non verificare utenze di lunghissimo corso) e si dà a chi invece ha accumulato migliaia di edit in pochissimo tempo e tutti dello stesso tipo. Peggio ancora hi fa edit di pochi tipi sbaglia di meno quindi è soggetto a averlo anche se potrebbe iniziare a fare male altro. Chi invece fa cose diverse ha sempre errori più recenti per ovvia statistica che vengono singolarmente fatti pesare moltissimo. Quindi l'AV non è strutturalmente stabile. Già è un miracolo che funzioni "operativamente" nl lavoro di insieme, figuriamoci se ci si ci appiccica la funzionalità di patrollare gli altri edit e per giunta retroattiva. --Alexmar983 (msg) 14:25, 4 feb 2016 (CET)

Riprendo quanto diceva sopra Nicolabel: usando il popup, non è possibile segnare la pagina come verificata se non si apre la pagina, quindi, per quel che mi riguarda, quando faccio patrolling "in velocità" in ultime modifiche lascio intatti i punti esclamativi rossi per tutte le modifiche che controllo ma non annullo. Di conseguenza, un qualsiasi altro patroller che lavora in quel momento, facilmente andrà a ricontrollare quello che ho già controllato io, e così via... [@ Rotpunkt], si può far qualcosa? --Euphydryas (msg) 14:20, 4 feb 2016 (CET)

@Euphydryas Posso vedere, ne discuterei però non in una pagina del bar, ma in un posto più adatto come Discussioni Wikipedia:RC patrolling. Quello che mi preme ora è rimuovere l'accessorio MarkUnpatrolledContribs creato ieri. Come ho scritto sopra (diff) non va bene assolutamente, oltre qualche ora non funziona già più. Aspetto un paio d'ore per eventuali altri pareri e lo rimuovo. --Rotpunkt (msg) 14:33, 4 feb 2016 (CET)

[@ Rotpunkt] per quanto mi riguarda e per quanto non perfetto, lo trovo meglio che nulla allo stato; non ho capito quali siano le problematiche a lasciarlo, anche se solo provvisoriamente. --Pil56 (msg) 14:43, 4 feb 2016 (CET)

@Pil56 La problematica è semplicemente che non funziona: lo scopo della discussione era trovare un modo per segnalare nella cronologia delle voci le modifiche ancora da verificare. L'accessorio MarkUnpatrolledContribs è in grado di farlo solo per le modifiche delle ultime ore, neppure di ieri, quindi come può servire? Chi lo usa vede la cronologia senza punti esclamativi e penserà che siano tutte verificate, invece è l'esatto contrario. Quindi il suo utilizzo è del tutto fuorviante. --Rotpunkt (msg) 14:48, 4 feb 2016 (CET)

Scusate io non ho capito molto, ma mi sembra, magari a torto, che ci stiamo allontanando dal tema che ho proposto e che ripropongo, mi scuso se ho frainteso.

1. Siamo meno collaboratori. Drammaticamente di meno. Nel settore che sto curando da qualche mese, la cultura religiosa orientale, eravamo qualche anno fa quattro/cinque. Ora sono io solo e da mesi... I temi sono "caldi", a rischio POV e vandalismi sottili, intendo non il "caccapuzza" che quello si vede e si toglie subito, ma cambiare un incipit ben fatto con uno assolutamente inadeguato facendolo fontare da una fonte ancora più inadeguata.
2. Questo sulla WikiDE non è possibile quindi le voci ben fatte rimangono tali. Qui è possibilissimo e la degenerazione è vicina, non si può chiedere infatti ad un admin o un patroller senza competenze specifiche di farsi carico della validità dei contenuto quando non li conoscono e non conoscono le fonti.
3. Lo si può chiedere all'utente diciamo "esperto" ma se questo è solo, il mazzo diviene terrificante. Nella WikiDe se tutti gli utenti "orientalisti" abbandonano il progetto per fatti personali le loro voci non subiranno alcuna alterazione di sorta perché per accettare le nuove modifiche al testo queste devono essere accolte da utenti di cui la comunità ha fiducia. Una nuova modifica può aspettare mesi se non anni.
4. L'ultimo collaboratore decente di WikIT "orientale" DonatoD è molto saltuario, anzi... quindi se io mi faccio monaco buddhista... le voci "orientalistiche" di WikIT sono belle che fritte... Attendere utenti competenti è ormai un miraggio, mentre i "cabbalisti fondamentalisti" o i "seguaci dei santoni" sono sempre all'opera per ragioni facilmente intuibili.
5. Dal che io spero, vivamente spero, che WikIT si decida o ad adottare il sistema WikiDE, che a me personalmente non piace, o, almeno, a fare in modo che le modifiche che in WikiDE sono sospese qui appaiano nella crono come evidenziate da "controllare". Questo per due ragioni, semplifica il lavoro di chi c'è o che torna e mette sull'avviso, per bene e visivamente, al "cabbalista fondamentalista" di turno che la sua modifica potrà essere controllata anche se dopo un po' di tempo.

Grazie per la comprensione. Ci sono utenti penso a DonatoD, Tonii, Yuyu e me che hanno passato ore sui libri per scrivere qualcosa qui sapendo il valore l'uno dell'altro e conoscendo tutti insieme le fonti. E' un peccato che possa andare tutto in malora in poco tempo... cosa che in WikiDE non accadrebbe e non accadrà mai. Vi prego di pensarci seriamente su e non riguarda solamente le voci di "orientalismo"... ovviamente. --Xinstalker (msg) 14:51, 4 feb 2016 (CET)

Xinstalker appurato che vedi bene "quelle da controllare" la scelta poi sarebbe di chiarire meglio "chi ha l'autorità di controllarle"? perché se sono in evidenza quelle da controllare e anche l'utente qua da 4 gg può controllarle e verificarle capisci che la cosa non funzionerebbe al massimo. Funzionicchierebbe in molti casi, ma non al massimo potenziale. Siamo pieni di Autoverificati (o autopattrolled che dir si voglia), non solo di utenze generiche, che di orientalistica o fisica quantistica non sanno nulla, ma magari fanno controlli di altro tipo e rischierebbero correggendo un'ortografia o una arg in un template o inserendo un portale a seconda di come è impostato il loro flag e la loro interfaccia di lavoro di validare una versione per esempio. Quindi deve essere chiaro che c'è un tasto "verifica" esplicito (o conctto simile) e che solo alcuni di certe classi lo vedano e possano cliccarci sopra. Poi certo ci saranno tutte le sottigliezze del caso (tipo se il rollbacker o l'admin garantisce in automatico la validità dell'ultima versione che ha reimpostato p.e. oppure come filtrare liste di back log da scrutare etc) ma di fondo si vuole capire cosa si verifica, come si verifica e chi lo verifica. Nel bene o nel male le cose sono interrelazionate, la scelta non può essere più di tanto spezzetata in più passaggi a meno che di aver chiaro dove si va a parare sul medio periodo.--Alexmar983 (msg) 15:12, 4 feb 2016 (CET)

Alexmar non so dire di più e non so nemmeno spiegarmi meglio. Se il problema viene percepito/condiviso e si trova una soluzione tanto meglio, se invece non viene percepito/condiviso o se non c'è una soluzione tanto peggio. Di più non so, ho detto la mia e credo che non ci tornerò su perché la ripeterei allo stesso modo. Osservo solo che WikiDE non ha di questi problemi e che noi potremmo adottare qualcosa che possa quantomeno limitarli. Ma magari ciò che io vedo come problemi in realtà non sono nemmeno percepiti come problemi, insomma... pensiamoci anzi pensateci perché i miei neuroni sono già al massimo delle sinapsi... --Xinstalker (msg) 15:25, 4 feb 2016 (CET)

il sistema dewiki è strutturato oramai in modo profondamente diverso dal nostro su almno due punti chiave, è improbabile pr questo importarne solo un aspetto, ti provo a spiegare là se vuoi come funziona, ti ho lasciato un messaggio--Alexmar983 (msg) 15:29, 4 feb 2016 (CET)

[@ Rotpunkt] Dalla mia ti posso dire che ieri mi evidenziava le modifiche fino al 10 gennaio, poi stamattina era arrivato a evidenziare quelle fino al 4 gennaio, in questo momento invece sembra non essere funzionante. --Dimitrij Kášëv 21:55, 4 feb 2016 (CET)

@Dimitrij Kasev Ciao, l'ho rimosso. Ho rifatto gli stessi test di ieri pure nel primo pomeriggio: per tutte le voci modificate stamattina da verificare (evidenziate dai punti esclamativi negli osservati speciali), se ne aprivo la cronologia, la stessa modifica non veniva evidenziata dall'accessorio. Funzionava solo per le modifiche delle ultime 2-3 ore. --Rotpunkt (msg) 22:10, 4 feb 2016 (CET)

OT del Famolo Day

Abbiamo aperto una discussione da 50mila bytes e poi ci lamentiamo che non abbiamo tempo per verificare le modifiche :)): questo non mi sembra essere costruttivi ;) quindi concludiamo passando a valutare la proposta originale :), okay ;)? Chi è favorevole o contrario ad evidenziare maggiormente le modifiche nelle voci? --2.226.12.134 (msg) 08:55, 5 feb 2016 (CET)

Non sei registrato, quindi devo per forza ascriverti a una genia, quella del famolo day. Apri una sezione solo per dire allora? L'importante è fare, compulsivamente. Votiamo! Ma guarda che si è già favorevoli alla proposta, ci sono problemi tecnici, delle questioni teoriche, l'accessorio è stato provato e ritirato... Votiamo! Mister Tamburino va avanti sul suo glorioso sentiero d'oro. Implacabile. La discussione da 50 mila bytes è stata aperta tre giorni fa. E non aggiungo altro. Anzi, sì, una preghiera: ti prego, astieniti dal fare il direttore del traffico delle discussioni: è già così difficile dire cose intelligenti! pqd...Ƿƿ 12:26, 5 feb 2016 (CET)

Cosa significa verificare

Chiariamoci su una cosa. Verificare significa una di queste cose:

• La modifica relativa alla voce di fisica quantistica è complessa, ma per fortuna io sono un professore ad Harvard e ho visto che è tutto a posto.
• La modifica relativa alla voce di fisica quantistica è complessa, io non sono particolarmente ferrato sulla materia, ma il pattern dell'utente è abbastanza solido e positivo: potrei non cliccare, forse segnalerò al prg... dipende da quanta puzza sento.
• L'edit non è un vandalismo "a prima vista", ma non è neppure troppo articolato per le mie capacità.

Detto altrimenti, in linea di massima la verifica di un edit significa accertarsi che non è un vandalismo. Siccome il nostro cabalista esecrando è un vandalo, la nozione pura e dura di "verifica" si fa complessa. Secondo me ci sono tre fasce: non è certamente un vandalismo; mi puzza; è decisamente un vandalismo (per cui, ad es., risolvo e segno come verificato, cioè come "risolto".

Ovviamente la fascia di mezzo è la più delicata. Tendenzialmente dovremmo verificare nei campi a noi familiari, e invece segnalare ai prg lì dove non ci sentiamo tanto sicuri.

Certo, se invece di ******** la fondazione si occupasse del progetto fattivamente, :D :D , il sistema indichirebbe l'utente che ha verificato la voce nel diff stesso (o nella versione oldid) - invece adesso l'informazione è in un inutile elenco a parte - e anzi permetterebbe che una modifica potesse essere verificata più volte, quindi in sostanza "votata" (e così anche un edit verificato da Tizio potrebbe anche essere "deverificato" da Caio).

Cmq, tutto questo per dire che se al prg:filosofia iniziano a mancare le forze, se al prg:wikipedia iniziano a mancare le forze, non c'è sistema che tenga, il castello crollerà e non resteranno che punti di ripristino (il che non è certamente poco!). pqd...Ƿƿ 01:55, 5 feb 2016 (CET)

Ottima la schematizzazione proposta da Pequod, che rende la risposta "semplice" da ipotizzare (non da implementare però...)

Dunque, fatto salvo che nel primo e terzo caso tutto fila liscio, bisogna capire come comportarsi nel secondo caso. La risposta è di fatto già stata data: rivolgersi, segnalando il caso, a qualche utente o a qualche progetto "competente" in materia. Tuttavia, perché possa avvenire ciò devono verificarsi necessariamente alcune condizioni:

1. La modifica deve apparire come "non verificata" per tutto il tempo necessario fino a che non viene effettivamente verificata; quindi non per 30 o 60 giorni, ma per un tempo indefinito. E qua ci scontriamo con il problema "tecnico" mostrato da Rotpunkt.
2. I verificatori devono essere utenti considerati "affidabili" dalla comunità. Per capirci: amministratori, rollbacker, al massimo autoverificati. Attenzione: non ho detto "competenti" ma "affidabili": possono anche non essere esperti di fisica quantistica, ma se sono "affidabili" possiamo essere certi che segnaleranno il problema al progetto (o utente) competente. Al momento, in effetti, siamo lontanissimi da ciò: scusate se mi ripeto, ma è un vero controsenso che per avere le proprie modifiche "autoverificate" bisogna diventare AV (con il placet comunitario quindi), mentre invece chiunque, automaticamente dopo 4 giorni, può verificare le modifiche degli altri.
3. Ultimo, chiunque vede una modifica che considera accettabile deve necessariamente ricordarsi di segnarla come verificata (cosa che al momento non avviene sempre, ammettiamolo), per non appesantire inutilmente la lista dei casi in attesa di verifica.

Non stiamo dicendo insomma roba da poco: almeno un grosso problema tecnico e un pesante cambio di mentalità. E' possibile? --Retaggio (msg) 18:24, 5 feb 2016 (CET)

Posso dire come mi veniva a me prima di leggere cosa c'è sopra? Un po' perché esco e un po' perché mi sa che siamo in fase di brainstorming puro e le idee vengono bene anche pure visto che cosa c'è da costruire la comunità ancora non lo immagina bene.

Esistono due classi di verifica: verifica dell'edit e verifica della voce prodotta dall'accumulo degli edit. Questa non è un'ipotesi di lavoro, è più un mio schema mentale che uso da tempo quando analizzo i sistemi AV di altre piattaforme.

Si potrebbe partire dal pressuposto che "voce con almeno un edit non verificata"="voce globalmente non verificata". Non importa che sia solo quello recente, è questo il punto. Almeno un edit non verificato (perché non approvato o non fatto da AV/AP), da quando si considerano, significa che non è verificata nl complesso la voce.

C'è differenza fra verificare un edit altrui e verificare una voce con più edit non verificati tutti assieme. Nel primo caso si giudica un passaggio analiticamente. Il secondo caso prevede di prendere, rileggere e ristabilire un certo punto di partenza.

Il primo tipo di verifica sull'edit è intrisecamente funzionale, ed in teoria è conservativo. Se non ti fidi, non dai l'ok alla verifica e "passi" a un altro il compito. Ovviamente non tutti possono mettere "patrolata" alla modifica, solo un utente di lungo corso e flag "solidi" lo potrerbbe fare. L'AV/AP verifica i suoi contributi in automatico quindi non intasa qusto elenco, il patrollatore di singolo edit valuta gli edit singoli dei non AP. Li valuta annullandoli o confermandoli, ma li valuta.

Dopo tot giorni una voce con edit non verificati/patrollati è essa stessa una voce potenzialmente da patrollare o verificare. Si può anche togliere di torno in blocco il problema del singolo edit, soprattutto se è più di uno in ballo, e trasferire a una nuova dimensione di problema, se questo intasa qualcosa. Un elenco di "voci globalmente da verificare"

Sembra un elenco potenzialmente lungo che si andrebbe a formare ma credo non sia così perché:

• gli edit nuovi sono di meno e diluiti su più voci, l'AP può dl resto essere reso analiticamente ancora più efficiente;
• il "punto di partenza" non deve essere "perfetto". Intendo dire che si può "stabilire" che la presenza di template F,W, chiarire etc vale come verifica, perché segnala chiaramente un problema. Abbiamo vissuto per anni con qusti template, mica questo sistema induce la perfezione eh... In altri termini se tu utente esperto (=flag) hai letto, hai segnato a matita rossa cosa non va bene, quella voce è marchiata che sia nell'elenco delle non verificate globalmente o meno. Puoi anche toglierla dall'elenco delle voci non verificate globalmente, passa al retropatrolling profondo comunque (FdQ, lavoro sporco di progetto). Anzi un elenco di voci "non verificate" è comunque più difficile da impostare per argomento snza falsi positivi e negativi, ma anche facendolo (mano a mano che si perfeziona il lavoro) alla fine che sia un elenco di voci con F,W, P o un elenco di voci da verificare senza uno specifico template sempre lenchi di lavoro sporco per l'home page di progetto rimangono.

Quello che rimane da stabilire è come e chi conferisce la verifica globale alla voce. Come ho detto questa è una funzionalità diversa e qui sta l'ingarbugliamento di fondo. In un'epoca di SUL è ovvio che non si può tenere i piedi in più staffe, se si scegli un flag di "patroller" si deve decidere a cosa questo si applichi. Se all'edit o alla versione.

Si potrbbe stabilire che l'AV/AP può patrollare gli edit dei non-AP ma che solo un "patroller" può sancire come verificata la versione data di una voce.

Questa è una delle ipoesi più semplici che mi viene. Il punto è che io prefrisco studiare bene le altre wiki per favorire strutture non troppo dissimili se non cambia troppo, che è più chiaro parlarsi. Non ho ancora finito di capire le altre come impostino la cosa, sono decine di versioni. Quindi non sono mai stato sicuro di proporre questa idea.

Buona discussione...--Alexmar983 (msg) 19:30, 5 feb 2016 (CET)

[@ Alexmar983] Così facendo si rischia di andare verso un avvitamento burocratico. Tra le prime "cose da fare", ci sarebbe da rimuovere la possibilità di poter verificare le modifiche di altri utenti a soli 4 giorni dalla registrazione. Per il momento sono incerto sulla necessità di generare un nuovo flag "patroller" (ho capito male io?)

[@ Retaggio] Per il punto 2: sono d'accordo. Per il punto 3: sicuramente ottenere questo netto cambio di mentalità, almeno nel breve periodo (da qui a 3 mesi) sarà un'impresa davvero complessa per diversi fattori. --Dimitrij Kášëv 00:08, 6 feb 2016 (CET)

"avvitamenti burocratici", quant volte l'ho sentito...

Annullare il diritto di verifica a chi sta qua da quattro giorni non è il punto cruciale, è solo un gesto dovuto affrontato con discreto ritardo. Non lo si è affrontato prima temo non perché non sia semplice arrivaci per coerenza interna (è ovvio che se ci vuole tempo a valutare le mie modifiche è asurdo che io valuti prima quelle degli altri) ma perché apre uno scenario in cui si intravede complessità, quella stessa complessità che anni di "è burocratico" non solo non hanno eliminato ma non hanno nemmeno preparato al meglio a gestire.

Non c'entra molto il flag in più o meno, quello è l'ultimo punto del ragionamento, e sono cose che negli anni evolveranno sempre e comunque, solo che è il più tangibile, è quindi è quello che si nota. Ebbene sì, potrebbe essere necessario creare un nuovo flag (intenso funzionalità) che temo si correrà a appiciare a uno esistente (inteso come classe di utenze)... Se lo dai agli AV/AP di fatto stai facendo metà di quello che ho scritto, in quella possibile ipotesi (che è uno delle tante), ti senti forse avvitato "a metà"?

Anche ragionando sul singolo edit un "patroller" sopra o allo stesso livello dell'AV è una cosa che c'è da molte parti. A volte si danno nomi diversi, per esempio "autopatrolling" è "patrolling passivo e "patrolling" è "patrolling attivo". Sono due cose diverse alla fine, una cosa è saper fare il tuo, un'altra valutare gli altri. Esistono casi in cui ognuno può valutare gli altri, più orizzontali, e casi più verticistici dove non è possibile. Si intuisce che è uno spazio a più gradi di libertà quello in cui fai questa scelta e difficilmente potrà mai essere "semplice" o "poco burocratico" (una correzione qui, un codicillo là) per adattarsi bene a questo tipo di problema. Si può appiattire su una semplificazione, come molte wiki fanno,ma non è detto che convenga e che alla fine altri aspetti del problema non ritornino.

Gli Autoconvalidati non verificano questo gran numero di pagine: togliendo loro la verifica ci sarà qualche caso critico indotto da malizia più facile da stanare, forse compensato da qualche sporadica modifica verificata correttamente che viene persa. Il "gesto dovuto" di togliere loro il flag non ha effetto pratico concreto se vine lasciato agli altri.

Ora, anche limitandosi alle sole verifiche dei singoli edit e non alla voce nella sua interezza, che poi è il "modello base", non si può non intuire che spostare il flag di verifica attiva o patrolling che dir si voglia a una classe o l'altra avrà conseguenze e possibili re-azioni nel tempo. Darlo agli AP/AV stimolerà ancora di più a valutare meglio a chi lo stai dando, altro che "fiducia"... tu daresti la possibilità di valutare edit altrui a chi hai il minimo dubbio abbia una potenziale debolezze sui propri? In sintesi lo chiami "autoverificato" ma in realtà stai dando un "verificato", un "patroller", e l'auto è implicito. Ma una volta diventato tale e dunque selettivo avrai meno nuovi AP/AV, quindi più modifiche non verificate, quindi ti verrà l'esigenza di dire che forse tenersi l'AV , la verifica "passivo" a parte non era una cattiva idea, perché mi toglie almeno più lavoro da fare. Specularmente se lo dai a altre classi di utenze "superiori" (rollbacker, admin) allora l'AV , la verifica passiva, sarà concessa più tranquillamente ma non compenserà il minor numero di chi può patrollare, fatto che intaserà anche in quel caso il numero di edit da verificare. Probabilmente finirà alla lunga che qualcuno ti dirà che gli torna scomodo di prendersi un flag che c'entra anche nulla con altre mansioni per fare solo la verifica sulle voci della quale comunque c'è bisogno (già successo, con tutti i flag progressivamente scomposti nel corso degli anni nonostante pare all'inizio fossero tutti "avvitamenti burocratici").

Ma l'aspetto che sembra chiave è che, al di là dell'effetto "coperta corta" che deriva dal non distinguere le due funzioni associandole a una classe o l'altra delle esistenti, comunque alla fine rimarranno sempre voci con edit non verificati. Il doppio o la metà non cambia molto, essi sono un'ulteriore classe di lavoro. Non esistono per complicazione burocratica di volerli vedere, esistono perché nssun sistema con un centinaio di volontari attivi davvero e decine di migliaia di modifiche al giorno su milioni di voce potrebbe evitarle. Questo aspetto quando provavo a schematizzarlo mi sembrava il "secondo grado di libertà" del lavoro di verifica o patrolling che dir si voglia.

Ovviamente io ho scomposto in questi due assi (singolo edit, voce nell'interezza) perché mi sembravano i più semplici ma abbracciavano abbastanza bene le verifiche da fare.

Fra l'altro è sul problema della verifica della voce nella sua interezza che emergono problemi quali appunto se una voce con un avviso chiaro che indichi una mancanza può essere ritenuta verificata o meno. Non è un problema da poco perché influenza proprio la priorità del lavoro tematico dei progetti che si vorrebbe predominante qualitativamente sulla bassa manovalanza del controllo a catena di montaggio dei numerosi edit.

Scusate l'intervento lungo...--Alexmar983 (msg) 02:27, 6 feb 2016 (CET)

Ricapitolando, da questa discussione abbiamo appreso che:

1. Un edit è verificato se a) è effettuato da un autoverificato (e superiori); b) è verificato da un autoconfermato (e superiori) c) sono passati 30 giorni.
2. Non è possibile capire dalla cronologia quali edit siano verificati e quali no, se non andando di diff in diff.
3. Non è possibile fare una verifica a) massiva (sei edit consecutivi verificati in un sol colpo) o b) automatica (se faccio rollback ad una modifica di sicuro ho verificato).

Per il punto 1b la proposta è: Le verifiche possono essere effettuate solo dagli autoverificati (e superiori). Per il punto 1c non sembra esserci soluzione tecnica: altre wiki hanno adottato soluzioni differenti che la comunità italofona non condivide. Per i punti 2, 3a e 3b al momento non sembra esserci soluzione tecnica adeguata. Riguardo al riassunto fatto da [@ Pequod76], io effettuo la verifica solo se ricado nei casi 1) e 3), intendendo con il 3) che l'edit corregge aspetti che sono facili da comprendere (es.: un errore grammaticale). Aggiungo un mio dubbio: [@ Rotpunkt] da un edit che risulta verificato, come si fa a capire chi ha fatto la verifica? [@ Alexmar983] Questo potrebbe essere molto utile per scovare sock e meat puppet. --Cpaolo79 (msg) 12:33, 6 feb 2016 (CET)

[@ Cpaolo79] Guarda questa pagina ad esempio: https://it.wiki.x.io/w/index.php?title=Speciale%3ARegistri&type=patrol&user=&page=Hugo+Largo&year=&month=-1&tagfilter=&hide_thanks_log=1&hide_patrol_log=1&hide_tag_log=1. Come vedi, sarebbe molto più snello e intelligente se questa informazione fosse disponibile già nel diff e anche nella versione stessa della pagina ("questa versione è stata verificata o autoverificata da utente:Caio in data X"). In ogni caso, allo stato la trovi dalla crono, visualizzando i log della pagina e cercando "modifiche verificate". pqd...Ƿƿ 12:41, 6 feb 2016 (CET)

[@ Alexmar983] Sinceramente non ho capito a cosa serva la verifica "integrale" della voce ("voce verificata globalmente"). Qual è esattamente l'apporto qualitativo di questo tipo di operazione? pqd...Ƿƿ 12:44, 6 feb 2016 (CET)

[@ Pequod76] Ma l'aspetto che sembra chiave è che, al di là dell'effetto "coperta corta" che deriva dal non distinguere le due funzioni associandole a una classe o l'altra delle esistenti, comunque alla fine rimarranno sempre voci con edit non verificati. Il doppio o la metà non cambia molto, essi sono un'ulteriore classe di lavoro. Non esistono per complicazione burocratica di volerli vedere, esistono perché nssun sistema con un centinaio di volontari attivi davvero e decine di migliaia di modifiche al giorno su milioni di voce potrebbe evitarle. Puoi fare tutto il sistema efficiente che ti pare dat le condizioni operative di partenza sui singoli edit, ma dopo un po' avrai un backlog di voci con ancora edit non verificati all'interno. Che ci vuoi fare? Buttarli via dopo un tot tempo e amen? Tutta la parte sulla competenza tematica ri-emerge lì. Perché ogni sistema semplice di validazioni di edit non può dare al singolo edit un grande valore di competenza tematica perché come ho detto è abbastanza analitico come passaggio. Solo dopo un po' al netto di edit sicuramente corretti (virgole, orotgrafia, portali, annullamenti di parolacce, inserimenti di immagini) ci si può sedere con calma e valutare se c'è qualcosa davvero nella voce che non va. Al di là di quanto un edit tematico o un gruppo di edit tematici ravvicinati ci possano apparire corretti nessuno si assumerebbe mai la responsabilità di affrontarli mentre si accavallano o mentre lui stesso, il verificatore, ha fretta. Ogni singolo dubbio su una data o un nome o il POV di una fonte inficia il lavoro. L'incrocio di condizioni ottimali, anche quando c'è "competenza", si verifica anche qualche giorno dopo l'avvenuta modifica. Cioè il back log, l'arretrato. A quel punto il confine fra edit singolo e revisione voce si fa sfumato. Se un singolo utente si trova a guardare una voce di cui è competente non ha più senso che si limiti al solo edit chirurgico magari in quel momento già mischiato a altri. Avrà più senso che riguardi la voce nella sua interezza (perché difficilmente parliamo di una voce in vetrina qua, e cose da fare ci sono comunque).

[@ Cpaolo79] l'analisi sui log utenti (quelli visti da Pequod76) collegate a quanto dici sono state studiate. c'è roba interessante ma si va sull'analisi utenze. Su itWiki l'analisi utenze è assai più embrionale dell'analisi voci. Finché non si gestisce quest'ultima bene e si "salta di livello", difficilmente si passa davvero ad affrontare bene la prima. Posso garantirti comunque che per trovare sock e soci una semplice analisi su frequenza di contributi su stesse voci in ns0 (o ns1) è al momento più che sufficiente. Interessante anche l'analisi di frequenza in talk molto specifiche tipo vagli, valutazioni vetrina e pdC (una talk progetto è troppo dispersiva). Anche quello lo farei prima di buttarsi a guardare le verifiche approvate. Intendo dire che puoi fare anche un controllo incrociato su valutazioni e ringraziamenti ma temo che allo stato aggiungerebbe davvero poco a risultati molto più abbordabili e comprensibili dalla massa dei wikipediani. Sarebbe come iniziare a pulire casa col panno in microfibra antiallargenico prima di aver fatto passare l'aspirapolvere. Come rapporto costi/benefici una semplice analisi contributi ns0/ns1 su stesse voci è molto più abbordabile. --Alexmar983 (msg) 13:45, 6 feb 2016 (CET)

Alex, scusami ma continua a sfuggirmi il punto. Quando l'utente Caio clicca il futuribile "verifica la voce nel suo complesso", cosa ci sta dicendo? Non ha più senso un messaggio umano? Il monitoraggio? Gli avvisi? Gli strumenti che già abbiamo? In ogni caso, facciamo già quello che abbiamo concordato? Gli Autoconvalidati non devono poter verificare. La tua proposta andrebbe fatta a parte, così si capisce anche meglio. pqd...Ƿƿ 19:27, 6 feb 2016 (CET)

futuribile? Su alcune wiki dove la versione è nascosta quando autorizzi l'ultima versione tu stai autorizzando la voce nel complesso, eh... da anni. Si mischiano pure da loro i due livelli della questione per "semplcità" ma i due livelli, sebbene sfumati, sono là: verifica singolo edit o verifica versione voce. O che sia un edit fatto su una voce che prima non è stata mai verificata edit per edit (dal momento zero in cui il sistema è iniziato) o che sia un insieme di edit che si sono accumulati senza essere verificati per mancanza di manodopera soprattutto competente (scenario probabile, altrimenti manco stavamo qua a prendere atto del problema con un ritardo remendo) tu stai surrettiziamente, tramite l'ultimo edit che fai o verifichi, verificando una voce nel complesso. Certo li schematizzo come due gradi di liberta diversi, singolo edit e voce prodotta da edit, altro non puoi fare per impostare una soluzione, ma sono un continuum. La "semplificazione" ci spinge a pensare che uno si trascura e ci si concentra sul primo, giusto? Liberi di sperarlo che tale semplificazione basti, ma quale sia il sistema che si farà pensando ai solo singoli edit e ingorando la voce nel complesso dopo circa 1-2 mesi ti troverai comunque migliaia di voci con una discreta stratificazione di edit inevasi da prendere in consegna. Quindi il futuro ti bussa alla porta. A quel punto che fai? Come Xinstalker si lamenta che la sua versione è stata autorizzata in ritardo mostruoso su dewiki, ci saranno ritardi mostruosi per decidere cosa fare delle verifiche comunque inevase. Se le lasci andare perdi un'informazione utile. Se fai finta che la verifica dell'ultima versione indipendentemente dalle precedenti basti per definire verificata tutta la voce ne togli di torno una gran massa, ma è solo una soluzione surrettizia, e ha conseguenze. Certo è semplice dire "ultima modifica verificata=voce verificata" ma non funziona alla lunga. Infatti le wiki che hanno (probabilmente pensavano fosse complicato o futuribile accettare che c'erano due ordini di grandezza del lavoro in gioco) surrettiziamente scaricato a chi verifica l'ultimo dit la verifica la voce tutta (perché magari la rende visibile) hanno utenze molto responsabilizzate che verificano meno edit anche sciocchi di quelli che potrebbero. Del resto io utente potrei verificare la correzione di virgola dell'ultimo edit, ma se nell'edit prima qualcuno ha inserito una data di morte, verifico anche quella. E allora che faccio? Non verifico nesuna delle due. Capita da anni. E capiterà anche a noi perché tanto siamo rissosi. Ma ce lo vedete il wikipediano che vede il suo "nemico" che verifica un edit giusto e automaticamente quello prima che è sbagliato ma molto raffinato. Si piomberà in talk a dirne di tutti i colori "ah io so le cose, tu correggi le virgole e fai danni", e giù asminuire... Mangeranno tutti la foglia e patrolleranno tutti molto meno di quanto potrebbero.

Ora anche definendo patroller relativamente al singolo edit, il che va benissimo, deve essere chiaro che è una voce a cui un patroller ha verificato l'ultimo edit non è una voce patrollata nel complesso. In alcuni casi lo è anche, se tutti gli edit erano stati patrollati prima, e se la voce era buona quando il sistema di patrolling è iniziato, in molti altri no. Puoi chiamare "patroller" colui che verifica i singoli edit altrui ma colui che autorizza la versione di una voce non è quel flag. Puoi chiamarlo "retropatroller" ma è comunque un'altra cosa. Le due funzioni si sovrappongono esattamente come patrolling e retropatrolling i quali, benché si sovrappongono come archi temporali e aree di interesse, comunque si chiamano diversamente perché sono cose non del tutto simili. Non è che quando uno ti dice che fa rtropatrolling gli chiedi di usare "patrolling" perché "è più semplice avere un nome solo" no? Solo che qua si va in crisi un po' anche all'idea di avere un nuovo flag distinto che bisogna metterlo subito a qualche classe che esiste se no "non è semplice" figurarsi due. Però sono diversi. Anche se ne vuoi fare solo uno non devi mai dimenticare che stai verificando il singolo edit, mai la voce. E che quindi una voce con edit non verificati, anche uno solo, non è verificata.

Puoi segnalare liste di back log di voci non del tutto verificate ai progetti ma a quel punto eccoti un bel carrozone ulteriore di lavoro di voci organizzate per argomento. Come ho detto sopra un modo bbastanza fluido di sposare quel lavoro ai progetti tematici, a cui inevitabilmente si indirizza, è spostarlo nelle categorie di servizio degli avvisi perché sono quelle che già si usano. Il che comporta che qualcuno legga la voce e faccia delle scelte basate sul buon senso assumendosi la responsabilità di togliere quella voce dal back log, quindi o che sani l'eventuale problema perché è competente in materia, o che inserisca un avviso che segnali il problema o che si assuma la responsabilità di dire non implicitamente ma esplcitamente che la voce va bene. Sbaglierà in alcuni casi, ma pazienza, fa parte del gioco. Questa, lo ripeto, è una funzione un po' diversa dal valutare il singolo edit. Richiede indubbiamente ancora più esperienza. Se tu definisci patrollata la voce che ha verificata l'ultima versione stai fissando il flag de facto di patroller a questo livello, che è molto avanzato. Quindi ce l'hanno poche persone, quindi hai un boom di modifiche inevase che temo ti spingranno a ripensare il problema. Se definisci il patrolling sull'edit ma non definisci una voce automaticamente patrollata se il suo utlimo edit è verificato, lo puoi dare a una classe più vasta di persone, hai molte più modifiche verificate ma hai comunque delle voci non verificate nel complesso. Meno che nell'altro scenario, ma ce le hai. Quindi o tramite elenchi di retropatrolling fatti parecchio bene o tramite un flag specifico di retropatroller dovrai gestirle.

Quindi non è una scelta da fare "dopo". Quando tu non approfondisci il valore che stai dando al patrolling dell'ultimo edit (cosa che quasi sempre ti pota a dire ultimo edit patrollato=voce patrollata, perché è "semplice") tu stai facendo una scelta comunque adesso, non dopo. Il punto è che la fai surrettiziamente. Ma c'è differenza fra scegliere una cosa dopo e gestire dopo una cosa che stai comunque scegliendo adesso.--Alexmar983 (msg) 21:50, 6 feb 2016 (CET)

Forse ho capito meglio. Certo che si fatica eh... Comunque... Oggi per noi se verifichi l'ultimo edit verifichi l'ultimo edit e basta. Stiamo ragionando di un sistema che, a quanto abbiamo visto, dopo un tot di tempo considera tutte le modifiche verificate, nel senso che un po' getta la spugna. Un mese o tre mesi cambia abbastanza poco ai fini di un retropatrolling. Se avessimo invece un sistema in cui la modifica resta non verificata indefinitamente, comunque io avrei in testa un flag (e una funzione) di tipo light: la verifica va sempre intesa del singolo edit. Ovviamente non si può ignorare la crono, almeno quella recente. Infatti se io reverto un vandalismo che è solo l'ultimo e lascio il penultimo, sono stato superficiale. Se verifico l'ultimo edit e non verifico (in nessun senso) il penultimo, che, mettiamo, è un vandalismo, un sistema che lascia indefinitamente in sospeso gli edit da verificare diventa ancora più utile, perché già solo scorrendo la crono mi saltano all'occhio i singoli edit che non sono stati ancora verificati.

Non sono granché convinto che si possa intendere l'ultimo edit verificato come una implicita benedizione per tutta la voce in generale. Non capisco chi la intenderebbe così. Non il lettore medio, che di queste cose non sa (le "sente", magari senza saperle, se legge de.wiki); non il collega pediano, che dovrebbe tendere a vedere verificato il solo singolo edit (stessa cosa per il sysop). Sarebbe come dire che se io correggo un refuso sulla voce X qualcuno allora "ci è passato Pequod, la voce è ok". Non sarebbe sostenibile (anche ad essere molto ottimisti sulla mia bravura).

Se ci dicessero che sì, si può evitare che le modifiche vengano segnate come verificate dopo un po' per "gettata di spugna", ma che bisogna tracciare una linea-soglia da oggi, mi starebbe anche bene. Significherebbe che a partire dalla data X, tutti gli edit precedenti li consideriamo verificati (un po' come oggi). L'alternativa unica sarebbe individuare quella stessa soglia e considerare NON verificati tutti gli edit precedenti. Ma non vedo l'utilità di ripassare un milione e più di voci e di stare a verificare ogni singolo edit: è molto più lineare considerare la voce come un risultato che non come un processo. Del resto, l'evidenziazione degli edit non ancora verificati serve come aiuto per scovare situazioni sensibili, ma se vuoi avere il polso dello stato della voce forse è più lineare leggere la voce e basta. Se qualcosa non funziona nella voce, controlli la crono.

Forse una cosa che nega quanto ho appena detto è la seguente: certe volte la voce X raggiunge un livello di qualità che ipotizziamo A, ma con il tempo diventa A-, cioè peggiora, magari di poco. Di ciò ci si accorge solo leggendo la voce "a fette", cioè lungo la crono, non dalla lettura della voce "come risultato".

Non so se da quanto ho scritto puoi intendere cosa ho capito e cosa no del tuo discorso. Ci sto provando, ma cerca di essere chiaro, non fare il pippardo. ;D pqd...Ƿƿ 01:19, 7 feb 2016 (CET)

una wiki che ha impiegato anni per porsi un problema strategico che si sarebbe dovuta porre anni prima (non sono polemico, lo dico con amarezza, ma è un fatto oggettivo comparati alle altre) è per definizione faticosa. Manca una visione dl patrolling non dico condivisa ma conscia dell'alterità, delle contraddizioni che si annidano in termini scelte che non vogliono dire per tutti la stessa cosa. Quindi ad esempio manca nella massa il concetto, la categoria mentale, se patrollare l'ultimo edit di una voce può voler dire cose diverse. Quando un interlocutore assume che l'altra interpretazione sia improbabile, ogni spigazione sarà "cervellotica" o "pipparda" ma tu hai idea la fatica che si ha a dare dignità a problemi, a visioni, a strutture che la massa pensa in partenza siano "minori" o semplici dettagli quando sono insiti esplicitamente o implicitamente in ogni sistema di patrolling modifiche? Però se non lo fai, davvero alla fine si rischia di decidere qualcosa in modo surrettizio. Quando tu scrivi "Non capisco chi la intenderebbe così", hai presente che ci sono wiki com DEwiki, de facto la "numero 2" (senza barare...) che la intendono proprio così? esempio. C'è stata una modifica da IP, stupida. Io ero già AP o patroller passivo, ma non attivo. L' IP non era nulla. Tutte le mie modifiche dopo l'IP, che aveva nascosto in automatico il testo modificabile, non potevano essere rese visibili da me. Non avvo il flag, l'auotorità, di dire ch quel "+1" era ok. Finché alla fine compare "[gesichtet von Symposiarch]", ma non all'IP. Alla mia modifica finale. Perché Symposiarch su DEwiki non verifica l'edit dll'IP ma la VERSIONE. Del resto ha anche senso, in alcuni casi sarebbe faticoso dare l'ok a 20 versioni dello stsso autore, ma il punto è che mentre ti sposti dall'edit all'ultimo edit a catena per i precednti è già una cosa diversa.--Alexmar983 (msg) 01:00, 8 feb 2016 (CET)

[← Rientro] Questa sezione ha come titolo "Cosa significa verificare": io invece vorrei sapere cosa significano questi fiumi di parole in libertà, perché non ci ho capito niente. --Euphydryas (msg) 12:01, 8 feb 2016 (CET)

Cosa significa verificare: Riassunto

[@ Euphydryas] e tutti gli altri che passano di qui, ma non hanno voglia/tempo di leggere i milabyte qui sopra, provo a riassumere in poche righe. Lo schema di Pequod, che divide in tre fasi principali il "verificare una modifica" (1. «La modifica è di mia competenza, la verifico». 2. «La modifica non è di mia competenza, non so se verificarla o meno». 3. «La modifica non è di mia competenza, ma non sembra un vandalismo, la verifico».), è condiviso da Retaggio, che approfondisce il secondo punto, ovvero le modifiche in cui il patroller non è certo che siano da annullare (che siano vandalismi o meno): è da qui che nascono anche le sezioni che leggiamo sotto. Retaggio analizza quindi tre condizioni necessarie relative alla verifica, ovvero (grassetto mio):

1. La modifica deve apparire come "non verificata" per tutto il tempo necessario fino a che non viene effettivamente verificata; quindi non per 30 o 60 giorni, ma per un tempo indefinito. Lo strumento "MarkUnpatrolledContribs" ad esempio segnala le modifiche come "non verificate" solo fino a un massimo di 30 giorni, dopodiché le "verifica" automaticamente, non importa se siano vandalismi o non. (vedi #Discussione_sul_punto_1)
2. I verificatori devono essere utenti considerati "affidabili" dalla comunità. Per capirci: amministratori, rollbacker, al massimo autoverificati. Attenzione: non ho detto "competenti" ma "affidabili": possono anche non essere esperti di fisica quantistica, ma se sono "affidabili" possiamo essere certi che segnaleranno il problema al progetto (o utente) competente. Al momento, in effetti, siamo lontanissimi da ciò: scusate se mi ripeto, ma è un vero controsenso che per avere le proprie modifiche "autoverificate" bisogna diventare AV (con il placet comunitario quindi), mentre invece chiunque, automaticamente dopo 4 giorni, può verificare le modifiche degli altri. (vedi #Discussione_sul_punto_5)
3. Ultimo, chiunque vede una modifica che considera accettabile deve necessariamente ricordarsi di segnarla come verificata (cosa che al momento non avviene sempre, ammettiamolo), per non appesantire inutilmente la lista dei casi in attesa di verifica.

Non stiamo dicendo insomma roba da poco: almeno un grosso problema tecnico e un pesante cambio di mentalità. E' possibile?

Secondo Alexmar983, sempre se non ho capito male, esistono due "classi di verifica" delle modifiche: quello della modifica singola (verificare un'edit alla volta) e quello della voce totale (verificare tutta la voce in una volta sola). Chiede quindi la creazione di un nuovo flag, e qui arriviamo al #Discussione_sul_punto_6: gli autoverificati (AV/AP) potranno verificare singolarmente solo gli edit degli utenti non-verificati, mentre altri utenti col "nuovo flag" patroller potranno verificare la voce totale. Questa proposta è stata bocciata da più utenti.

#Discussione_sul_punto_2: vedere direttamente nella cronologia della voce chi ha verificato ogni modifica.

#Discussione_sul_punto_3: verificare le modifiche tramite popup.

#Discussione_sul_punto_4: segnare automaticamente come verificate le modifiche che vengano annullate (da chiunque, sia dal patroller sia dal vandalo).

#Discussione_sul_punto_7: poter verificare più volte ciascun edit, anche di autoverificati. --Dimitrij Kášëv 09:42, 9 feb 2016 (CET)

Commenti al riassunto

[@ Dimitrij Kasev] grazie!!! --Euphydryas (msg) 10:28, 9 feb 2016 (CET)

Le classi di verifica sono tre:

1)proprio edit, cioè l'AP/AV, l'autorpatolled/autovrificato, il "verificatore passivo"

2)edit altrui, cioè il patrollatore o verificatore attivo

3)versione, cioè il patrollatore di versione o il controllore attivo o il retropatroller

Quasi tutti i miei interventi fanno notare che la gente confonde la modifica edit con la versione

e come ho detto (1) e (2) hanno un inclusione logica, mentre (2) e (3) hanno correlazione

un problema che tornerà di nuovo e di nuovo e di nuovo e che non puoi gestire tre classi di verifica con meno di tre flag. Puoi accorpare flag in più classi ma sono comunque tre ordini.

molte wiki accorpano più livelli. Dewiki accopra la (2) e la (3). itwiki accorperebbe secondo alcune proposte fatte qui la (1) e la (2). Quale è il problema? Che l'accorpamento può essere fatto dando flag simili a classi di utenze o ignorando del tutto un flag ma non dovrebbe mai essere surrettizio. Devi ssere cosciente cosa stai accorpando, proprio a livello operativo.

Siccome tanto tre è burocrazia, ho ribadito che se devi accoprare qualcosa fa meno danno (cioè le complicazioni che ne derivano sono meglio gestibili) accorpare (1) e (2) che (2) e (3). perché con (1) e (2) al di là di qualche bisticcio sui nomi (do il patrol agli AP ma continuo a chiamarli AP) è chiaro a tutti cosa stai accorpando, la risposta è nelle linee guida. (2) e (3) no. tanto è che quando parli esplciitamnte di verifica versione mettendo il problema davanti agli occhi la gente continua a parlare di verifica edit, come se fossero la stessa cosa (leggi i commenti alla proposta 6). Lo vedi in tutti gli interventi anche in quelli segnalati come "buoni" per riassunto. vedi questo esempio--Alexmar983 (msg) 12:49, 9 feb 2016 (CET)

Dubbio: verifico o no?

Da quando sono iscritto ogni giorno, nel controllare i miei OS (al momento quasi 18mila pagine: tutta la Categoria:Antica Grecia fino al 40° livello, buona parte della Categoria:Antica Roma e qualcos'altro di extra), verifico tutte le modifiche non vandaliche e tutte quelle che annullo, lasciando il famoso "!" rosso solo nei casi in cui sono incerto, che a volte segnalo ad utenti che conosco e in altri casi semplicemente lascio perdere (sì, lo confesso ...). C'è però un dubbio sul quale mi sono sempre arrovellato, dato che non esiste una spiegazione chiara in Aiuto:Verifica delle modifiche: posto il caso in cui una voce subisca in successione una modifica A "dubbia" (inserimento di una voce correlata poco pertinente; inserimento di una frase senza fonte [se la voce è perfettamente dotata di fonti annullo, ma se ha già in cima un {{F}} e non conosco bene l'argomento mi dispiace annullare tout court] ...) e una modifica B che non presenta problemi (correzione ortografica; aggiunta di una categoria ...) ma che non annulla la modifica A, è giusto che io segni come verificata la modifica B? In teoria, essendo B una modifica senza problemi, l'azione dovrebbe essere corretta; il mio dubbio nasce dal fatto che, nel caso in cui un utente abbia impostato le preferenze degli OS per vedere solo l'ultima modifica apportata ad una voce (come del resto faccio io), il mio comportamento potrebbe impedire ad un tale utente di notare la modifica A "problematica". Qual è il comportamento corretto, considerato anche che per me sarebbe assai scomodo contattare uno o due progetti al giorno? --Epìdosis 20:11, 6 feb 2016 (CET) P.S. Credo di essere parzialmente OT, scusatemi!

ah manco a farlo apposta, è quello che citavo sopra. Questo è il problema di fondo che si ha non separando fra verifica del singolo edit e quello della voce. Quello che va evitato è l'errore di attribuire un flag di patroller senza aver chiaro cosa si sta patrollando. Solo che la chiarezza per un flag che ha connotazioni operative viene immaginando molto concretamente quali sovrastrutture ne derivano. Non è saggio andare troppo a "braccio" perché davvero si rischia di trovarsi code di lavoro o inefficienze inattese da sanare.--Alexmar983 (msg) 21:58, 6 feb 2016 (CET)

Secondo me devi sentirti tranquillo a segnare come verificata la B. Infatti, nella tua ipotesi non segni, così l'utente Caio cosa fa? Guarda, come te, l'ultima modifica e... si pone lo stesso dubbio e non segna, poi è il turno di Sempronio... e tutti restano impallati. Ma la catena si spezza solo quando qualcuno, l'utente:John Carter, nel controllare un edit, verifica la crono. Infatti controllare il penultimo edit è già verificare la crono. Ovviamente questo controllo può essere più o meno profondo (penultimo edit, terzultimo, ultima settimana, ultimi 30 edit...). Solo John Carter sta facendo quel tipo di controllo e non credo che gli sarebbe impedito dal tuo click, perché lui sa che non è nell'ultimo edit che risiede la verità di quella crono e di quella voce. Il che non significa che segnare come verificato un solo edit (magari l'ultimo) sia inutile. Poi è certamente giusto, come mi pare lasci intendere Alex, cercare di diffondere una nozione comune di "cosa significa verificare". Bisogna quindi mettersi d'accordo, a partire dalla pagina di aiuto, in cui cercare di spiegare questa cosa, in un senso o nell'altro. pqd...Ƿƿ 01:28, 7 feb 2016 (CET) P.S.: Comunque, la prima cosa che deve imparare un admin è proprio questa: quando ti cade l'occhio su una voce, quale che sia la ragione, per prima cosa guarda la crono.

Riassunto per punti

Provo a riassumere quanto emerso e le varie proposte operative emerse in questa discussione. Possiamo così decidere quali discussioni proseguire in questa pagina e quali migrare a pagine di discussione più consone. Grazie a tutti gli utenti finora intervenuti! Buona notte, --Epìdosis 23:50, 6 feb 2016 (CET)

1. Evidenziare i contributi non verificati nelle cronologie con un punto esclamativo rosso o con uno sfondo giallo
   • Pro: semplificherebbe il retropatrolling; metterebbe sull'avviso chi consulta la cronologia
   • Contro: nessuno
   • Fattibilità: ? (vedi Phabricator: [1], [2], [3])
2. Permettere di vedere direttamente in cronologia chi ha verificato le varie modifiche subite dalla voce
   • Pro: maggiore fruibilità della lista dei patrollatori, che altrimenti è quasi come se non esistesse
   • Contro: appesantimento dell'interfaccia; duplicazione del collegamento ai registri della pagina
   • Fattibilità: ?
3. Poter verificare le modifiche tramite i popup
   • Pro: numerose modifiche, non essendo verificate, attualmente potrebbero essere ricontrollate più volte da diversi patrollatori
   • Contro: nessuno
   • Fattibilità: ?
4. Segnare automaticamente come verificate le modifiche annullate, così come già succede con quelle rollbackate
   • Pro: si evita al patrollatore di dover compiere l'azione manualmente
   • Contro: nessuno
   • Fattibilità: ? (phabricator:T16439)
5. Spostare il permesso patrol dagli autoconvalidati agli autoverificati
   • Pro: eviterebbe possibili errori (inesperienza) o abusi (malafede) da parte degli utenti non autoverificati, la cui contribuzione non è stata scrutinata per l'assegnazione del flag
   • Contro: non si intravede un rischio pregresso o incombente di abuso; meno utenti hanno accesso alla verifica delle modifiche
   • Fattibilità: ? (richiede molto lavoro per assegnare i diritti)
6. Creare anche un gruppo "patrollatori" che possano "sancire come verificata la versione data di una voce" (cit. Alexmar983)
   • Pro: ? (vedi m:FlaggedRevs)
   • Contro: avvitamento burocratico e altri (vedi m:FlaggedRevs)
   • Fattibilità: molti mesi di lavoro per varie persone che vogliano portare avanti la cosa (m:Flagged_Revisions#Enabling), poi un costo continuo di mantenimento
7. Fare sì che si possa verificare più volte uno stesso contributo, anche di un autoverificato
   • Pro: più occhi vedono meglio di uno
   • Contro: lavoro extra
   • Fattibilità: estremamente difficile, richiederebbe una totale riprogettazione della tabella nel database

se si vogliono chiamare "patrollatori" quelli che patrollano le singole modifiche e sono diversi dagli autopatrolled ovviamnte il nome sarà diverso... avevo ridotto a due flag e non inventato nuovi nomi solo perché se ne avessi detti tre sarebbe stato troppo strano per tutti. qui altri dttagli--Alexmar983 (msg) 00:32, 7 feb 2016 (CET)

Tra i permessi attuali abbiamo patrol, che consiste in Segna le modifiche degli altri utenti come verificate, e autopatrol, che consiste in Segna automaticamente le proprie modifiche come verificate (si tratta dei nostri AV). Nel caso serva una terza funzione, bisogna trovare un terzo nome. pqd...Ƿƿ 01:50, 7 feb 2016 (CET)

Appunto... una cosa è il flag, una cosa il nome del gruppo. Uno dei problemi tipici di wiki è che non si distinguono, se leggi bene sono stato anche io che ho messo in guardia esplcitamente su questo fatto? Quando qualcuno ha iniziato a dire "mettiamo patrol agli AP/AV" chi ha notato che allora dovresti cambiare nome agli AP/AV? Nella mia proposta i flag rimanevano due, uno per i "patrollatori di voci" e uno per i "patrollatori di edit" in cui per semplificare avevo messo entrambi gli auto e no. Se dovevo introdurre il concetto in modo graduale non potevo farlo proponendo un sistema a tre flag. Quindi per introdurre il concetto ho accorpato il flag che è esplicitamente un sottoinsieme di un altro. La verifica edit non è un caso specifico di verifica della voce, sono due cose interrelazionate ma diverse come tipo di lavoro, mentre la verifica del proprio edit singolo è un caso generale, semplice inclusione logica, della verifica di ogni edit singolo. --Alexmar983 (msg) 12:57, 7 feb 2016 (CET)

• [@ Epìdosis]: aggiungerei il punto 7: far sì che un contributo non diventi mai automaticamente verificato. Quanto alla proposta 6 di [@ Alexmar983], non la condivido, ma mi riservo di dare una spiegazione più articolata in un altro momento. Alla fine l'unica proposta che può essere presa da subito con decisione comunitaria interna ad ITwiki è la 5: riproponiamo al bar generale? --Cpaolo79 (msg) 10:59, 7 feb 2016 (CET)

prego, io posso solo ribadire che uno dei problemi della discussione è stato che "bisogna tracciare una linea-soglia" (o simile). Se sei a combattere con un vandalo sistemico ogni volta devi riaprire alla crono, riscorrere gli edit e rollbackare a una versione decente che può anche contenere tracce del vandalo sotto un Ip inusuale o contenere utenze valide ma che conosci poco. Ebbene, la possibilità di individuare subito una versione accettabile è di aiuto enorme. Perché chiunque ha il potere di annullare le modifiche prima di un certo momento, ma non tutti hanno la competenza o tematica o di conoscenza di utenze di fissare quel momento. Facendolo in modo più chiaro e ragionato di "l'ultima versione con un edit confermato da un paroller" tu permetti a chiunque di ristabilire una versione funzionale, in caso di emergenza, su più voci. L'amministratore, il rollbacker o il retropatroller esperto (che sta iniziando a prendersi il rollbakcer pure lui) può anche dopo un po' prendere la mano a capir cosa ripristinare, ma come può comunicare bene all'utente o al collega meno esperto presente alle tre di notte quale è il rollback più sicuro da seguire? Ci sono modi surrettizi di individuare una versione di voce complessivamente patrollata ma un percorso netto associato a un flag rimane un'opzione pratica se si superassi lo "stress di n+1 flag, che n vanno bene ma '+1' è burocrazia". Perché a differenza del "patroller" per l'edit, che dato a soli 110-120 fra amministratori e rollbacker ha un effetto "collo di bottiglia", quel tipo di "patroller" (sulla versione o sulla voce che dir si voglia) potrebbe essere davvero associato ai flag avanzati, è proprio il gruppo perfetto come competenze e dimensioni. --Alexmar983 (msg) 12:57, 7 feb 2016 (CET)

Fatto, ora risegnalo al bar generale. --Epìdosis 12:27, 7 feb 2016 (CET)

---

---

Provo ad aprire delle sottosezioni per discutere o semplicemente appoggiare i sette punti emersi. --Epìdosis 13:02, 7 feb 2016 (CET)

Discussione sul punto 1

Evidenziare in crono i contributi non verificati

Si sono già espressi a favore [@ Etrusko25, Epìdosis, Supernino] (qualunque evidenziazione) [@ Rotpunkt, Retaggio, Pil56, Fullerene] (punto esclamativo rosso; alcuni li ho inferiti dal fatto che hanno apprezzato il tool di Rotpunkt) [@ Pequod76] (qualcosa di più appariscente del punto esclamativo rosso) [@ Nicolabel, Dimitrij Kasev, Xinstalker] (evidenziato in giallo) [@ Updown] ("soluzione grafica morbida"). --Epìdosis 13:35, 7 feb 2016 (CET)

Sono anch'io favorevole.--Cpaolo79 (msg) 20:43, 7 feb 2016 (CET)

Senz'altro favorevole, ma ho solo un appunto di dettaglio: al punto esclamativo preferirei che fosse evidenziata in giallo la riga della cronologia non verificata. --Nicolabel 21:30, 7 feb 2016 (CET)

l'evidenziare in giallo (e rosso) è collegato al ORES . Il patrollatore dovrebbe avere entrambi i dati, quello cromatico dall'ORES e quello dal flag.

In compenso parlando di ORES io agirei anch sullo sfondo di "cronologia". Al momento puà comparire colorato lo sfondo della linguetta in alto a dstra, quella vicino alla barra di ricerca. La cosa è abbastanza disorientante perché spesso, se ho capito bene come funziona, mi segnala in arancione lo sfondo anche per un falso positivo segnalato da ORES parecchie settimane prima. Almeno così mi è parso le poche volte che ho provato a capire. Ho auto la netta sensazione di perdere tempo in molti casi. Ecco forse io non metterei sfondi cromatici alla linguetta "cronologia" ma farei comparire davanti a "cronologia" aprendo la pagina da utente un "!" per segnalare la presenza nella crono di "!" non verificati.

In ogni caso abbiamo l'informazione sulle modifiche utenti e quella di ORES che devono esser segnalate bene nella crono aprendola in modo distinti e al secondo ordine ci dobbiamo chiedere se le vogliamo riassunte (una o entrambe) nella linguetta "cronologia" in alto a destra, in modo che aprendo la voce possiamo ricevere un messaggio che indichi "ehi, guarda in cronologia se tutto quadra"--Alexmar983 (msg) 00:41, 8 feb 2016 (CET)

Premettendo che so poco o nulla di informatica e quindi potrei pure dire castronerie... Non sarebbe mpiù facile riformare quello che già c'è (ScoredRevisions basato su ORES appunto, che da quel che vedo non ha il limite dei 30 giorni delle ultime modifiche ma si basa su qualcos'altro) piuttosto che inserire nuovi tool? Non si potrebbe (ovviamente tenendo conto che non dipende solo da noi) tentare di creare un nuovo "model" che evidenzi in giallo di default tutti i non autoverificati e poi abilitarlo su it.wiki?--Caarl⁹⁵ 15:41, 8 feb 2016 (CET)

Caarl 95 sono due sistemi complementari: ORES è una macchina, l'altro è una sovrastruttura umana. Non ha molto senso scegliere fra uno e l'altro, ha più senso lasciare che si sviluppino in parallelo e si perfezionino al limite imparando e migliorandosi reciprocamente. Qualunque cosa ch è così avanzata da integrarli può venire solo dopo molto tempo. sceglierne uno solo sarebbe strano.--Alexmar983 (msg) 21:25, 8 feb 2016 (CET)

+1 all'inserimento dei punti esclamativi degli OS (o soluzioni simili) nelle cronologie; su altre wiki (se non hanno cambiato), spesso si può vedere un avviso di ultima versione non verificata anche leggendo la voce. --Supernino 10:14, 8 feb 2016 (CET)

+1 Come Nicolabel, sono assolutamente per la riga evidenziata in giallo. La funzione non è solo per chi verificherà ma anche per chi inserisce il testo "che sa" che la sua modifica è in giallo... --Xinstalker (msg) 10:52, 8 feb 2016 (CET)

• Confermo Favorevole --Retaggio (msg) 12:05, 8 feb 2016 (CET)

• Sì, anch'io - per un paio di giorni - mi sono trovato bene con la riga evidenziata di giallo, si distingue più facilmente ( Favorevole). --Dimitrij Kášëv 18:43, 8 feb 2016 (CET)
• Io però non capisco quale è il piano per coordinare ORES con questo... ho letto uno sfondo "giallo chiaro" che non si confonde alla scala cromatica giallo/rosso di ORES ma come si evita il rischio di sovrapposizione delle informazioni? Anche se immagino che la conversione della "!" in un colore di sfondo sarà introdotta come spunta delle preferenze (in genere si fa così, che accontenta tutti, o qualcosa di simile) esattamente, che sia una spunta a richiesta o un cambiamento per tutti, che cosa si sceglie quando si chiede di avere una barra-riga colorata al posto di "!"? Il piano è di dare la precedenza a uno in particolare perdendo l'altro? Cioè se scelgo di togliere "!" per il patrolling tutto ciò che è sotto 80% di ORES e assieme non patrollato compare in giallo chiaro e poi sopra 80% subentra la classe cromatica di ORES? Era così che è stato fatto il test? per curiosità, su DEwiki le versioni in attesa di patrollamento che sono un gruppo a ridosso dell'ultima, compaiono in celeste... mai piaciuto ma in effetti il giallo è troppo "cattivo" perché molte sono giuste. Chissà perché proprio celeste, forse era più riposante per gli occhi.--Alexmar983 (msg) 21:46, 8 feb 2016 (CET)
• Favorevole. Preferirei però il punto esclamativo all'evidenziatura, per la sovrapposizione con ORES. --Fullerene (msg) 01:12, 9 feb 2016 (CET)
• Favorevole spero in una soluzione grafica morbida. --Updown(msg) 01:17, 9 feb 2016 (CET)

[@ Alexmar983] per la proposta 1, se non sbaglio, non si è accennato ad una restrizione della visibilità delle modifiche da verificare, dunque suppongo che sia sottinteso che restino visualizzabili di default a tutti e solo gli utenti che possiedono la funzione di verificare le modifiche (a prescindere da quale si deciderà che essi siano). Per l'eventuale evidenziatura c'è invece da valutare la sovrapposizione con ORES: per il momento secondo me sarebbe meglio continuare con l'uso assodato dei punti esclamativi. --Fullerene (msg) 12:03, 9 feb 2016 (CET)

[@ Fullerene] Anche dopo il tuo intervento penso che non sia chiaro dove si vada a parare. Personalmente se come è possibile videnziare meglio con barra porta a una perdita dell'informazione su ORES o sull'altra, io come te mi tengo la "!". E quindi gradirei che fosse un'opzione per chi la vuole, non di default. Ma penso si chiarirà meglio discutendone a parte.--Alexmar983 (msg) 12:54, 9 feb 2016 (CET)

Se poi venisse creato come accessorio opzionale, come lo è anche ORES, non avrei alcuna obiezione, ma, almeno in attesa di trovare un'altra eventuale soluzione che non provochi l'inghippo individuato, penso che per i punti esclamativi si possa procedere da subito. --Fullerene (msg) 20:36, 9 feb 2016 (CET)

Appoggio. --Retaggio (msg) 09:50, 10 feb 2016 (CET)

Anch'io: credo che sia una proposta di buon senso --Nicolabel 10:06, 10 feb 2016 (CET)

Idem. --Dimitrij Kášëv 10:10, 10 feb 2016 (CET)

(rientro) Chiedo scusa ma per quanto attiene l'avvio della discussione da me proposta essa ineriva non al fatto di fornire uno strumento a "chiunque" ma di avvertire l'utente "cabbalista fondamentalista" (è un esempio, non c'è solo lui... magari fosse solo lui) che la sua modifica è sotto controllo e che prima o poi un utente "esperto" della materia saprà verificarla. Il tema non è la verifica orizzontale che possono fare tutti, quella del "cacca puzza" o giù di lì, ma di info più sofisticate e decisamente più pericolose per il progetto. Il problema è quello. Questo strumento serve a quel tipo di utenti che magari non sanno nemmeno cosa sia ORES ma possono sfogliare e verificare qualsiasi verso del Talmud Babilonese o di qualsiasi Upaniṣad, comprensive di fonti seconde accademiche, riuscendo con i virgolettati a inchiodare il furbo "fondamentalista" alle sue manipolazioni e devastazione POV (settarie e/o a volte con letteratura inventata di sana pianta) delle voci. La WikiDE non ha problemi perché lì il "fondamentalista" si attacca... la sua modifica non apparirà mai se non viene prima verificata da un utente "verificato". Qui è diverso se Monozigote se ne va, se Pequod vince al Superenalotto e se io in un momento di stizza cancello tutti gli OS..., tempo tre mesi e le voci oggi ottime si vanno a farsi friggere. Occorre che, se subentra qualcun altro, oppure Monozigote torna, Xinstalker si seda e Pequod perde tutta la vincita ai tavoli di Las Vegas, ci sia traccia evidente di ciò che è stato impostato e soprattutto il fondamentalista deve saperlo. Mi rendo conto che le questioni tecniche finiscano per prevalere sul Talmud o sulle Upaniṣad, ma la "voce" parla di quello e non di ORES. Se non piace il giallo perché confonde, facciamolo verde, viola, a puah (pois)... grazie! Altrimenti, è bene che ciò sia chiaro, siccome stiamo diminuendo rapidamente, forse non avremo l'evidenziazione in crono che disturba il nostro sguardo, ma avremo prima o poi non più Wikipedia... ma Nonciclopedia... e siccome non sapremo di aver un "nuovo" prodotto saremo contenti lo stesso... e tutto il lavoro di mani esperte sarà distrutto... in WikiDE invece sarà ben conservato... --Xinstalker (msg) 09:36, 10 feb 2016 (CET)

Per far sapere al vandalo che la sua modifica verrà verificata si potrebbe estendere la visualizzazione del punto esclamativo a tutti piuttosto che solo a coloro che dispongono della funzione patrol, come invece avviene attualmente. Tuttavia credo che l'uso della cronologia da parte di simili utenze sia abbastanza sporadico, dunque qualsiasi tipo di segnalazione (punto esclamativo o evidenziatura che sia) rimanga poco efficace: a tale scopo casomai andrebbe pensata una sorta di segnalazione al momento della modifica, ma non saprei. --Fullerene (msg) 23:03, 11 feb 2016 (CET)

Ascoltami c'è vandalo e vandalo. Qui ovviamente non stiamo trattando quello che scrive parolacce o cancella parte delle voci, stiamo parlando del vandalo pov-pusher. In questo caso c'è quello occasionale che legge la voce e siccome non coincide con il suo pov ignorante infila qualcosa e poi se ne torna quieto. Ma quello fa danni limitati (in genere una o due voci) ed quasi facilmente gestibile. Quello che mi preoccupa è un altro genere di vandalo pov-pusher, quello "sistematico". Non è un vandalo ignorante, anzi... conosce alla perfezione le dottrine della sua "setta" che sono l'unica verità in materia, frequenta assiduamente molte delle voci, modifica i suoi nick, è anonimo o anche non, tutto affinché la "Verità", cioè la sua, vinca sul mondo dei malvagi. Se è astuto si camuffa negli atteggiamenti disponibili, quasi sempre è "colto", quindi infila testi, cioè fonti prime (perché le seconde non ci sono altrimenti il suo non sarebbe POV ma sarebbe un contributo utile) distorte ai fini del suo POV. Lo smascheri solo quando conosci bene la materia, allora gli chiedi i testi, chi ha fatto le traduzioni, le fonti seconde, e alla fine scopri che i testi sono largamente minoritari e settari, le traduzioni antiquate e superate, le fonti seconde critiche inesistenti. Dal che lo inchiodi e lì esce il resto ovvero che gli studiosi sono "demoniaci", la "falsità" impera in questo mondo, Wikipedia è anti-ebraica-buddhista-cristiana-etc. in quanto poi l'unica lettura vera dell'ebraismo-buddhismo-cristianesimo e la sua.... Scoperto e seppellito con fonti accademiche e traduzioni aggiornate, scompare riapparendo in una sorta di battaglia nella jungla tipo vietcong. Difficile che molli perché ha una missione: redimere il mondo per mezzo di Wikipedia. Bene questo "tipo" di utente che siamo finora riusciti a rintuzzare e a gestire, quando non a cercare di arruolare in una contribuzione rispettosa dei Pilastri, è abile nei meccanismi di Wikipedia, conosce tutto compresa la crono. Deve sapere che se io crepo e DonatoD non torna o Pequod decide di ritirarsi in eremo, oppure Monozigote resta in Australia, ci sarà sempre qualcuno che controllerà la crono, che lui conosce e dove è ora "segnalato", e lo beccherà prima o poi. Anche perché questo tipo di utente è in grado di stravolgere intere voci distruggendo in modo radicale quelle che sono costate ad altri utenti ore di studio su numerose fonti terze. Questo problema in WikiDE non c'è più, l'hanno risolto in modo radicale, una voce che raggiunge un buon livello rimane lì e non ci sono vandali pov-pusher che possano devastarla.... --Xinstalker (msg) 12:31, 12 feb 2016 (CET)

Favorevole alla riga evidenziata in giallo, molto più visibile del punto esclamativo.--Kirk39 Dimmi! 17:59, 12 feb 2016 (CET)

[@ Xinstalker] se si ritiene che la segnalazione possa avere anche una minima efficacia, per me non c'è alcun problema a renderla visibile a tutti, sempre che sia tecnicamente possibile. Per l'evidenziatura invece non riesco a capire come faccia ad essere compatibile con il sistema ORES: anche creandola opzionale, gli utenti sarebbero impossibilitati ad attivare entrambi gli accessori. Tra l'altro il punto esclamativo non mi sembra che passi inosservato. --Fullerene (msg) 00:22, 13 feb 2016 (CET)

Per me il punto esclamativo è così significativo che mi trovo almeno 30 volte al mese a verificare edit già verificati (l'ultima volta pochi secondi fa). Non spicca, c'è poco da fare. Invece mi attivo ORES e lo provo, vediamo com'è. Se non ricordo male, l'avevo attivato quando fu avviata la sperimentazione e subito tolto, non ricordo perché. pqd...Ƿƿ 00:37, 13 feb 2016 (CET)

Favorevole, qualsiasi sia il metodo di evidenziazione. -- Helichrysum Italicum ^{(chiamami "Heli")} 15:15, 27 feb 2016 (CET)

Discussione sul punto 2

Vedere in crono chi ha verificato ciascun edit

Si è già espresso a favore [@ Pequod76]; io stesso sarei favorevole. --Epìdosis 13:35, 7 feb 2016 (CET)

Favorevole, ma non lo trovo indispensabile.--Cpaolo79 (msg) 20:43, 7 feb 2016 (CET)

+1 --Nicolabel 21:30, 7 feb 2016 (CET)

sì certo, credo da altre wiki che non sia una modifica pesante, tipo su dewiki si legge sempre "gesichtet von" (anche se purtroppo com dicevo solo sull'ultimo edit di un gruppo non verificato e non sul singolo edit). Un dettaglio da tenere presente è che in genere le informazioni di questo tipo sono già più raffinate, e forse sono un po' confusionarie per chi deve anche solo capire una cronologia come funziona. Su un sistema che deve alla verifica la visibilità del proprio lavoro è un concetto essenziale da "vedere" subito anche se si è neofiti, ma un sistema che non ha questo passaggio penso si possa anche non vedere fin da subito. Cioè non che debba essere così per forza, ma se ci sono idee in merito sui pro e contro, o si deve trovare un accordo con chi invece si oppone, si può anche definire meglio se tale funzionalità è una spunta addizionale delle preferenze, o un'informazione solo per utenti registrati o autoconvalidati.--Alexmar983 (msg) 00:32, 8 feb 2016 (CET)

Dato che rende l'interfaccia più caotica e non è utile ai neofiti, è opportuno inserirla solo come funzione opzionale da attivare con la spunta nelle preferenze. --MarcoK (msg) 11:13, 8 feb 2016 (CET)

• Come MarcoK, terrei come opzionale. --Retaggio (msg) 12:05, 8 feb 2016 (CET)

  cioè intendi come in quella delle due proposte che ho fatto, che va tenuta opzionale come spunta delle preferenze?--Alexmar983 (msg) 12:45, 8 feb 2016 (CET)

  Non ho capito a quali due proposte ti riferisci. Comunque, come ha detto Marcok. --Retaggio (msg) 13:01, 8 feb 2016 (CET)

• Serve a poco, se proprio si vuole opzionale.--Bramfab Discorriamo 15:13, 8 feb 2016 (CET)
• Anche per me rende l'interfaccia troppo caotica. Inoltre sapere chi ha verificato una modifica è utile solo in casi non troppo frequenti, quindi credo che sia sufficiente l'elenco dei registri dove già sono visibili. Nulla in contrario comunque se si volesse creare questo accessorio come opzionale. --Fullerene (msg) 01:23, 9 feb 2016 (CET)
• Come chi mi precede: accessorio opzionale che, se creato, potrà essere attivato dalle preferenze. --Dimitrij Kášëv 07:24, 9 feb 2016 (CET)
• Solo opzionale, come suggerito da MarcoK--Kirk39 Dimmi! 18:12, 12 feb 2016 (CET)
• Specifico il mio parere: concordo sull'opzionale. --Epìdosis 18:10, 14 feb 2016 (CET)
• +1 da attivare come opzione. -- Helichrysum Italicum ^{(chiamami "Heli")} 15:16, 27 feb 2016 (CET)

Discussione sul punto 3

Verificare le modifiche anche tramite popup

Si sono già espressi a favore [@ Nicolabel, Dimitrij Kasev, Euphydryas, Etrusko25]. --Epìdosis 13:35, 7 feb 2016 (CET)

• Favorevole. --Fullerene (msg) 01:26, 9 feb 2016 (CET)
• Favorevole, sarebbe un'accelerazione molto utile.--Kirk39 Dimmi! 18:13, 12 feb 2016 (CET)
• Favorevole (nel frattempo mi sono perso un po', ma questa opzione mi è appena venuta in mente e così son tornato a vedere come procede la discussione) --Ghess-hu? (Indovina chi) 11:21, 16 feb 2016 (CET)
• Favorevole pqd...Ƿƿ 14:37, 17 feb 2016 (CET)
• Favorevole -- Helichrysum Italicum ^{(chiamami "Heli")} 15:17, 27 feb 2016 (CET)

Discussione sul punto 4

Segnare automaticamente come verificate le modifiche annullate

Non ho trovato favorevoli espliciti (forse [@ Cpaolo79]), ma io stesso credo sarebbe una comodità. --Epìdosis 13:36, 7 feb 2016 (CET)

Non uso molto i popup ma credo anche io che sarebbe uno strumento utile e probabilmente lo usereiScusate avevo fatto confusione con la proposta 3--l'etrusco (msg) 17:03, 7 feb 2016 (CET)

Sarebbe un passaggio in meno, quindi io sono favorevole. --Dimitrij Kášëv 19:55, 7 feb 2016 (CET)

Sì, favorevole. --Cpaolo79 (msg) 20:43, 7 feb 2016 (CET)

Sono favorevole anche a questa proposta.--l'etrusco (msg) 21:56, 7 feb 2016 (CET)

• Contrario: raramente, è l'annullamento di un'azione altrui ad essere la violazione (caso più edvidente, le edit war o comunque quei casi in cui un utente annulla un rollback). --Harlock81 (msg) 00:33, 8 feb 2016 (CET)

  Ma l'annullamento in sé sarà comunque da patrollare. Non serve invece che una modifica non piú esistente sia sottoposta a verifica. Nemo 11:04, 8 feb 2016 (CET)

• anche io sono Contrario. Il rollback è un flag avanzato, ma l'annullamento in sè non vuol dire nulla.--Alexmar983 (msg) 01:02, 8 feb 2016 (CET)

Contrario (vedi 2° intervento), non tutti gli annullamenti sono assimilabili al rollback eseguito con l'apposito bottoncino. --Supernino 10:14, 8 feb 2016 (CET)

Favorevole Se una modifica è stata annullata vuol dire che è stata fatta una valutazione sulla stessa. Quindi (indipendentemente che fosse vandalica o meno) è già stata verificata da qualcuno, per definizione. --MarcoK (msg) 11:09, 8 feb 2016 (CET)

• Contrario Va in conflitto con le proposte 5 o 6. Le modifiche le possono annullare tutti, anche gli IP. --Retaggio (msg) 12:05, 8 feb 2016 (CET)

[@ retaggio] in discussione ho spiegato come la proposta è di considerare verificate le modifiche di annullamento annullate, il cui edit di annullamento sia stato operato da AV (o utenti con permessi superiori). --Cpaolo79 (msg) 12:39, 8 feb 2016 (CET) [ulteriormente rimaneggiato da Pequod76]

Non avevo notato, se così la cosa cambierebbe. Comunque dovremmo specificare che questa proposta non "vive" da sola, ma solo come dipendente dalla proposta 5. Venendo al merito, teniamo presente che così facendo stiamo di fatto "dividendo" l'annullamento in due: un primo tipo per gli AV e un secondo per tutti gli altri: se così, ripeto, non mi direi contrario, ma bisogna anche verificare la fattibilità. --Retaggio (msg) 12:46, 8 feb 2016 (CET)

(f.c) [@ retaggio], come mi fa giustamente notare [@ Pequod76], così come scritta inizialmente la mia frase non ha senso: l'ho riscritta. --Cpaolo79 (msg) 18:29, 8 feb 2016 (CET)

Secondo me occorre specificare meglio se la proposta è relativa ad ogni annullamento o solo a quelli di utenti ritenuti affidabili (autoverificati, ad esempio). In ogni caso, dato che qualunque edit di un autoverificato è verificato di default, credo che la seconda interpretazione esista già nella pratica. --Nicolabel 12:43, 8 feb 2016 (CET)

Avevo anche io dato per scontato che gli annullamenti da considerare automaticamente verificati fossero quelli degli utenti autoverificati - che esposto così suona tautologico, mi rendo conto. Sono contrario, ça va sans dire, a verificare in automatico gli annullamenti di utenze di non accertata affidabilità. --l'etrusco (msg) 13:38, 8 feb 2016 (CET)

Secondo me non va in conflitto con la proposta 5, quanto meno per una ragione curiosa. È vero, ovviamente, che talvolta è l'annullamento a essere abusivo. Ma consideriamo la cosa così: se l'annullamento è abusivo (cioè, annulla un edit buono), segna come verificato un edit buono (il che è in sé stesso desiderabile). Se invece l'annullamento è corretto (cioè, annulla un edit cattivo), allora segna come verificato e processato un edit cattivo, annullandolo (anche questo è desiderabile). Nella prima ipotesi, è importante notare che l'edit annullato viene segnato come verificato, non così l'edit dell'annullamento. La ratio della proposta 5 è evitare che l'utente vandalico-sottile Geronimo faccia un edit malevolo e venga coperto dall'utente alleato (o sock) Filippo, che gli segna verificato l'edit. Ma se Filippo annulla l'edit di Geronimo e glielo segna verificato, non potremo che ringraziarlo. Né sarebbe di alcun aiuto che l'edit buono, annullato dal malevolo Giampoldo, resti segnato come non verificato. C'è insomma differenza tra "segno come verificato" e "annullo e segno come verificato": della seconda mossa può essere abusivo la parte "annullo", ma questo è già vero di qualsiasi annullamento errato o malevolo, nonché di qualsiasi edit-war. Mi sembra che possiamo tranquillamente accogliere la proposta. pqd...Ƿƿ 14:00, 8 feb 2016 (CET)

"Sono contrario, ça va sans dire, a verificare in automatico gli annullamenti di utenze di non accertata affidabilità", scrive Etrusco. Ecco, il punto dovrebbe essere proprio questo: non è l'annullamento che risulterebbe verificato (lo ha scritto Nemo: "l'annullamento in sé sarà comunque da patrollare"). La proposta riguarda l'edit annullato, non l'edit che annulla. pqd...Ƿƿ 14:02, 8 feb 2016 (CET)

Incerto su questo punto. L'annullamento porta la voce a uno stato precedente, verificare questo passaggio potrebbe essere evitato solo se il patrolling della modifica fosse immediato ed efficace. In caso contrario è più funzionale avere gli annullamenti da verificare in crono. --Updown(msg) 14:42, 8 feb 2016 (CET)

[@ Updown] La proposta, lo ripeto, è considerare verificati gli edit annullati. Gli annullamenti, invece, resterebbero da verificare. pqd...Ƿƿ 14:53, 8 feb 2016 (CET)

Però "a colpo d'occhio" forse sarebbe meglio rimanessero come da verificare tutte le versioni malvagie, visto che di solito ho l'impressione patrollando in real time che si tende a considerare l'ultima versione verificata come "buona" prestando meno attenzione agli edit precedenti. Però dopo la precisazione di [@ Cpaolo79] intanto mi sposto sul neutrale nel caso dell'annullamento ad opera di un AV, e neutrale/tendenzialmente contrario nel caso di un annullamento di non AV (per i casi in cui -chiarisco- in crono si susseguono più versioni non buone, "annullamento" compreso; non che ci sarebbe tanto danno, restando l'ultima in effetti da verificare, per questo mi limito a tendenzialmente) --Supernino 15:48, 8 feb 2016 (CET)

[@ Pequod76] In effetti l'annullamento di un edit implica una verifica e in crono ne rimarrebbe comunque traccia. Inteso così mi vede favorevole. --Updown(msg) 16:06, 8 feb 2016 (CET)

confl. La precisazione di Cpaolo non ha molto senso. "la proposta è di considerare verificate le modifiche di annullamento fatte da AV (o superiori)". Ma che proposta sarebbe? È già così! Un AV è un utente autoverificato, che ha tra i permessi autopatrol. Quindi un suo annullamento è verificato in automatico, come qualsiasi altro suo edit. Per il resto, ho spiegato mi pare a sufficienza perché va bene considerare come verificata una modifica annullata, quale che sia la natura ipotetica dell'annullamento, malevola o benevola. Un annullamento consiste nel togliere/mettere ciò che era stato messo/tolto. La necessità di verifica è sufficientemente espressa in uno solo dei due edit (l'adit annullato o l'edit che annulla): non ha senso pensare che verificare due edit che sono l'uno il semplice opposto dell'altro significhi essere più accurati. Significa solo pensare che qualsiasi pedanteria sia buona in sé stessa perché espressione di una indeterminata "precisione". pqd...Ƿƿ 16:09, 8 feb 2016 (CET)

[a capo] Ringrazio Cpaolo per la correzione della proposta, ma resta che la proposta, allo stato, è considerare verificata la modifica annullata, a prescindere da chi la annulla. A meno che non si spieghi perché dovremmo fare diversamente e si chiarisca perché non vale quanto ho spiegato della logica della proposta allo stato. :) pqd...Ƿƿ 18:39, 8 feb 2016 (CET)

Un ultimo dubbio. Nella stragrande maggioranza dei casi le modifiche sono annullate perché improprie. Tra queste, alcune richiedono l'intervento di un amministratore: una diffamazione, un copyviol o un altro caso fra quelli per i quali è previsto l'oscuramento. L'utente poco esperto, o il lettore di passaggio, sapranno certamente annullare la modifica - perché annullare una modifica è azione semplice e diffusa - ma possono non sapere che sarebbe pure opportuno segnalare quell'edit (o come farlo).

Le modifiche annullate sono spesso sciocchezze, ma a volte sono la feccia di wikipedia. Credo che un secondo controllo sia utile. --Harlock81 (msg) 19:17, 8 feb 2016 (CET)

Sono d'accordo con le premesse, ma non ho capito cosa ne discende. pqd...Ƿƿ 20:13, 8 feb 2016 (CET)

Mi par di capire che il sistema segnalerà in modo differente le modifiche verificate da quelle che non lo sono. In base a questa proposta, mi par di capire che se un IP rimuovesse un insulto, la sua versione sarebbe evidenziata in giallo (da verificare), la versione contenente l'insulto invece sarebbe in bianco (verificata). Non mi convince. Lo so, è un aggravio di lavoro in più verificare le due modifiche, ma personalmente lo preferisco. --Harlock81 (msg) 20:20, 8 feb 2016 (CET)

"evidenziata in giallo" riguarda ORES, intendeve dire che " ci sarebbe stato un !" davanti forse?--Alexmar983 (msg) 20:46, 8 feb 2016 (CET)

Quanto previsto dal punto 1, per qualunque cosa si opti. --Harlock81 (msg) 20:49, 8 feb 2016 (CET)

Quindi se passa questa l'annullamento di un AV/AP non resterebbe da verificare, e si perderebbe traccia di entrambi gli edit nel flusso di modifiche da scrutare giusto? In discussione ho espresso che è intrinsecamente scivoloso estendere la verifica di un edit a un altro (passare da 1 a N), anche nei casi si ritengono più ideali. Esempi ne vedete anche qui sulle crono da oscurare (come dice Harlock), l'ingarbugliamento di più edit (Updown) etc... cioè il caso di due edit perfettamente complementari fatto/annullato implica un sistema binario "perfetto" di cosa è giusto o sbagliato, oltre che la certezza che essi rappresentino un' "unità di lavoro" in sè... ma è così? Ho passato anni a vedere chiunque che chiedeva di segnalare classi di IP frequenti da bloccare, di mettere avvisi in talk affinché si potessero segnalare agli altri i problemi etc... sono informazioni utili per organizzarci collettivamnte, ricordare all'utente che annulla frettolosamente che c'è di più tutt'altro che marginale. Del resto AV non è un flag analitico ma si basa sulla "fiducia" no? Non c'è alcuna garanzia che chi lo ottenga abbia un minimo di esperenza di patrolling vera, chissà che ha fatto finora... insomma annullare bene è un'arte, ed è delicato per questo c'è un gruppo che sta sopra l'AV per farlo "più della media". Già è forzato pensare che chi sappia fare un edit buono sappia valutare buoni gli edit altrui, perché l'AV apre abbastanza anche a utenze brave ma con POV o un carattere non semplice. Però valutare positivamente il lavoro altrui è "proponitivo" non "punitivo", e noi siamo di fondo un sistema che incentiva l'aspetto "proponitivo", ma proprio per questo valutare "positivamente" un edit è ben altra storia che valutarlo "negativamente", storia che ci dovrebbe far pondrare bene ogni automatismo. Un AV che si è fatto "fiducia" con altre attività può benissimo eccedere annullando informazioni utili o creando una situazione di tensione proprio con chi bazzica molto meno da queste parti o non è registrato, marcando entrambi gli edit come verificati (l'annullato e l'annullamento dell'AV) si perde del tutto un'informazione che permette di risalir alla situazione e meno persone possono intervenire in "supporto" della "parte debole" (il non-AV) salvando il bambino buttato con acqua a volte nemmeno tanto sporca.

Sicuri quindi che gli AV non debbano essere ben controllati (anche se un po' di meno, ma tramite la verifica dell'edit prcedente) sul modo con cui annullano? Io questa sicurezza non ce l'ho. Che poi è individuando chi annulla bene che poi si segnalano i rollbacker migliori, no?--Alexmar983 (msg) 00:01, 9 feb 2016 (CET)

• Favorevole se può essere reso possibile ai soli utenti che possono verificare le modifiche (a prescindere da quale gruppo si sceglierà di assegnare tale funzione), cioè a coloro che vengono considerati in grado di valutare le modifiche altrui e di prendere eventuali provvedimenti (richiesta di oscuramento della modifica, intervento nella pagina di discussione dell'utente annullato, eccetera). --Fullerene (msg) 11:20, 9 feb 2016 (CET)
• Favorevole Ho fatto (mi è capitato anche prima di questa discussione) lo stesso ragionamento di Pequod --Horcrux_九十二 15:46, 12 feb 2016 (CET)
• Commento: ho letto questa discussione, e i commenti estesi sia di Alexmar che di Pequod, ma non riesco a capire in cosa si è concretizzata questa proposta. In sostanza, cosa si sta proponendo? -- Helichrysum Italicum ^{(chiamami "Heli")} 15:38, 27 feb 2016 (CET)

[@ Helichrysum Italicum] Data una modifica X annullata o rollbackata da una modifica Y, X verrebbe segnata automaticamente come verificata. Tutto qui. --Epìdosis 15:46, 27 feb 2016 (CET)

[@ Epìdosis] grazie. In linea di massima sono Favorevole solo nel caso in cui l'annullamento sia stato attuato da un AV. Ipotizzo si intenda che l'annullamento Y sia di quelli che lasciano X in cronologia, giusto? Che si propone di fare se l'annullamento Y coinvolge N modifiche consecutive? Anche in questo caso, le N modifiche risultano automaticamente verificate? -- Helichrysum Italicum ^{(chiamami "Heli")} 15:53, 27 feb 2016 (CET)

[@ Helichrysum Italicum] La proposta è legata alla pressione del tasto annulla: al momento pare non sia tecnicamente fattibile.

La proposta "minima" è che scatti solo se l'annulla è premuto da AV (e superiori), ma in realtà avrebbe senso per chiunque sia l'autore dell'annulla: infatti se un non AV annulla una modifica di un AV, non cambia nulla (la modifica dell'AV era per definizione già verificata), mentre se la modifica annullata era fatta da un non AV siamo nella situazione che quella modifica annullata di fatto è "scomparsa".

Per quanto riguarda gli annullamenti multipli, se fatti a mano (es.: ripristino una versione vecchia presa dalla cronologia) c'è poco da fare, il software non mi sembra sia attrezzato per riconoscere una simile azione; in caso di Rollback, pare che già ora le cose stiano così (eseguo il rollback tre edit => quei tre edit risulteranno verificati). --Cpaolo79 (msg) 08:45, 29 feb 2016 (CET)

Ma come si fa asserire che è "tecnicamente" impossibile? Quando programmavo in HTML, per farlo bastava che facessi un controllo aggiuntivo del testo iniziale e del testo inviato col sumbit, così se cambiava anche un solo carattere potevo fare tutte le azioni aggiuntive che ritenevo utili. Una cosa simile capita già adesso in Wikipedia quando si preme modifica una pagina e poi si vuole uscire senza salvare: se non si è cambiato nulla si esce subito, se si è cambiato anche un solo carattere compare un warning per avvertirti che se esci perdi tutte le modifiche. Provateci! --Skyfall (msg) 09:16, 29 feb 2016 (CET)

[@ Skyfall] "impossibile" nel senso che andrebbe modificato il codice e non abilitata una qualche funzione / script. Conosco bene le restanti spiegazioni perché programmo in HTML ;-). Comunque se ne è parlato qui. --Cpaolo79 (msg) 09:22, 29 feb 2016 (CET)

Discussione sul punto 5

Spostare il permesso patrol dagli autoconvalidati agli autoverificati

Si sono già espressi a favore [@ Nicolabel, Dimitrij Kasev, Etrusko25, Cpaolo79, Retaggio, Epìdosis]; contrario [@ Nemo bis]. --Epìdosis 13:36, 7 feb 2016 (CET)

Sono anch'io favorevole.--Cpaolo79 (msg) 20:43, 7 feb 2016 (CET)

I pro e i contro evidenziati dicono già tutto. Molto favorevole. --Supernino 10:14, 8 feb 2016 (CET)

• Estremamente Contrario Così si riduce parecchio il numero di utenti che possono patrollare, e quindi le modifiche non verificate; non vedo così tanti abusi da poter giustificare la decisione; dopotutto si tratta solo di segnalare se una modifica è vandalica oppure no (senza entrare nella qualità della stessa), quindi alla portata della gran parte degli utenti. Inoltre così si rischierebbe di disincentivare i potenziali patrollatori. --MarcoK (msg) 11:02, 8 feb 2016 (CET)
• Confermo il Favorevole --Retaggio (msg) 12:05, 8 feb 2016 (CET)
• Favorevole, ma preferibilmente ai rollbacker piuttosto che a tutti gli autoverificati: essere affidabili non significa essere in grado di prendere provvedimenti seri e necessari come la richiesta di oscuramento di una modifica, per questo serve avere un minimo di dimestichezza nel patrolling, capacità individuabile attualmente negli utenti appartenenti al gruppo dei rollbacker. --Fullerene (msg) 11:37, 9 feb 2016 (CET)
• Mi tolgo dai favorevoli perché penso che gli AV non sono di per sé un gruppo particolarmente deputato a fare una cosa del genere. Il punto della proposta è che "autoconvalidato" è uno status troppo "basso", anche se, a ben guardare, tantissimi utenti sono appunto semplicemente autoconvalidati. Il punto è che si diventa autoconvalidati dopo appena 4 giorni e 10 edit, ma l'eventuale passaggio successivo, autoverificato, si ottiene solo a particolari condizioni. Allora, se vogliamo individuare un gruppo di utenti che, in esclusiva (rispetto ai semplici autoconvalidati), possano segnare come verificate le modifiche, abbiamo due strade: a) farlo coincidere con gli AV; b) creare un nuovo gruppo (per esempio 6 mesi dal primo edit e 500 edit). Ci sono pro e contro in entrambe le ipotesi. pqd...Ƿƿ 23:34, 11 feb 2016 (CET)
• Commento: Sulla scorta della riflessione di Pequod ho fatto un test: dalle 21:50 alle 00:05 sono stati verificati 1000 edit: 997 da parte di utenti autoconvalidati autoverificati (o, più raramente admin) e appena tre da parte di utenti non autoconvalidati autoverificati (una di queste verifiche, tra l'altro era inutile). Per cui l'idea di caricarci di burocrazia creando un gruppo ad hoc mi sembra superflua. O riteniamo che vada bene lasciare le cose come sono oggi, lasciando mano libera agli autoconvalidati, o riteniamo che, vista la maggiore immediatezza dell'operazione assicurata dall'implementazione delle proposte 1 e 3, sia più prudente restringere questa facoltà ai soli autoverificati. Inventarci altre soluzioni mi pare invece inutile. --Nicolabel 00:30, 12 feb 2016 (CET)

  997 edit verificati da autoconvalidati?? Ammazza! Non da autoverificati, vero? Ho letto bene? Bisogna capire cosa ci serve: queste spunte sono di qualità? Perché in astratto ha ragione Marcok, se restringiamo la platea, ci sono ovviamente meno persone che si occupano di verificare. Ma se, d'altra parte, il tenore di queste verifiche è basso, allora tanto meglio che questi edit restino da verificare. Resta che manca coincidenza tra il tenore degli edit di cui ha parlato Xin in apertura di discussione e la verifica degli edit, che di norma è intesa come "attesto che non è un vandalismo". Quindi facile che un edit malevolo come quello del cabalista esecrando passa da queste maglie. Bisogna pensarci bene, isolando questa proposta in una discussione a parte, con una buona sintesi di partenza e segnalazione al bar. Cmq, per me il sistema ideale è proprio quello per cui ogni edit può venir "premiato" o "bocciato" un indefinito numero di volte. Non si tratta di mettere la spunta 100 volte alla correzione di un refuso: da quel lato continuiamo a vivere come adesso. Il punto è che una modifica controversa può essere considerata verificata solo quando viene spuntata tre, quattro volte. Passo di lì, vedo persino chi l'ha verificata e dico: a posto. Il "raggrumarsi" di valutazioni favorevoli ad un singolo edit dà anche indicazione per la fissazione di "punti di ripristino" in crono, altra ipotesi futuribile. pqd...Ƿƿ 01:20, 12 feb 2016 (CET)

  Ehm... mi sono confuso: il 99,7% delle verifiche è arrivato da autoverificati (o flag superiori) e appena lo 0,3% da autoconvalidati non autoverificati. --Nicolabel 08:55, 12 feb 2016 (CET)

  Eccellente! Ciò dimostra che non serve cambiare nulla. :) Nemo 11:17, 14 feb 2016 (CET)

  Ma davvero? Ciò dimostra invece che possiamo rendere la verifica "affidabile" senza perdere nulla. :-) --Retaggio (msg) 18:15, 14 feb 2016 (CET)

• Personalmente, non è che mi stanno "simpatici" gli AV (scherzo...). Il punto, imho, è che gli AV hanno comunque ricevuto una sorta di "patente di affidabilità" da parte della comunità. Questo a mio parere è il punto essenziale. Qualsiasi automatismo (anche dopo 5000 edit) mi dà certezza sulla conoscenza dei meccanismi wiki, ma non su altro. D'altra parte (mi ripeto) è anche un controsenso che per considerare le proprie modifiche "autoverificate" imponiamo un passaggio comunitario e poi per verificare le modifiche degli altri apriamo automaticamente a tutti. Al limite sarei più disponibile creare un nuovo gruppo, piuttosto che accettare l'automatismo (ma comunque non la considero un'ipotesi "conveniente"). Quanto al restringimento della platea, ricordo che al momento gli AV sono circa 1000... di cosa parliamo insomma? --Retaggio (msg) 10:27, 12 feb 2016 (CET) PS - Un altra cosa: le "spunte", le verifiche, ci servo tutte e nessuna è inutile: anche quelle sui refusi, perché riducono il numero dei "punti esclamativi" da controllare.

  Giusto come reminder, ricordiamo cosa dovrebbe fare un verificatore:

  edit riconosciuto come certamente vandalico/errato/POV/ecc... -----> Correzione(*) e spunta

  edit dubbio -----> segnalazione ad utente o progetto competente

  edit riconosciuto come certamente accettabile -----> spunta e via

  Per questo richiedo non necessariamente "competenza", ma certamente "affidabilità".

  (*) ed essendo l'AV già "AV" non abbiamo neanche il problema di verificare la correzione del verificatore

  --Retaggio (msg) 10:33, 12 feb 2016 (CET)

• A questo punto la proposta diventa: Spostare il permesso patrol dagli autoconvalidati agli autoverificati o creare un nuovo gruppo e di conseguenza si collega al punto 6 qua sotto. Riepilogando, possiamo arrivare a quattro soluzioni:

1. Assegnare il permesso "patrol" ai "soli" rollbacker. "Soli" tra virgolette perché ci sarebbero anche gli amministratori. PRO: utenti molto affidabili, prendo spunto da Retaggio qui sopra «non ci sarebbe il problema di verificare la correzione del verificatore». CONTRO: i rollbacker (e gli admin) sono in numero nettamente inferiore rispetto agli autoverificati, a causa di ciò il vantaggio di avere verifiche "sicure" «non compenserà il numero di chi può patrollare».
2. Assegnare il permesso "patrol" [anche] agli autoverificati [oltre che ai rollbacker]. PRO: utenti affidabili scelti dalla comunità, numericamente sarebbe un vantaggio poter assegnare anche a loro la funzione di verifica. CONTRO: c'è il dubbio di dover verificare anche le loro verifiche e quindi di dover verificare più volte anche uno stesso edit (vedi anche punto 7).
3. Creare un nuovo gruppo (dovrebbe essere "patroller") tra gli autoverificati e i rollbacker, avente il permesso "patrol" (condiviso con rollbacker e admin). PRO: i "patroller" sarebbero utenti affidabili ("più degli autoverificati, ma non quanto i rollbacker") scelti dalla comunità proprio per questa specifica funzione (patrollare/verificare le modifiche) = vantaggio di avere modifiche sicure. CONTRO: il permesso patrol si potrebbe assegnare anche agli autoverificati, (teoricamente) perdendo in sicurezza e senza avere altra burocrazia.
4. Lasciare il permesso "patrol" [anche] agli autoconvalidati. PRO: «[a toglierlo] si riduce parecchio il numero di utenti che possono patrollare, e quindi le modifiche non verificate; non vedo così tanti abusi da poter giustificare la decisione» CONTRO: qualunque utente, anche un vandalo, dopo 4 giorni e 10 edit può verificare le modifiche. --Dimitrij Kášëv 11:44, 12 feb 2016 (CET)

• Commento: Chiarito che, a quanto pare, sono proprio gli AV che per lo più si occupano di verificare, allora non è tanto pazzo dare a loro questa responsabilità di verificare (oltre che ad admin, burocrati, rollbacker, CU). Non perdiamo azioni "patrol" e siamo sicuri di affidarle a personale affidabile. pqd...Ƿƿ 13:22, 12 feb 2016 (CET)

Provo allora a fare sintesi: con l'eccezione di [@ Marcok, Nemo bis] (che invito però a leggere le statistiche riportate qui sopra, o eventualmente a rifarle in una fascia oraria più frequentata da utenti inesperti come ad es. quella pomeridiana) c'è consenso unanime sulla limitazione della funzione patrol ad autoverificati e flag superiori. Attenderei un paio di giorni dopodiché, in assenza di fatti nuovi potremmo dare per approvato il punto 5. --Nicolabel 14:57, 12 feb 2016 (CET)

• Favorevole al permesso di verificare per gli AV, quindi sulla soluzione 2 di Dimitrij Kasev. Sugli altri infatti: la 4, visto il test di Nicolabel, mi pare che si perda poco. La 1 al contrario vedrebbe pochi utenti che possono verificare, mentre la 3 mi pare una complicazione.--Kirk39 Dimmi! 18:36, 12 feb 2016 (CET)
• [@ Nicolabel] dal test hai escluso le modifiche autoverificate? 1000 verifiche in poco più di due ore mi sembrano un'esagerazione, a me sembra che siano molte meno e in buona parte fatte da amministratori o comunque patroller assodati. Per questo avevo suggerito di spostare la funzione ai rollbacker, in modo da avere una netta sicurezza sulla modifiche verificate e sui provvedimenti che ne devono seguire, al prezzo di avere solo poche modifiche in più da verificare. Ho preso un abbaglio? --Fullerene (msg) 01:06, 13 feb 2016 (CET)

  [@ Fullerene] temo che tu abbia ragione: mi sono limitato a scorrere la pagina speciale delle modifiche verificate senza distinguere tra verifiche vere e proprie ed edit di autoverificati. Resta il fatto che, se in due ore circa le verifiche da parte di non autoverificati sono state 3, siamo nell'ordine di 50-100 al giorno, un numero tutto sommato modesto da consentirci di prendere la decisione migliore senza preoccuparci troppo del calo potenziale di verifiche (IMHO mettere il link diretto in watchlist e/o tramite popup ne farebbe aumentare il numero in misura più significativa). --Nicolabel 19:24, 13 feb 2016 (CET)

• A questo punto, sono Favorevole alla proposta iniziale. Come detto da Retaggio, non perdiamo molto e blindiamo il meccanismo. pqd...Ƿƿ 18:52, 14 feb 2016 (CET)

• [@ Nicolabel, Fullerene]: ho fatto un'analisi più approfondita e da Speciale:Registri/patrol ho preso tutte le verifiche effettuate oggi dalle 00:00 alle 12:00 (metà giornata): ho rozzamente copiato in un file di testo a blocchi di 500 azioni alla volta e ho trovato un totale di 2973 verifiche.

Con un programmino ho filtrato le autoverifiche e ho messo insieme questi dati:

Risultati dell'analisi delle verifiche per il giorno 17 febbraio 2016

• Numero verifiche effettive: 218
• Verificatori: 38
  • Civvì: 1
  • Archimederoma: 1
  • Zack Tartufo: 1
  • Zombieontheroad: 4
  • YukioSanjo: 12
  • Syrio: 3
  • Kokky92: 1
  • Carlomorino: 1
  • Etrusko25: 3
  • Doc.mari: 1
  • X-Dark: 1
  • TintoMeches: 5
  • Leo45555: 42
  • Lucarosty: 1
  • Updown: 1
  • Jalo: 6
  • Phantomas: 1
  • Gierre: 4
  • Federico Leva (BEIC): 18
  • Pequod76: 2
  • RicoRico: 2
  • Epìdosis: 3
  • Baldersdod: 1
  • Pil56: 8
  • Beta16: 1
  • Ruthven: 1
  • Dimitrij Kasev: 23
  • Cpaolo79: 8
  • Vegetable: 23
  • %Pier%: 2
  • Jaqen: 3
  • Adigama: 1
  • Jeanambr: 1
  • DrQuantum: 1
  • Assianir: 1
  • DARIO SEVERI: 4
  • AttoRenato: 10
  • Carlomartini86: 16

Non ho avuto il tempo di controllare se tutti sono autoverificati, di certo qui non trovo Utente:Leo45555 che sembra il verificatore più attivo oggi. Avendo più tempo e strumenti migliori (non ho filtrato per namespace, ad esempio) possiamo fare controlli più approfonditi. --Cpaolo79 (msg) 14:05, 17 feb 2016 (CET)

Sono venuto a conoscenza della discussione perchè Cpaolo79 mi ha citato. Secondo me bisogna lasciare la possibilità di fare patrol anche agli utenti normali. Ovviamente io sono di parte, perchè non sono autoverificato. --Leo45555 (msg) 21:50, 17 feb 2016 (CET)

Visto il consenso e il tempo atteso, ho aperto questa discussione per concretizzare. --Fullerene (msg) 23:51, 26 feb 2016 (CET)

Perfetto. Dovremo anche aprire un'altra discussione per approfondire i punti rimasti in sospeso (2. e 4.). --Dimitrij Kášëv 23:59, 26 feb 2016 (CET)

arrivo in ritardo ma sono Favorevole a togliere agli autoconvalidati la possibilità di verificare le modifiche, lasciandolo a utenti dagli AV in su. -- Helichrysum Italicum ^{(chiamami "Heli")} 15:27, 27 feb 2016 (CET)

Discussione sul punto 6

Creare anche un gruppo "patrollatori"

Non fatto - proposta archiviata per clausola della palla di neve

Pareri sulla proposta

Si è già espresso a favore [@ Alexmar983]; contrari [@ Dimitrij Kasev, Cpaolo79]. --Epìdosis 13:36, 7 feb 2016 (CET)

Contrario la proposta può essere benissimo assorbita nella precedente: i rari casi in cui si volesse riconoscere a qualcuno la facoltà di verificare gli edit altrui e non i propri (o viceversa) non giustificano l'aggravio burocratico che deriverebbe dalla creazione di un ulteriore gruppo. --Nicolabel 21:44, 7 feb 2016 (CET)

si può avere una contrarietà basata su un ragionamento funzionale? Si possono fare tutti i composti di burocrazia della lingua italiana, ma non è una motivazione, e questo mi preoccupa, perché non esiste possibilità di mutuare nemmeno un apsetto di una proposta se si ritene con così grande certezza che sia dannosa o inutile. Eppure la necessità di stabilire una versione solida di una voce non è assorbibile nella precedente, sono ordini di lavoro abbastanza diversi, e non è un'esigenza nulla nel lavoro di controllo. Si tratta di un problema del resto con cui si confrontano altre edizioni e in nuce essa deriva da una constatazione di fondo che è tutt'altro che banale, cioè il prendere atto che il numero di edit da verificare con cognizione di causa è sempre da anni strutturalmente inferiore alle forze in gioco, non proprio una sciocchezzuola, perché è ciò che produce questa discussione. Per intenderci se gli edit da verificare e le risorse umane per verificarli fossero comparabili questa discussione nemmeno esisterebbe perché alla richiesta di avere più struttura al patrolling, fosse anche il flag di AV o di rollbacker, si direbbe che è quella un'aggravio burocratico. Difatti per anni lo si è detto in varie forme, a ogni passaggio relativo ai flag di patrolling questa motivazione della burocrazia per non approfondire è spuntata fuori come il prezzemolo. E dove siamo finiti? Qui, a parlarne comunque.

La frase "rari casi in cui si volesse riconoscere a qualcuno la facoltà di verificare gli edit altrui" suona poi alquanto strana... se si intende la possibilità di verificare edit non propri, questo non è un "raro caso", è "il caso" su cui è iniziata questa discussione. --Alexmar983 (msg) 00:18, 8 feb 2016 (CET)

Semplicemente ho letto la pagina, ho maturato un'idea e ho espresso la mia opinione: la tua proposta - IMHO - non è conveniente. Convengo con te sul fatto che occorra ridurre il tempo perso in discussioni infruttuose ed è perciò che ti prego di non annacquare questo momento in cui si sta cercando di fare sintesi dei 100 kB che l'anno preceduto. Per il resto, la mia talk è disponibile. --Nicolabel 00:29, 8 feb 2016 (CET)

c'è un punto su cui sono sempre stato cristallino: se si vuole la talk personale, si passa noi in primis in talk prsonale. Mi scrivi là, ti rispondo là... mi scrivi qui, ti sarà risposto qui. Tralasciando la seconda frase sui "rari casi" che mi rimane strana, ti faccio notare che "non è conveniente" è una motivazione funzionale (poi il tempo ci dirà se [non] conveniva), ma non è "è burocratica", hai detto una cosa diversa adesso. Fare una fila di due ore al comune per avere un documento è burocrazia ma alle volte ti conviene sul lungo periodo, dipende dal documento. Non so su cosa sta convenendo, io non riterrei mai infruttuose quelle discussioni. Posso ritnere infruttuosa una posizione, nel senso che è sterile e non dà frutti, mai la discussione. Discussioni dove decine di persone avevano scritto "burocra*" sono del resto tornate utili dopo mesi o anni.--Alexmar983 (msg) 01:14, 8 feb 2016 (CET)

Anch'io contrario; per me non ha molta utilità creare un nuovo gruppo di "patrollatori" quando esiste già un gruppo "autoverificati" che si vede tutte le proprie modifiche per l'appunto verificate. Se si temono abusi degli autoverificati, questi farebbero comunque prima a fare propri gli eventuali edit scorretti di terzi. --Supernino 10:14, 8 feb 2016 (CET)

perché forse tu intendi implicitamente mi pare in base ai tuoi commenti sopra che l'autoverificato abbia il patrol giusto? ok, anzitutto è un esempio di come dare il patrol agli autopatrolled senza accettare che abbiano un nome diverso renderà molto ambigue le discussioni future, come in parte accennato. Anche ammettendo questo fatto se come sembra si stabilisce che si valuta l'edit (e Pequod sembrerebbe averlo ribadito), l'autoverificato o patrollatore (AV con flag anche patrol) non può fare propri gli eventuali edit scorretti di terzi, se con questo si intende solo prendere un edit e riadattarlo, L'edit di terzo rimane da verificare a prescindere, chi è il patrollatore sul singolo edit lo deve approvare. Il che pone meglio in evidenza che se un edit ha errori ma cose buone da salvare bisognerebbe scegliere cosa fare e codificarlo bene. In teoria se il patrol è, come è, dell'edit singolo e non patrolla la versione allora devi annullare l'edit e poi aggiungere il materiale che salvi nel tuo edit autoverificato successivo. Altrimenti l'edit precedente che hai parzialmente riscritto e corretto rimane segnalato come non verificato. Oppure fai le modfiche che devi fare, salvi il tuo ma poi comunque autorizzi come verificato il precedente assumendo che per verificato tu intenda non "sostanzialmente corretto" ma appunto "processato". Il problema è che a questo punto per evitare che rimanga inevasa la verifica tu hai valutazioni contrastanti sugli edit al limite con alcuni contenuti buoni che correggi o che vedi qualcun altro correggere. Vanno annullatti e poi corretti o vanno approvati se poi li hai corretti con un edit successivo? La differenza di stile porta a back log diversi e a rendere non del tutto stabili le informazioni wikimetriche sulle utenze. Soprattutto è un esempio dei tanti di cosa significhi in pratica valutare l'edit o valutare la versione prodotta dagli edit precedenti. Non c'è un solo tipo di (retro)patrolling, quindi non può funzionare correttamente un solo tipo di flag patrol, che lo si intenda sull'edit o sulla versione. Anche se sembra "complicato" averne due, trattare insieme casistiche diverse sotto un solo ombrello non si rivelerà più "semplice" in molti dettagli.--Alexmar983 (msg) 13:08, 8 feb 2016 (CET)

Molto Contrario Si possono usare i gruppi che ci sono già, inutile complicare al vita a tutti. La possibilità di verificare una revisione dovrebbe rimanere a tutti gli utenti e non solo a un ristretto gruppo. --MarcoK (msg) 11:05, 8 feb 2016 (CET)

Tutta la discussione prima si basa sulla verifica delle modifiche singole, penso che tu indichi su quello per "revisione". In quanti modi si deve scrivere il concetto che non si deve fare confusione fra la modifica singola e versione? perché anche la versione può evere una "revisione". In altri termini "revisione" in sè è un sinonimo di patrolling ma torniamo qua, cosa si intende per patrollare/verificare/rvisionare? Singolo edit o versione? Una cosa è prendersi la responsabilità di dire che se ne sceglie una, ben altra è dirlo implicitamente sostenendo che un flag basato su uno dei due concetti è in "di più". Allora è "di più" perché usi solo l'altro concetto di revisione/patrolling etc (sull'edit) o è in "di più" perché hai in mente un modo di gestirli assieme?--Alexmar983 (msg) 13:08, 8 feb 2016 (CET)

• Contrario, complicazione inutile. --Retaggio (msg) 12:05, 8 feb 2016 (CET)

Discussione sul punto 7

consentire di poter verificare più volte ciascun edit, anche di autoverificati

Non fatto - proposta accantonata per assenza di consenso (e difficoltà tecniche)

Pareri sulla proposta

Si sono già espressi a favore [@ Pequod76] e, se ho interpretato bene, [@ Cpaolo79]. --Epìdosis 13:37, 7 feb 2016 (CET)

Credo di essermi spiegato male: [@ Rotpunkt] nel suo messaggio del 3 febbraio alle 20:21 ha scritto: "[Le modifiche non verificate] Più vecchie di un mese non penso tu possa averle verificate perché Speciale:UltimeModifiche conserva al massimo un mese". È quello che intendevo. --Cpaolo79 (msg) 20:43, 7 feb 2016 (CET)

tendenzialmente contrario: capisco la ratio, ma il bilancio costi-benefici mi sembra sfavorevole. --Nicolabel 21:46, 7 feb 2016 (CET)

Contrario Idem, bilancio costi-benefici sfavorevole. --MarcoK (msg) 11:04, 8 feb 2016 (CET)

• Incerto/a --Retaggio (msg) 12:05, 8 feb 2016 (CET)

Come Nicolabel. --Epìdosis 12:18, 8 feb 2016 (CET)

• Non sarebbe male. Anche però immaginando che sia facilissimo da ottenere, e quindi il costo stia solo nell'inserirlo nel flusso di lavoro in modo ottimale, prima di farlo si deve avere dei dati solidi su come va la verifica degli edit "singolarmente". Se già l'edit singolo fatica a trovare un revisore, e questo si vede dagli arretrati, non conviene puntare a un sistema che ha più di una revisione/valutazione. Solo allora, quando il resto dell'infrastruttura è chiara, si può approvare e bocciare per bilancio costi-benefici.--Alexmar983 (msg) 14:34, 8 feb 2016 (CET)
• Contrario La proposta va contro l'esistenza stessa del gruppo degli utenti autoverificati, se si pensa davvero che anche i contributi di questi utenti vadano verificati tanto vale abrogare direttamente il gruppo (cosa a cui sono contrario, oltretutto). --Gce ★★★+3 14:42, 8 feb 2016 (CET)
• Contrario, purtroppo abbiamo più voci da controllare che controllori --Bramfab Discorriamo 15:18, 8 feb 2016 (CET)
• Incerto/a Se la possibilità di verificare un edit è data solo agli utenti autoverificati vale quanto detto da Bramfab. Se invece rimane come è ora potrebbe costituire una formazione di consenso alternativa alla pagina di discussione, però può aiutare all'individuazione dei punti di ripristino nella cronologia. --Updown(msg) 16:21, 8 feb 2016 (CET)

  Penso che Bramfab abbia ragione. Il punto della proposta è però proprio quello individuato da Updown, cioè la definizione di punti di ripristino. Mi pare che esistano modi più lineari per farlo che non quello espresso dalla proposta. A conclusione di questo blocco di proposte operative propongo di discutere della cosa a parte. pqd...Ƿƿ 17:26, 8 feb 2016 (CET)

  sì ma i meccanismi di ripristino lineare o non, manuali o automatici possono convivere, anzi è più "solido" se lo fanno. Noto comunque che si fa anche qua confusione fra verifica edit e verifica versione. Potrà anche aiutare a individuare un punto di ripristino, ma allora deve essere una validazione della versione non dell'edit, altrimenti è un aiuto ambiguo. Indubbiamnte è una possibilità tecnica che varrebbe studiare come implementarla, perché comunque in diversi scenari o piattaforme aiuterebbe. Se uno c'ha voglia di perderci del tempo penso proprio che alla lunga non andrebbe sprecato. Difficile garantire qualcosa di più concreto.--Alexmar983 (msg) 01:46, 9 feb 2016 (CET)

[@ Alexmar983] Noi verifichiamo le versioni, in questo caso da verificare sarebbe una transizione reattiva che quindi non genera una nuova versione. L'ultimo stato utile della pagina rimane taggato come da verificare anche se passasse la proposta come è. --Updown(msg) 01:56, 9 feb 2016 (CET)

Updown cosa è une "transizione reattiva"? Se intendi che se verificassimo le versioni, una versione sucessiva a una verificata prodotta a edit verificati sarebbe verificata, è vero, io lo stesso l'ho fatto presente mi pare negli interventi precedenti... ma noi non verifichiamo le versioni, né abbiamo strumenti per verificare le versioni. Leggiti cosa ho scritto sopra sulla proposta 6 per esempio quando la gente parlava di "verifica edit" o di "modifiche" :D. deWiki lo fa con le Gesichtete Versionen, enWiki propose le Sighted versions ma fallì, noi no. d:Q11107170 non esiste su itwiki. Aiuto:Verifica delle modifiche parla solo della "differenza con la versione precedente", Aiuto:versione è solo un redirect a come scegliere una versione, non verificarla.--Alexmar983 (msg) 02:33, 9 feb 2016 (CET)

La transizione reattiva è l'annullamento, che percepiamo come passo in avanti nella crono, ma rappresenta un passo in dietro nella timeline degli stati della pagina. --Updown(msg) 12:34, 9 feb 2016 (CET)

• Come Nicolabel. --Dimitrij Kášëv 20:00, 8 feb 2016 (CET)
• Contrario come Gce. --Fullerene (msg) 01:36, 9 feb 2016 (CET)

Commento complessivo sulle proposte

Le obiezioni di Harlock alla proposta 4 mi sembrano ragionevoli, per cui sono anche d'accordo a lasciare perdere la proposta. Le osservazioni di Alexmar che seguono subito dopo pongono invece un problema su cui stavo riflettendo in queste ore, relativo alla proposta 5. In sostanza, stiamo spostando la possibilità di verificare dalla classe di utenti Autoconvalidati alla classe Autoverificati. Non solo, però, ci eravamo detti di non collegare l'identità AV ad altro che non fosse AV, ma stiamo tagliando fuori dal gioco, se mi passate l'espressione, un gran numero di utenti. La normalità è essere Autoconvalidati, non AV. Secondo me, per concludere questa discussione, che pone molte questioni insieme, dobbiamo approvare senza indugio le proposte 1 e 3, su cui siamo tutti d'accordo, e fare un supplemento di ragionamento, riflessione e discussione comunitaria per la proposta 5. Quanto alla proposta 4, anche questa merita un'ulteriore riflessione: soprattutto le osservazioni di Harlock fanno pensare che è più prudente lasciare perdere. In ogni caso, ripeto, distinguerei tra il blocco di proposte che sono certamente accettabili da altre più delicate. Meglio mettere un po' di polvere sotto al tappeto e ragionare ex novo su questioni di grande delicatezza (le proposte 1 e 3 non hanno questa delicatezza e sono immediatamente accettabili: hanno solo profili pratici). pqd...Ƿƿ 00:32, 9 feb 2016 (CET)

spero che la "1" sia chiaro esattamente per gli altri come si implementi (e che cosa si approvi) se un'opzione di preferenze o un cambio obbligatorio per tutti e come convive con l'informazione di ORES perché io non l'ho chiaro. Comunque di fondo la 1 e la 3 sono indubbiamente dettagli di interfaccia, quindi sono il "topolino" rispetto alla "montagna" (o "rivoluzione" che dir si voglia). Sono quindi Favorevole a stralciare e passare a discussione a parte per i dettagli. Avranno un qualche effetto per acelerare il patrolling, sarei stupito se bastasse a sanare il deficit strutturale che si segnalava in discussione, ma male non possono fare. Come ORES del resto.

Tutte le altre sottendono scelte più profonde di come si intende il lavoro e la natura delle utenze. Discussioni sui flag e classi di utenze anche più secondarie di queste, come noto a alcuni di voi, si svolgono e sono svolte già nelle scorse settimane, e continueranno. La comunità cerca e cercherà ancora il suo nuovo centro di gravità (semi)permanente sulla questione.--Alexmar983 (msg) 01:01, 9 feb 2016 (CET)

La proposta 2 (sapere chi ha verificato) viene percepita come un orpello, ma secondo me diventa molto utile se si decide di adottare la proposta 7 (verifiche multiple), che a sua volta deve essere definita meglio solo dopo aver discusso la proposta 5 (facoltà di verifica solo agli autoverificati). In merito alla proposta 4 (gli annullamenti verificano ma non sono verificati): quello che ci interessa è che non ci siano passaggi che cadano nel limbo o che evadano dal processo di verifica; il metodo proposto tenta di ottimizzare il lavoro lasciando traccia nella crono per un futuro controllo. Viene però dato per scontato per l'utente un metodo di verifica che tenga conto del nuovo metodo di lavoro, quindi anche questa proposta ha una forte dipendenza dalla proposta 5. --Updown(msg) 01:13, 9 feb 2016 (CET)

Non sento di essere molto d'accordo sul "stiamo tagliando fuori dal gioco [...] un gran numero di utenti" relativamente alla proposta 5: stiamo parlando di quasi 1000 utenti, eh! Poi non stiamo dicendo che gli altri li buttiamo nel cassonetto... stiamo solo dicendo che c'è un gruppo più ristretto (1000 utenti, ripeto) che, ritenuto "affidabile" dalla comunità, è abilitato a togliere gli esclamativi rossi oppure a segnalare ai progetti in casi dubbi. Non altro. --Retaggio (msg) 09:49, 9 feb 2016 (CET)

Piuttosto amaramente noto che la discussione ha raggiunto i 150 kb ed è praticamente incomprensibile a chi non ha ore da dedicare alla lettura di interventi spesso incomprensibili; io ormai ne ricordo solo l'inizio quando si diceva che fosse necessario fare innanzitutto una richiesta tecnica per poter implementare queste funzioni. Ora vedo che si sta facendo una moltitudine di proposte, significa che una volta "deciso" si avrà tutto subito funzionante o si sta parlando di "massimi sistemi"? --Pil56 (msg) 10:39, 9 feb 2016 (CET)

Pil, hai ragione: dovremmo fare tutti uno sforzo di sintesi e chiarezza. --Nicolabel 10:44, 9 feb 2016 (CET)

Come guida alla lettura credo che in prima battuta sia sufficiente leggere le sezioni riassunto per punti (solo primo edit) e questa (soprattutto gli editi di Pequod, Updown e Retaggio).

Consiglio in particolare il riassunto di Kasev: Wikipedia:Bar/Discussioni/Contributi_discutibili,_come_gestirli#Cosa_significa_verificare:_Riassunto. --Retaggio (msg) 10:47, 9 feb 2016 (CET)

I riassuntini li ho anche letti; la mia domanda "secca" è: ma se la proposta 1 (o la 2, o la 3 ecc.ecc) venisse accettata per acclamazione, da domani può essere messa in funzione? Diversamente la discussione è un po' fine a sé stessa. --Pil56 (msg) 11:01, 9 feb 2016 (CET)

[@ Pil56] Per l'appunto, ho chiesto di mettere in saccoccia i risultati relativi alle proposte 1 e 3, che, lo ricordo, sono rispettivamente:

1. evidenziare in qualche modo gli edit non verificati; sono già evidenziati da un punto esclamativo rosso in RC e in OS; inoltre, nei diff; si vuole aggiungere l'evidenziazione in crono; aggiungo io, guardando a phabricator (qui), anche questa richiesta: "it would be great if when viewing diffs, the unpatrolled status of the previous diff was visible — this would allow the reviewer to look at the previous diff only if it has not already been patrolled, while currently the reviewer has to look at the previous diff to know if it has been patrolled" (traduzione: "sarebbe ottimo se, controllando una diff, lo stato di non verificato della diff precedente fosse anch'esso visibile - ciò permetterebbe al revisore di controllare la diff precedente solo se non già patrollata, mentre ad oggi il revisore deve controllare la diff precedente per sapere se è stata patrollata"). L'altro pezzo di phabr contiene appunto la richiesta di evidenziare gli edit non verificati in crono. Se c'è la richiesta su phabr vuol dire che non è fantascienza.
2. patrollare tramite pop-up. (qui su phabr, a proposito di wikidata, ma una richiesta si può fare per altra piattaforma).

Su queste due proposte c'è accordo. Adesso qualcuno di noi che sa manovrare su phabr potrebbe recapitare questo consenso e fare richiesta. Sarebbe bello evidenziare gli edit non verificati anche in speciale:contribs. pqd...Ƿƿ 11:22, 9 feb 2016 (CET)

Concordo con [@ Pequod76] nel mettere agli atti le proposte 1 e 3, e riprendere subito e altrove i punti 4 e 5, altrimenti questa discussione diventa troppo dispersiva e inconcludente. --Fullerene (msg) 12:03, 9 feb 2016 (CET)

Segnalo Discussioni_progetto:Patrolling#Proposta_per_lo_spostamento_della_funzione_ad_un_altro_gruppo_utente da inserire nella futura discussione sul punto 5. --Updown(msg) 07:38, 11 feb 2016 (CET)

[@ Nemo bis] Ci aiuteresti a portare su phabr le proposte 1 e 3? pqd...Ƿƿ 19:29, 12 feb 2016 (CET)

Se mi fate domande fatemele in discussione, sono tornato da queste parti solo per caso. Il punto 1 era già segnalato, come detto da Rotpunkt, comunque ho riportato il risultato della discussione in phabricator:T31611#2026384 con alcune considerazioni e ho chiesto a uno sviluppatore di commentare. Quanto al punto 3 bisogna chiedere a chiunque sviluppi i popup. Nemo 10:52, 14 feb 2016 (CET)

Perché, il ping non ha funzionato? pqd...Ƿƿ 18:50, 14 feb 2016 (CET)

Io non lo uso. Nemo 16:09, 22 feb 2016 (CET)

PS: una volta conclusa, non sarà il caso di cambusare questa discussione in qualche talk di coordinamento? -- Helichrysum Italicum ^{(chiamami "Heli")} 15:29, 27 feb 2016 (CET)