Wikipedia:BarTUTTO

Da Wikipedia, l'enciclopedia libera.
Il bar di Wikipedia
«Le pagine di Wikipedia sono come i figli: una volta partoriti diventano figli del mondo» – Anonimo Wikipediano

Bar completo
Indice della settimana

Not Italian? It-0? Go to the Embassy Desk!
New message? Deutsch · English · Español · Français  |  Crystal 128 reload.png Aggiorna la pagina

Gnome-colors-list-add.svg Nuova discussione

Insert redirect.png Segnala discussione esterna

Benvenuti al bar di Wikipedia!
Benvenuti al bar di Wikipedia!
Cup-o-coffee-simple.svg

Il bar di Wikipedia è il luogo d'incontro e discussione dei wikipediani: qui si discutono argomenti di interesse generale per l'intero progetto. A tal proposito, tieni presente che:

  • il bar non nasce per risolvere conflitti; per isolare il problema e risolverlo in modo costruttivo è meglio aprire una richiesta di pareri
  • il bar non è il luogo giusto per promuovere o inserire collegamenti a procedure già molto promosse nelle pagine di servizio di Wikipedia, come voci in vetrina, voci di qualità, pagine da cancellare o elezioni di amministratori, salvo in casi inoppugnabilmente straordinari (es. cancellazioni di linee guida importanti o di template di servizio in uso per tutta Wikipedia); ricorda che molte di queste procedure sono già riportate su Il Wikipediano.

Il bar potrebbe tuttavia non essere il luogo più adatto dove porre la tua domanda: guarda dove fare una domanda per essere sicuro di ricevere la risposta più adeguata.

Discussioni in evidenza
Discussioni in evidenza

Qui sono segnalate le discussioni di interesse per tutta la comunità in corso al bar o altrove che proseguono da settimane o mesi:

Cambusa
Cambusa

Discussioni in corso
Discussioni in corso

Cerca nel Bar
Cerca nel Bar
Human-go-next.svg   

Altri luoghi dove cercare, chiedere, informarsi...
Altri luoghi dove cercare, chiedere, informarsi...
il Wikipediano il Wikipediano
Ultime notizie da it.wiki.
Domande più frequenti FAQ
Le domande più frequenti su Wikipedia.
Aiuto Aiuto
Istruzioni per l'uso di Wikipedia.
Dove chiedere Dove fare una domanda
Tutti i posti giusti dove chiedere qualcosa potendo confidare in una risposta.
Bar tematici Bar tematici
Discussioni su voci di argomenti specifici.
Embassy desk Embassy desk
Foreign visitors? Contact us!


1 febbraio

La figura del wikipediano ora riconosciuta in una norma UNI


Dal 28 gennaio, il "wikipediano" è una abilità/profilo professionale del web ufficialmente riconosciuta dalla norma multiparte UNI 11621-1/4: 2016 Attività professionali non regolamentate – Profili professionali per l'ICT [1]. Questo si deve al team italiano di IWA che ha base a Venezia, e in particolare a Luca Corsato, che ha proposto l'inserimento del "Wikipedian" tra i profili. È una bellissima notizia, anche perché siamo i primi in Europa a farlo. Cosa significa in pratica? Tanto per cominciare, che ora lo potete inserire nel vostro curriculum, e che le aziende d'ora in poi sapranno ufficialmente cosa vuol dire "wikipediano" (e wikipediano in residenza) e quali sono le sue (numerose) competenze. Niente male! Un grazie a Luca! --MarcoK (msg) 15:45, 1 feb 2016 (CET)

Fico :) --Supernino 16:23, 1 feb 2016 (CET)
Meglio che le aziende non lo sappiano http://voceditalia.it/articolo.asp?id=931 :) --Bultro (m) 17:07, 1 feb 2016 (CET)
LOL (per quello che ha scritto Bultro) (In effetti cosa conviene dire e cosa tacere in un colloquio, per un lavoro, alla domanda "Quali hobby ha?" è una questione molto complessa e di difficile determinazione).
Al di là della piacevolezza del riconoscimento, ma perché il cambio è così rilevante (al punto che la notizia non solo è bella ma bellissima)? Prima in un curriculum vitae il candidato non poteva scrivere di essere un Wikipediano? (Qualunque indicazione non prevista dalla norma UNI è vietata / viene ignorata?)
Prima (e tutt'ora) un Wikipediano poteva comunque scrivere di essere un enciclopedista, un volontario, un operatore culturale, erano tra quelli previsti? (Certo, tutte come abilità, attività. Non come professione).
P.S. E se un'azienda chiedesse un attestato / certificato che lo comprovi? --62.19.53.20 (msg) 17:57, 1 feb 2016 (CET)
il vero rischio è di avere un "donatore" di lavoro che ti "chiede", in barba all'etica Wikipediana, di creare la voce della ditta non enciclopedica per cui lavori ;).. --79.34.147.233 (msg) 18:04, 1 feb 2016 (CET)
Intanto grazie mille a MarcoK! È stato fatto un lavoro enorme di sintesi in realtà quello descritto è il Wikipediano in Residenza, ma si è scelto di chiamarlo semplicemente Wikipedian per non sembrare che possa essere una cosa diversa. Il profilo del Wikipedian l'ho compilato partendo proprio dalla tutela del progetto e abbiamo proprio creato la descrizione così: "Il Wikipedian, inquadrato all’interno di un Ente (sia pubblico che privato) o di un’Azienda, viene definito “Wikipediano in Residenza” [WP-01] e funge da collegamento tra la struttura “di residenza” e la comunità di Wikipedia (e/o degli altri progetti, come Wikimedia Commons, Wikisource o Wikidata), per promuovere una cooperazione reciprocamente vantaggiosa. All’interno della struttura in cui opera individua e valorizza i dati e i materiali utili alla crescita della comunità wikimediana, mettendoli a disposizione, verificando il punto di vista neutrale [WP-06], attraverso licenze aperte e incentivando il confronto tra le persone per il miglioramento dei contenuti al fine di aumentare la reputazione della struttura di residenza.". Ecco qua... per il resto non vedo l'ora di veder scritto nei cv "wikipediano". --lucacorsato 18:07, 2 feb 2016 (CET)
Qualcuno avverta però l'agenzia delle entrate che per il 99,99% dei wikipediani l'esserlo non dà reddito :) --Yoggysot (msg) 19:37, 1 feb 2016 (CET)
Oddio per me le ISO sono in generale dei motori generatori di carta ad uso e consumo degli ispettori qualità/ambiente.--Moroboshi scrivimi 20:07, 1 feb 2016 (CET)
Save a tree — disband an ISO Working Group today. --Tino [...] 11:59, 2 feb 2016 (CET)
[↓↑ fuori crono] Save a forest — disband all ISO Working Group today. Er Cicero sloggato. --188.217.108.74 (msg) 14:51, 3 feb 2016 (CET)

Ho aggiunto qui questa informazione. --Daniele Pugliesi (msg) 10:32, 3 feb 2016 (CET)

Incontri mensili a Bologna


Ciao a tutti. Dopo un paio di test, come gruppo di wiki(p|m)ediani a Bologna abbiamo istituito un incontro mensile aperto al pubblico. In questo modo pensiamo di aiutare chi avesse delle difficoltà a usare i progetti o semplicemente rispondere alle domande dei curiosi. Se volete passare a trovarci, o mandarci qualche amico che virtualmente non siete riusciti a convincere a partecipare al progetto, trovate le informazioni nella pagina del raduno. Buon lavoro. --Giuseppe (msg a baruneju) 20:39, 1 feb 2016 (CET)

l'idea è ottima, andrebbe copiata anche in altre città.. --79.34.147.233 (msg) 11:56, 2 feb 2016 (CET)


2 febbraio

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[non chiaro], 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.wikipedia.org/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)

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: [2], [3], [4])
  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: nessuno
    • 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 o rollbackate
    • Pro: si evita al patrollatore di dover compiere l'azione manualmente
    • Contro: nessuno
    • Fattibilità: ?
  5. Spostare il permesso patrol dagli autoconvalidati agli autoverificati
    • Pro: impedirebbe errori da parte di utenti inesperti o di utenti in malafede
    • Contro: meno modifiche verificate (ma anche meno errori)
    • Fattibilità: OK
  6. Creare anche un gruppo "patrollatori" che possano "sancire come verificata la versione data di una voce" (cit. Alexmar983)
    • Pro: risolverebbe gli accumuli di modifiche non verificate del passato
    • Contro: avvitamento burocratico?
    • Fattibilità: ?
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)

Avviata la seconda fase della verifica degli utenti attivi al Progetto Football americano (esterna)

Gnome-go-jump-right.svg

Questa è una discussione esterna (Che significa?)
Sintesi: È stata avviata la verifica degli utenti partecipanti al Progetto Football americano: se meno di 3 utenti manifesteranno interesse per il progetto allora esso sarà chiuso (ad oggi solo un utente lo ha fatto)..
La discussione prosegue in «Discussioni progetto:Sport/Football americano#Verifica utenti attivi». Segnalazione di Gce.

Corsivi nel testo


Mi è stata annullata una modifica su Bos taurus e i corsivi che avevo messo sono stati sostituiti da virgolette perché così direbbe il Manuale di stile. Non ho trovato il punto secondo cui per introdurre termini specifici come mucca, vitello ecc. non si debba usare il corsivo. Potete aiutarmi a capirci di più?--Carnby (msg) 23:36, 2 feb 2016 (CET)

"Mucca" e "vitello" sono nomi comuni, come "cane" e "gatto", e non vanno scritti in corsivo, il quale va utilizzato solo quando necessario e non quando non vietato. I nomi che vanno scritti in corsivo sono quelli scientifici dei generi, specie e sottospecie, come da Wikipedia:Convenzioni di stile/Forme di vita. Sull'utilizzo delle virgolette, vedi ad es. la prima frase del mio intervento. --Horcrux九十二 00:12, 3 feb 2016 (CET)
(confl) Puoi trovare le spiegazioni in proposito in Aiuto:Corsivo. (Per domande di questo genere, inoltre, sarebbe meglio scrivere direttamente in Aiuto:Sportello informazioni invece che al bar generalista.) --Tino [...] 00:14, 3 feb 2016 (CET)
[@ Tino] Oddio, in verità Aiuto:Corsivo mi sembra in contrasto con quanto ho detto sopra. Cosa significa "le suddivisioni tassonomiche superiori al genere nella forma latinizzata (sì Mammalia, no mammiferi)"? "Mammalia", anche dalla voce stessa, non va scritto in corsivo. --Horcrux九十二 00:31, 3 feb 2016 (CET)
Non avevo notato quel passaggio (anche se la risposta all'utente in questo caso non cambia). Direi che sarebbe opportuno uniformare le regole :-D --Tino [...] 06:55, 3 feb 2016 (CET)
Allora c'è una discrepanza tra il manuale di stile e l'uso dei linguisti, i quali usano solitamente il corsivo nel caso di uso metalinguistico, di spiegazione del termine. Per esempio: « [...] pieve deriva dal latino plebe(m), ‘volgo’; lo stesso termine latino ha dato per via dotta plebe». Notare anche l'uso delle virgolette alte scempie per esplicitare il significato.--Carnby (msg) 10:16, 3 feb 2016 (CET)
@Carnby: Quando_usare_il_corsivo: 6 Con i termini usati in funzione metalinguistica e le esemplificazioni linguistiche (es.: "Gli è l'articolo usato davanti a s impura: gli scogli"). E' previsto, ma e' necessario che sia chi edita e chi patrolla capisca la "funzione metalinguistica". --Bramfab Discorriamo 13:23, 3 feb 2016 (CET)
Non ho mai notato l'utilizzo del corsivo per tale fine, me ne scuso. Allora sarebbe da decidere fra corsivo e virgolette. Secondo la Treccani - Enciclopedia dell'Italiano la funzione metalinguistica spetterebbe alle virgolette. Per l'Accademia della Crusca e per la stessa Treccani, talora le virgolette sono sostituite dal corsivo quando si vogliono indicare citazioni brevi o parole straniere o dialettali (non mi sembra il nostro caso). La Treccani cita il testo Dardano, Maurizio & Trifone, Pietro, Grammatica italiana. Con nozioni di linguistica, Zanichelli, 1983. --Horcrux九十二 14:03, 3 feb 2016 (CET)
Per capire meglio il problema si faccia riferimento a Morbus anglicus di Arrigo Castellani («Studi linguistici italiani» 13-1987 pp. 137-153), e in particolare al primo capoverso di pagina 148.--Carnby (msg) 14:20, 3 feb 2016 (CET)
Chiamo [@ Pequod76] che solitamente di queste problematiche ne e' edotto. --Bramfab Discorriamo 14:31, 3 feb 2016 (CET)
Grazie Bramfab per il ping. [@ Carnby] Scusa, stiamo discutendo di tutto ma non della modifica in concreto. Dico quella che ti sarebbe stata annullata. Qual è? È importante vedere il diff per giudicare.
[@ Horcrux92] La fonte treccani non dice che "la funzione metalinguistica spetterebbe alle virgolette". Dice invece "la virgoletta può avere [funzione] metalinguistica". Converrai che è alquanto diverso. La verità è che c'è una diretta concorrenza tra virgolette e corsivo. A questo proposito vedi Serianni, I.228: "Normalmente in corsivo vanno le parole straniere o dialettali citate in un testo italiano [...] e così pure tutte le forme d'interesse linguistico" (cioè l'uso metalinguistico di cui si è detto). Più in generale bisogna capire che è insensato pensare di trovare UNA verità su questi fronti. Tutte le autorità discordano, WP dovrà fare la sua propria scelta. pqd...Ƿƿ 15:00, 3 feb 2016 (CET)
[@ Pequod76] Hai ragione, ho un po' travisato il senso, ma se mi parli di funzione metalinguistica delle virgolette e subito dopo parli della concorrenza col corsivo e non ne fai alcun cenno, la mia deduzione non è così campata per aria. Comunque è ovvio che si trovino opinioni discordanti su questo argomento. Ogni autore, per quanto autorevole possa essere, fa un utilizzo distinto delle virgolette e del corsivo in base a ciò che a sua volta gli è stato insegnato e in base a ciò che a sua volta ha studiato. Dov'è la verità? Non c'è, perché non ci sono ragioni particolari dietro tale scelta, ci sono solo tradizioni letterarie a cui far riferimento (o a cui l'autore che vogliamo scegliere ha fatto riferimento). --Horcrux九十二 15:22, 3 feb 2016 (CET)
P.S. La modifica in cui è stato aggiunto il corsivo è questa, mentre qui viene sostituito con le virgolette.
Scusa, non ho capito, a cosa non faccio alcun cenno? Quale tua deduzione?
I diff non funzionano... che data hanno? pqd...Ƿƿ 15:28, 3 feb 2016 (CET)
"Mi parli" era riferito all'autore del testo della Treccani ;-) Il senso è: prima dice che le virgolette hanno funzione metalinguistica, poi fa il confronto col corsivo e non accenna a tale funzione, ergo deduco (magari erroneamente, ma è ciò che ho dedotto) che il corsivo non viene usato con funzione metalinguistica. I diff a me funzionano... prova qui e qui. --Horcrux九十二 15:38, 3 feb 2016 (CET)
Ok, ho visto i diff. Non è semplicissimo, io terrei il corsivo. Peraltro mi pare giusto il rinvio alla questione degli apici, anche quello un uso metalinguistico, dove però non adottiamo il corsivo per esigenza di trasparenza (vedi l'esempio di pieve, che io nelle voci normalmente rendo così: da plebs, "volgo"). Altri casi di conflitto: negli incipit. Quando ad esempio l'incipit suona "Il termine X indica etc." Normalmente non definiamo flatus vocis ma enti a vario titolo. Eppure questa formulazione talvolta serve. In questi casi, dire "il termine X" pone X in funzione metalinguistica, poiché è individuato come termine. Senza voler andare a recuperare la previsione di aiuto:corsivo per cui i termini non vanno in corsivo (parliamo di terminologia, per chiarezza), evitare questi corsivi negli incipit serve ad evitare sovraccarichi grafici di dubbia utilità. In questi casi funzionano meglio (e mi sembrano doverose) le virgolette, perché isolano il termine individuato dal corpo dell'incipit e può essere pensato come un uso speciale. Assai difficile in generale trovare una formula che risolva coerentemente tutte le questioni: l'importante è cercare soluzioni per wp, non in base ad autorità inevitabilmente contraddittorie.pqd...Ƿƿ 15:43, 3 feb 2016 (CET)
L'uso delle virgolette alte per i significati è usato anche nel prestigioso libro di Oswald Szémerenyi Introduzione alla linguistica indeuropea; in generale però gli apici tipografici sono più comuni.--Carnby (msg) 23:20, 3 feb 2016 (CET)


3 febbraio

Come modificare la licenza di una immagine già caricata in Commons


Ho caricato alcune immagini in Commons. Si tratta di foto di dipinti, da me scattate, per le quali ho l'autorizzazione dell'autore delle opere per il loro inserimento in Wikipedia. Volevo utilizzare la licenza Creative Commons 4.0, invece per errore ho attribuito la 3.0, che consente l'utilizzo delle immagini anche a scopo commerciale. Vorrei sapere se è possibile modificare la licenza di ogni immagine, oppure come posso richiederne la cancellazione per ricaricarle con i dati corretti. Grazie.Questo commento senza la firma utente è stato inserito da StoArt (discussioni · contributi) .

Per caricarle su commons occorre comunque che si scelga una licenza che permette l'uso commerciale. Sia la CC 3.0 che la 4.0 hanno sia sottolicenze che permettono l'uso commerciale, sia che non lo permettono (queste ultime hanno le lettere "NC" nella sigla che le rappresenta, es CC-BY-NC-SA-3.0).
Se l'autore delle opere non era d'accordo con l'uso commerciale, e il caricamento è frutto di un fraintendimento, forse si può chiedere una cancellazione di cortesia (ma qui lascio la parola a chi è piu' pratico di me per le cancellazioni su commons). --Yoggysot (msg) 21:42, 3 feb 2016 (CET)
Ovviamente se qualcuno avesse già approfittato dell'immagine per utilizzi consentiti dalla CC 3.0 sarà impossibile richiedergliela indietro. --Bramfab Discorriamo 23:02, 3 feb 2016 (CET)
Aggiungo, StoArt, che a meno che tu sia un editore o uno studio legale è estremamente improbabile che restringere l'uso commerciale sia davvero ciò che desideri: per maggiori informazioni vedi m:Free_knowledge_based_on_Creative_Commons_licenses/it. Nemo 11:10, 4 feb 2016 (CET)
Ho controllato: si trattava di foto di opere di Enrico Bruno Novali, quindi il diritto d'autore sulle medesime non è nella disponibilità del fotografo a prescindere dalla licenza scelta. Le ho messe in cancellazione in Commons. L'autore delle opere dovrà seguire WP:CONCEDI. Nemo 11:13, 4 feb 2016 (CET)


4 febbraio

Richiesta pareri su collaborazione già attiva tra utenti di Wikipedia e Facebook


Già da più di un anno a questa parte, ho creato un gruppo su Facebook dove si informano gli iscritti al gruppo sulla creazione e il miglioramento di alcune voci di Wikipedia e chi vuole è invogliato a contribuire in maniera diretta (modificando le voci su Wikipedia) o indiretta (suggerendo correzioni da svolgere o fornendo informazioni su contenuti e fonti).
Il nome del gruppo in questione è "Alcamo su Wikipedia" e si occupa delle voci che riguardano nello specifico questa città.
A tale proposito, ho creato questa pagina: Utente:Daniele Pugliesi/Alcamo, che vorrei utilizzare principalmente per tenere traccia delle attività svolte e da svolgere, per ringraziare tutti coloro che partecipano alle attività del gruppo e per comunicare loro facilmente queste informazioni.
Riguardo alla pagina Utente:Daniele Pugliesi/Alcamo, chiedo il vostro parere per sapere se deve/può essere lasciata nel namespace utente (come una semplice pagina da consultare per gli iscritti al gruppo) oppure se deve/può essere spostata nel namespace:Progetto (eventualmente modificandola in qualche modo). Nel secondo caso, tengo a precisare che molti degli iscritti al gruppo non sanno come si usa Wikipedia e non sono interessati a collaborare direttamente, per cui la maggior parte delle discussioni resteranno sul gruppo Facebook o avverranno addirittura tramite email, per cui non so se si possa parlare di "Progetto" di Wikipedia nel vero senso del termine. Che ne dite? --Daniele Pugliesi (msg) 11:23, 4 feb 2016 (CET)

La presenza di gruppi wikipediani più o meno ufficiali su FB è cosa nota; ben venga se questi favoriscono in qualche modo la collaborazione o anche il semplice interesse di potenziali utenti. Se da un lato apprezzo i gruppi di informazione generale, che si limitano a comunicare iniziative o a spiegare caratteristiche particolari di WP, sono perplesso di fronte a gruppi che, come questo, sono assimilabili a "bar di progetto": un conto è discutere su queste pagine di argomenti pertinenti all'enciclopedia, un altro è farlo in altre sedi e poi riportare qui il lavoro (certo lodevole). Temo che possa creare un preteso per "richieste editoriali" come già succede in diverse sedi ("ho notato che la voce Xyz non è corretta, potete modificarla"). --Ghess-hu? (Indovina chi) 11:30, 4 feb 2016 (CET)
Quando arriva una richiesta di correzione di una voce, sono felice di accoglierla. Considera che quasi tutti gli iscritti al gruppo abitano ad Alcamo, per cui conoscono (chi più chi meno) le vicende presenti e passate della città.
Tornando alla domanda principale, la pagina Utente:Daniele Pugliesi/Alcamo va lasciata al titolo attuale o va spostata al namespace:Progetto? E se sì, sotto quali condizioni? --Daniele Pugliesi (msg) 13:48, 4 feb 2016 (CET)
Per creare un progetto ci sono precise modalità. E un progetto è «[...] un luogo di coordinamento tra utenti che discutono come gestire le informazioni di uno specifico ramo della conoscenza». Se ci sono utenti che lo creano e lo portano avanti, il progetto Alcamo è un progetto come gli altri; non si può quindi concepire che le decisioni prese in un gruppo esterno siano valide all'interno di wikipedia, dove le decisioni sono frutto del confronto fra utenti, né che qualcuno funga da portavoce per conto di altri. Utile sarebbe magari che chi ha imparato a usare fb impari ad usare wiki: il tuo gruppo fb potrebbe così essere veramente utile :D --AttoRenato le poilu 19:52, 4 feb 2016 (CET)
Attenzione: sul gruppo Facebook non viene presa alcuna decisione che riguardi Wikipedia. Tali decisioni infatti devono essere necessariamente svolte su Wikipedia stessa. Il gruppo Facebook ha invece lo scopo di raccogliere il materiale necessario per le voci e suggerire a chi ne ha voglia come si fa, attenendosi sempre alle linee guida di Wikipedia. Dunque l'unica cosa che potrebbe rimanere "nascosta" a causa dell'utilizzo di tale gruppo sono i contributi indiretti dei singoli partecipanti del gruppo. Per questo quando una voce è frutto del loro intervento, cito i loro nomi nella pagina di discussione della voce o in alcuni casi scrivo il ringraziamento nell'oggetto della modifica. --Daniele Pugliesi (msg) 22:00, 4 feb 2016 (CET)
[× Conflittato] Rispondo scrivendo su aspetti abbastanza differenti (su ognuno delle quali potrebbe forse essere utile aprire una discussione, magari più generale dello specifico caso su Alcamo su Wikipedia, caso specifico su cui non entro, anche perché la pagina su Facebook qui linkata non mi è visibile, Facebook mi chiede di registrarmi) :
  • Sarebbe interessante capire perché questi utenti di Facebook non migliorano direttamente loro le voci (visto anche che non serve registrarsi su Wikipedia e c'è un invito a farlo Wikipedia:Non aver paura di fare modifiche. Perché non sono interessati a collaborare, come è stato riferito? E non sanno come usarla, ma è così difficile da usare, perlomeno per le modifiche abbastanza semplici?). E ancor più sarebbe interessante capire (ma immagino sarebbe ancor più difficile avere informazioni) perché altre persone non modificano, quelle che non collaborano neppure indirettamente tramite quella pagina di Facebook.
  • La pagina Utente:Daniele Pugliesi/Alcamo se ho ben capito descrive come funziona il gruppo Facebook. Per cui più che in una pagina utente su Wikipedia o su una pagina progetto su Wikipedia, non dovrebbe stare su Facebook?
  • AttoRenato, però di progetti tematici che fanno da "raccordo" tra Wikipedia e altre realtà già ne abbiamo, ad esempio Progetto:GLAM e Progetto:WikiAfrica.
  • Che una persona abiti ad Alcamo non vuol necessariamente dire che abbia conoscenze sulla storia del luogo, né tanto meno che tali conoscenze si basino su fonti affidabili, verificabili, ecc. ecc. --62.19.43.30 (msg) 22:19, 4 feb 2016 (CET)

[ Rientro] @62.19 etc: Condivido alcune tue considerazioni, ma il parallelismo con Africa e GLAM è mal posto perché i progetti che citi sono ('anvedi ^_^)... progetti a tutti gli effetti. In entrambi i progetti (Progetto:GLAM/Come iniziare e Progetto:WikiAfrica/Contribuisci) si offrono del resto istruzioni su come collaborare a wikipedia - non prevedendo, ovvio, che chi voglia collaborare a wikipedia rimanga fuori da wikipedia. Nel caso nostro si tratterebbe di un progetto "raccordo" con un gruppo fb su Alcamo? :( --AttoRenato le poilu 23:50, 4 feb 2016 (CET)

  • Riguardo ai motivi per cui qualcuno preferisce collaborare in maniera indiretta anziché diretta, spesso viene detto che "non hanno voglia di farlo" o "non hanno tempo". Tali risposte ovviamente nascondono delle motivazioni più profonde, ma andare a chiedere quali sono queste motivazioni mi sembra un inutile atto di insistenza. Il mio parere personale è che la stragrande maggioranza, pur ritenendo Wikipedia utilissima, ritiene che i wikipediani siano "stupidi" perché svolgono un'attività non retribuita che invece dovrebbe esserlo, e la paura di potere essere considerati anche loro "stupidi" li scoraggia. Se fosse così, bisognerebbe fare una larga campagna di sensibilizzazione a favore del volontariato, spiegando i motivi per cui il volontariato è un'azione utile e nobile. Ciò non perché le persone non lo sanno, ma perché hanno bisogno di sapere che tutti lo sappiano. Il ragionamento può sembrare contorto, ma anche la mente umana lo è in fondo.
  • La pagina Utente:Daniele Pugliesi/Alcamo potrebbe diventare un modo per avvicinare piano piano i collaboratori su Wikipedia, nel senso che chi è interessato potrebbe iniziare a discutere qui su Wikipedia anziché su Facebook e così poco a poco si potrebbe costruire un vero e proprio progetto su Wikipedia. Inoltre il linguaggio wiki permette di scrivere la pagina in maniera più ordinata, con wikilink alle pagine di Wikipedia e ad altri siti, grassetti e corsivi, mentre su Facebook che io sappia i link vengono mostrati per esteso, rendendo più difficile la lettura del testo. Se è un problema, posso comunque inserire le informazioni direttamente su Facebook come suggerito.
  • Chi abita ad Alcamo nel 99% dei casi conoscerà di più la propria città rispetto a chi vive in un'altra città. Penso che per tutte le città valga lo stesso discorso. Ovviamente stiamo parlando nel caso in cui volessimo creare una voce di qualità medio-bassa. Se invece volessimo puntare a creare una voce qualitativamente superiore, si rende necessario il confronto con fonti autorevoli. Intanto però il grosso è stato fatto inserendo i contenuti della voce. Una volta che i contenuti ci sono, cercare le fonti è anche più semplice, proprio perché si sa cosa cercare. --Daniele Pugliesi (msg) 03:22, 5 feb 2016 (CET)
Rispondo a Daniele:
  1. restiamo sulla mancanza di voglia, perché se uno ci tiene/è interessato si iscrive, al massimo non lo dice a nessuno (dei miei amici lo sanno davvero in pochi che collaboro qua, alla fine sono fatti miei). Quindi se uno vuole contribuire lo fa, se non vuole è inutile tergiversare con gruppi Facebook o altro. Le voci sono di Wikipedia, questo è il posto deputato a discutere, proporre, correggere.
  2. a maggior ragione non ha senso il gruppo Facebook
  3. il discorso vale per tutte le città, ma anche argomenti diversi dalla geografia: l'obiettivo dovrebbe essere sempre e comunque la massima qualità, intesa non come scrivere solo voci da vetrina, ma contribuire con materiale che abbia fonti autorevoli, sennò è fuffa. Già adesso ci sono centinaia di voci senza fonti, se si incoraggia a contribuire "perché tanto è un punto di partenza", soprattutto quando lo scopo è formare nuove utenze, allora c'è qualcosa di sbagliato.
Quindi io dico: Tizio vuole collaborare? Lo fa su WP, da anonimo o da registrato a sua scelta, ma seguendo le nostre regole: non mi sta bene che la pigrizia venga in qualche modo incoraggiata, per un semplice fattore di comodo. Tizio conosce la storia di un monumento che non ha ancora una voce? Tizio la scrive, cercandosi le fonti: non chiede a Caio di scrivere quello che lui gli dice, tanto poi le fonti le trova qualcun altro. --Ghess-hu? (Indovina chi) 12:07, 5 feb 2016 (CET)
Il gruppo su Facebook funziona benissimo per i suoi scopi in quanto fa leva sul senso di "identità locale" da cui si può partire per motivare gli iscritti alla collaborazione. Consiglio a tutti di aprire un gruppo simile sulla propria città (a patto che sia continuamente seguito e aggiornato da almeno un wikipediano esperto in modo da rispettare le linee guida di Wikipedia).
La mia domanda qui è piuttosto rivolta alla pagina Utente:Daniele Pugliesi/Alcamo e sulla sua collocazione. Mi piacerebbe creare un progetto a tale proposito che riguardi tanti gruppi simili, ciascuno relativo ad una diversa città italiana. I tempi però mi sembrano ancora non maturi, per cui, sempre se non ci sono contrari, trasferisco tutte le informazioni importanti sul relativo gruppo di Facebook, lasciando la mia pagina utente per mia consultazione personale, come qualsiasi altra pagina utente. Continuerò a coordinare le attività sulla città di Alcamo. Ci sono ancora tante idee in cantiere che non sono state realizzate. Nel frattempo se qualcuno vuole aprire un gruppo simile sono disponibile a fornire suggerimenti. Ne riparliamo più in là se volete. Grazie per l'attenzione. --Daniele Pugliesi (msg) 14:06, 5 feb 2016 (CET)
Come ho già datto in passato, qusta sperimentazione è un esempio da citare, e sono favorevole a ogni intervento per "stabilizzarla". Non avrei avuto problemi a aprirne una simile anche io se non avessi una variabilità di luoghi troppo alta. Penso che per ora possa andare bene il namespace utente di chi "gestisce" il gruppo Facebook come luogo di interazione. L'unica specifica mi raccomando è di segnalarlo chiaramente alla home del progetto tematico competente.
A proposito, se vuoi segnalare anche al gruppo wikishootme pr crcare le immagini come ho già fatto io a tuo padre settimane fa, fai pure...--Alexmar983 (msg) 21:49, 5 feb 2016 (CET)
[@ Alexmar983] Grazie per la dritta. Lo strumento che hai segnalato non funziona a dovere: ho cercato nei pressi di Alcamo e compaiono tante pagine che hanno già immagini. Inoltre mio padre è da poco che contribuisce a Wikipedia e non so se ha già preso confidenza con Wikidata e Commons. Una cosa alla volta... --Daniele Pugliesi (msg) 08:42, 6 feb 2016 (CET)
è il senso della segnalazione, l'ho detto mentre lo descrivevo... Lo strumento funzionerebbe in sè, semplicemente mancano le immagini su wikidata. Si usa per trovare cosa manca e insieme togliere i falsi positivi sulle mancanze. Sono appunto lavori perfetti per un gruppo. Un utente da solo per sistemare una zona ci impiega tempo, più utenze molto meno. Se tutti si "rifutassero" di perfezionarlo non decollerebbe mai... essendo utile si segnala in massa e si confida che almeno qualcuno ci si metta. Grzie a Dio lo fa.--Alexmar983 (msg) 13:33, 6 feb 2016 (CET)
Perdonami, ma non ho capito neanch'io bene come funziona. Figuriamoci se lo capiscono gli iscritti al gruppo di Facebook, che in maggioranza non hanno mai editato su Wikipedia e a maggior ragione su Wikidata. Inoltre non si è ancora capito come viene gestito il gruppo su Facebook e questo mi dispiace moltissimo. O sono io che mi spiego male o quanto ho scritto è stato letto solo in parte. Il 99% degli iscritti al gruppo non svolge infatti alcuna modifica su Wikipedia e non ha intenzione di farlo. Semplicemente da una mano fornendo informazioni che poi io o mio padre e raramente qualcun altro aggiungiamo su Wikipedia. Molti altri si limitano a leggere gli articoli appena creati e a cliccare "mi piace". Queste attività sono già abbastanza utili e hanno dato ottimi risultati. Non voglio forzare nessuno a fare ciò che non vuole. --Daniele Pugliesi (msg) 14:01, 6 feb 2016 (CET)
Ti assicuro che il funzionamento del tool è stato chiaro a utenti che sono stati su wikipedia molto meno di te :D... C'è la foto su commons? Sì, la metti anche su data. Non c'è? Ok, la scatti o la cerchi e la metti su commons e poi su data. Ho sempre saputo che il gruppo non fa edit. Infatti mi aspettavo che si ripulisse dalle voci in cui le foto sono presenti (chi conosce il territorio e wikipedia fa molto prima di chi conosce solo wikipedia) e poi, fatto questo, si segnalasse al gruppo dicendo "mancano queste foto, intanto le potete scattare"? Poi le potevi trasferire pure tu. Non mi era mai sembrato una cosa complicata.--Alexmar983 (msg) 14:17, 6 feb 2016 (CET)
Prova a cercare "Alcamo" con il tool: spuntano tante voci dove le immagini già sono presenti. Inoltre nelle voci nuove sul territorio di Alcamo le immagini sono inserite al momento della creazione. Per tale motivo non lo trovo utile nell'ambito di tale gruppo, a prescindere dalla volontà e dalla capacità degli iscritti di utilizzarlo. --Daniele Pugliesi (msg) 14:46, 6 feb 2016 (CET)
"la metti anche su data" (cit.) Le foto possono essere inserite su Wikidata? Forse vuoi dire il link alla categoria su Commons? --Daniele Pugliesi (msg) 14:58, 6 feb 2016 (CET)
Ho visto adesso che su Wikidata esiste anche un parametro "image". Può essere utile ai fini dei progetti Wikimedia svolgere tali attività, ma indicare un'immagine su Wikidata dal punto di vista del gruppo "Alcamo su Wikipedia" mi sembra un'attività poco coinvolgente. Lasciamo i compiti noiosi a chi ha già esperienza su Wikipedia e che è già motivato. Chi non ha mai usato Wikipedia o ha iniziato ad usarla da poco ha invece bisogno di essere motivato con la scrittura di un pagina, anche un semplice abbozzo, che dà sicuramente più soddisfazioni. Inoltre nel gruppo "Alcamo su Wikipedia" è fondamentale inserire attività che non solo aiutino a conoscere Wikipedia ma anche a conoscere e apprezzare il territorio di Alcamo. La logica che ci sta sotto è: "Se ami il tuo territorio, conoscilo e fallo conoscere." --Daniele Pugliesi (msg) 15:17, 6 feb 2016 (CET)


5 febbraio

6 febbraio

Riferimenti all'Archivio storico del Corsera (esterna)

Gnome-go-jump-right.svg

Questa è una discussione esterna (Che significa?)
La discussione prosegue in «Wikipedia:Bar/Discussioni/Archivio_del_Corriere_della_Sera_a_pagamento:_che_si_fa%3F#Rimozioni_affrettate». Segnalazione di .mau..


7 febbraio