Ieri mi sono trovato a ripristinare circa 3000 revisioni di una pagina (le richieste delle RC). Il recupero è andato a buon fine grazie al pulsantino revert ma... il db si è bloccato per alcuni minuti. É già la seconda volta che si sovraccarica per questo motivo (l'ultima volta è stato recuperando il bar). La mia proposta (riproposta) è di spostare in archivio le pagine pesanti (quelle che hanno una crono molto ampia) e bloccarle per scongiurare inserimenti poco graditi di copyviol ed evitare lavoro di manutenzione inutile.--Nick1915 - all you want 16:32, 3 lug 2006 (CEST)[rispondi]

Per quanto riguarda lo spostamento non ho nessuna obiezione. Ma il blocco no e poi no. Lo so che sono nuovo e direte "è il solito niubbazzo che vuole fare il grande", però io sono contrario ai blocchi sia parziali che totali se non in casi super-super-super estremi. E usare di questo strumento per un motivo così empio, beh mi sembra scorretto. --Ron Paul 16:51, 3 lug 2006 (CEST)[rispondi]

Scusate, ho scritto nel posto sbagliato (e per pura casualità il tema calzava un po'). Ricordate, mai troppi tab aperti. --Ron Paul 17:16, 3 lug 2006 (CEST)[rispondi]

Scusami ma che modifiche vorresti fare ad un archivio? Sono discussioni ferme e statiche e il blocco le rende immuni da copyviol: se non le blocchiamo allora tanto vale lasciarle dove sono... la vulnerabilità rimarrebbe uguale!--Nick1915 - all you want 16:55, 3 lug 2006 (CEST)[rispondi]

Dato che è la stessa cosa che vi supplico di fare per il bar da *settimane*.... l'ho fatto io.

Bloccate Teknopedia:Recentchanges/archivioRichieste, la nuova pagina purgata è già attiva. --JollyRoger ۩ 17:09, 3 lug 2006 (CEST)[rispondi]

Conflittato L'idea di Nick non è male. Temo che Ron Paul abbia capito male la proposta. Si tratta solo di congelare (bloccare) degli archivi di vecchie discussioni che, come tali, devono essere consultabili ma non hanno bisogno di essere editabili. --J B 17:10, 3 lug 2006 (CEST)[rispondi]

sottolineando di nuovo che la prossima volta che recupererete il bar andrete incontro all'orrore... --JollyRoger ۩ 17:12, 3 lug 2006 (CEST) [rispondi]

Suggerisco di farlo per pagine con + di mille modifiche; per le altre non credo ci siano problemi.--Ş€ņpãİ-27 - せんぱい scrivimi 17:26, 3 lug 2006 (CEST)[rispondi]

Vi ripeto che però, facendolo per il bar, si sballano le sottpaginazioni. --JollyRoger ۩ 17:41, 3 lug 2006 (CEST)[rispondi]

Ok mi offro volontario per il processo di decronizzazione :P--Nick1915 - all you want 13:38, 8 lug 2006 (CEST)[rispondi]

Leggo che la decronizzazione "si applica solo alle pagine esterne al namespace principale (quindi, non alle voci dell'enciclopedia) con oltre 1000 edit". Posso capire che, per quanto riguarda le voci in ns0, possa sussistere il problema di "dove mettere" la crono congelata. Tuttavia...

Tuttavia, basandomi sul dump di stats.wikimedia (aggiornato al 31/12/2007), ho steso questa lista di voci con più di 1.500 modifiche. Sono 32 in tutto, ma sicuramente negli ultimi due mesi altre voci avranno varcato il limite indicato.

Hanno sicuramente superato il limite anche Sicilia (che al 31/12/2007 aveva 1496 edit) e 2007 (che al 31/12/2007 aveva 1494 edit).

Nota bene: Gesù è l'unica aggiornata al 02/03/2008, perchè io e Piero Montesacro abbiamo effettuato un decron della voce il 5 novembre scorso, salvo poi ritornare sui nostri passi in seguito a segnalazione della deprecazione dei decron in ns0. Ad ogni modo, come per altri casi (Italia, Roma, Prostituzione, etc.) sono stati decronizzati i vandalismi e i copyviol.

Proprio la vicenda riguardante la voce Gesù mi fa riflettere su questa deprecazione. Davvero non si può trovare un posto dove parcheggiare le vecchie crono, almeno per le voci che hanno più di 1.500 edit? -- Sannita - L'admin (a piede) libero 20:11, 2 mar 2008 (CET)[rispondi]

proposta buttata lì: spostare la voce (quindi con tutta la cronologia) fuori dal NS0 e lasciare scritto sulla pagina di discussione dove si trovano le versioni vecchie? -- .mau. ✉ 20:35, 2 mar 2008 (CET)[rispondi]

Si potrebbe creare un namespece apposta per questo. Meglio ancora se lo facessero i dev, modificando direttamente il software. Il namespace potrebbe essere un namespace riservato (con un numero negativo). A questo punto le pagine potrebbero essere spostate perfino automaticamente dal software stesso.

Il probelma di questo metodo, così come in ogni caso se si sposta fuori dal ns0, è che a questo punto le vecchie versioni sono, appunto, fuori dal namespace principale (e ad esempio questo comporta che più inserite nei dump del database del solo namespace principale). A meno che non si aggiorna anche il metodo per fare i dump in modo da includere anche questo namespace speciale. -- AnyFile 22:19, 2 mar 2008 (CET)[rispondi]

Il mio dubbio era proprio questo: se trasferiamo una crono in ns4 (Teknopedia) o in qualsiasi altro ns≠0, automaticamente gli edit fatti in ns0 diventano in ns(*). D'altra parte, neppure possiamo creare delle sottopagine in ns0, che verrebbero considerate voci. -- Sannita - L'admin (a piede) libero 22:28, 2 mar 2008 (CET)[rispondi]

È davvero necessario decronizzare in ns0? Se sì perché? La crono in ns0 non è "sacra" (copyviol a parte, ovvio)? Kal - El 23:48, 2 mar 2008 (CET)[rispondi]

Appunto. Se mi si toglie degli edit in ns0, mi succede qualcosa di male? se il problema è sui requisiti di voto, basta aggiungere anche quei namespace al computo.

Dal mio punto di vista, la cronologia serve essenzialmente a due cose: (a) ottemperare alla GFDL - e per questo basterebbe addirittura avere anche solo la lista dei contributori, come abbiamo fatto ad esempio per la decaniattizzazione - e (b) avere una storia della voce che ci aiuti nel caso si scopra che c'è stata copyviol o altro. Tutto il resto sono seghe mentali aggiunte non indispensabili all'enciclopedia. -- .mau. ✉ 09:21, 3 mar 2008 (CET)[rispondi]

La decronizzazione potrebbe diventare preventiva: leggendo l'utlima wikizine si apprende che le pagine con più di 5000 versioni (nessuna su it.wiki al momento, almeno in ns0...) non possono più esser cancellate, a causa del troppo lavoro dei server che per tali operazioni subiscono rallentamenti notevoli. Ora, come dicevo, la decronizzazione potrebbe quindi diventare preventiva, nel senso che è forse meglio decronizzare voci come quelle indicate da Sannita prima che le stesse raggiungano la fatidica soglia dei 5000 edit, altrimenti nel caso di blasfemie, copyviol ed affini, la crono non potrà più essere ripulita. A meno di un intervento da parte di utente con diritti di oversight. Dove mettere la crono? Per me anche in ns4 con rimando in talk: la GFDL viene comunque ripsettata, e gli autori delle voci possono essere facilmente rintracciati. Un namespace dedicato è decisamente prematuro. --kiado 10:03, 3 mar 2008 (CET)[rispondi]

preferisco di gran lunga un namespace dedicato, il ns4 è già abusato (vedi vaglio che in realtà andrebbe fatto in una sottopagina della pagina di discussione della voce). --bonz ^{l'italiano è un'opinione} 10:59, 3 mar 2008 (CET)[rispondi]

Il numero di edit mi è relativamente indifferente (o meglio: viene dopo molte altre cose, perché di già che si lavora gratis molti altri riconoscimenti non se ne vedono :-)). Con i pattyviol devo avercene rimessi almeno qualche centinaio per esempio e va bene così. Piuttosto avere una cronologia "finta" (per esempio senza link alle pagine utente) come dice mau non può creare problemi superiori a quelli di averne una corposa? O dobbiamo iniziare davvero a preoccuparci - in quest'ottica di numero gravoso sui server di edit - di non correggere il classico refuso che si nota (dopo aver fatto 10 volte anteprima, naturalmente) mentre si sta salvando? Qualcuno mi dà una risposta chiara? Scusate voglio solo capire bene, nessuna polemica. Kal - El 13:10, 3 mar 2008 (CET)[rispondi]

Non capisco il problema, anche dopo aver letto la pag di aiuto. Nè dal punto di vista tecnico, nè da quello logico. Se si cancellano alcuni edit che problemi ne ha il DB? Se ci sono 10 100 o 1000 edit in crono che differenza fa? xchè dovrebbe essere "parcheggiata altrove" una porzione di crono delle voci? -- Scriban(msg) 13:32, 3 mar 2008 (CET)[rispondi]

@ Scriban: Come ha detto Kiado, "leggendo l'utlima wikizine si apprende che le pagine con più di 5000 versioni (nessuna su it.wiki al momento, almeno in ns0...) non possono più esser cancellate, a causa del troppo lavoro dei server che per tali operazioni subiscono rallentamenti notevoli. Ora, come dicevo, la decronizzazione potrebbe quindi diventare preventiva, nel senso che è forse meglio decronizzare voci come quelle indicate da Sannita prima che le stesse raggiungano la fatidica soglia dei 5000 edit, altrimenti nel caso di blasfemie, copyviol ed affini, la crono non potrà più essere ripulita".

Questo Kiado non l'ha detto, ma lo aggiungo io: la decronizzazione serve anche a tutelare la GFDL, ovvero la lista degli autori delle voci. Con la decronizzazione, la cronologia della voce fino ad una certa versione viene salvata e "congelata". Le modifiche si continuano a fare sulla voce principale, ma in caso di copyviol o altro non servirà recuperare 4.000 versioni, ma solo 100 o 200.

@ Kal-El: Per carità, nessuno sta dicendo che i typo non debbano più essere fatti. Anzi. Il problema è semplicemente dove piazzare le crono per rispettare la GFDL. Il problema non sussiste ancora, ma potrebbe verificarsi e "prevenire è meglio che curare". (cit.)-- Sannita - L'admin (a piede) libero 18:34, 3 mar 2008 (CET)[rispondi]

Chiaro: era una battuta iperbolica. Ho capito il problema tecnico. Posto che abilitare le sottopagine in ns0 è già stato bocciato più volte (per validi motivi) resta il problema (serio) di dove congelare queste cronologie. Io l'elenchino copiaincollato stile RC/pattyviol lo trovo inefficace, inadeguato e anche poco rispettoso dei contributi di utenti seri; d'altro canto trasferire in altri namespace non è nemmeno il massimo. Non ho le idee chiare (ok, si era capito :-)). Kal - El 19:08, 3 mar 2008 (CET)[rispondi]

Se è per questo non sei l'unico. ;D -- Sannita - L'admin (a piede) libero 21:32, 3 mar 2008 (CET)[rispondi]

Imho si potrebbe creare una pagina Teknopedia:Decronizzazioni e mettere le decronizzazioni come sue sottopagine, la pagina dovrebbe anche contenere i link (rossi) alle stesse (protette [create:sysop]) --Vito ^{You bought yourself a second chance} 22:08, 3 mar 2008 (CET)[rispondi]

Mi pare di aver capito che:

• la procedura di pulizia della crono, a livello sw, prevede la cancellazione totale della voce e della crono ed il "ripescamento" selettivo di tutti gli edit dal DB (eccetto quelli da cancellare).
• questa procedura è pesantissima (e te credo!). Imho è un problema di come viene gestito il DB, quindi di mediawiki, quindi dovrebbe essere imho gestito a livello dell'infrastruttura sw e non di quella dei contenuti in altre parole non sono c@**i nostri :-D
• Al "limite" ci arrivano prima (o ci sono già arrivate) altre Wiki. Lodevole il "prevenire" -sono d'accordissimo- ma forse, trattandosi appunto di un problema soprattutto sw e non di contenuti, starei alla finestra a vedere come risolvono le wiki + grandi.

Insomma, mi sbilancio: è un problema puramente informatico, quindi va risolto al livello informatico, senza toccare in nessun modo i contenuti. Se (e solo se) fosse impossibile far scalare il sw, quando sarà necessario, vedremo il da farsi. :-) -- Scriban(msg) 14:02, 4 mar 2008 (CET)[rispondi]

Anzi, aggiungo. È assolutamente fuori luogo e deprecabile inventarsi procedure e modalità senza un massiccio coordinamento con le altre wiki e con gli sviluppatori del sw. Non si può pensare che ogni xx.wiki vada per conto suo: aspettiamo tassativamente un coordinamento da parte di Wikimedia. -- Scriban(msg) 14:08, 4 mar 2008 (CET)[rispondi]

Calma. MediaWiki, come Teknopedia, è un progetto partecipativo, addirittura nato appositamente per Teknopedia. Quindi forse sono anche un po' cose che possono riguardarci e, sempre che si sia ferrati in materia (ad esempio io non lo sono), per le quali fare qualcosa, partecipando al progetto in questione. Comunque, la cancellazione selettiva è da tempo argomento di discussione sia su MediaWiki che su Bugzilla. A questo problema aggiungi pure che le voci crescono e i criceti nei server sono sempre quelli :-) Per il resto, WMF è la proprietaria dei server sui quali stiamo amabilmente discorrendo, e dal mio punto di vista se WMF dice: da domani non si possono più cancellare le voci con più di 5000 versioni, beh non resta che adattarsi a questa decisione. --kiado 14:34, 4 mar 2008 (CET)[rispondi]

Scusa, sono forse stato troppo assertivo... quel che voglio dire è che il problema mi pare sw, quindi imho va discusso sul piano del sw con le competenze tecniche di un gestore di database, e non sul piano di quelle "logiche" dell'orgaizzazione dei contenuti (o almeno, non ancora). Quanto ai criceti, dubito che siano sempre quelli... saranno stati aggiunti nuovi criceti man mano che i semi.. ahem... le voci crescevano. Infine, proprio perchè i crice... i server sono di WMF, è WMF che deve dire come gestire questo problema (allo stesso modo per tutte le wiki). Noi possiamo proporre a WMF una ipotesi ma mi guarderei molto bene dal metterla in pratica senza assenso esplicito di WMF. :-) -- Scriban(msg) 16:07, 4 mar 2008 (CET)[rispondi]

• Le voci più editate dovrebbero avere tutte un redirect o una disambigua 'sicuri'. Associazione Calcio Milan, ad esempio, ha un redirect Milan che non rischia certo di diventare orfano... Spostare la cronologia e avvisare in discussione che le vecchie versioni si trovano lì mi sembrerebbe assolutamente rispettoso della GNU FDL, mantenendo al tempo stesso i contributi nel namespace principale. Ovviamente da fare solo dove siamo in presenza di redirect o disambigue che non rischiano la cancellazione. --(Y) - parliamone 17:39, 5 mar 2008 (CET)[rispondi]

  Concordo con Yuma. Vedi qui: Associazione Calcio Milan ha ora 5197 versioni! Nemo 16:51, 1 ago 2008 (CEST)[rispondi]

Ma negli altri progetti fratelli, di WMF, come fanno? Non che dobbiamo fare per forza come loro, ma saperlo magaripuò essere utile per non ri-inventare l'acqua calda. --ChemicalBit - Cerchiamo di aumentare il rapporto segnale/rumore - (msg) 21:52, 1 ago 2008 (CEST)[rispondi]

Bah, non ho capito. In en.wiki se ne infischiano, ma a quanto ho capito loro non cancellano nemmeno le versioni con violazioni del diritto d'autore. Perciò leggo: «There is no need for such a page to ever be deleted». E spostano solo la Sandbox. D'altro canto qui sembra che gli steward siano autorizzati a cancellare queste pagine (dandosi momentaneamente i permessi da oversight, credo), perciò visto che ne abbiamo diversi il problema sembrerebbe meno grave. Resta comunque il problema della difficoltà delle cancellazioni selettive, se le pagine hanno una cronologia enorme e molte versioni cancellate. --Nemo 22:55, 1 ago 2008 (CEST)[rispondi]

Per la gestione delle revisioni cancellate, mi pare che la scelta adottata per alcune voci di 'cestinare' la crono infetta sia l'unica strada percorribile. Fino a una certa dimensione, può evitare il completo decron. --(Y) - parliamone 14:14, 2 ago 2008 (CEST)[rispondi]

Riprendo la discussione precedente alla luce di un problema tecnico verificatosi alla pagina Football Club Internazionale Milano, durante l'eliminazione di alcune versioni per copyviol. Essendo stato imposto un limite di 5000 revisioni oltre il quale una voce non può essere cancellata (potrebbe non essere possibile), inizia ad apparire un messaggio di errore:

Al momento la voce non ha ancora raggiunto la soglia delle 5000 rev; altre voci, quali Associazione Calcio Milan, le superano abbondantemente. Per ora il problema sembra saltuario, in alcune voci appare, in altre no; per evitare problemi quali perdite di revisioni, recuperi difficoltosi (già ora ci vogliono due minuti per cancellazione/recupero) o impossibilità di cancellazione e quindi permanenza di copyviol e vandalismi, suggerirei di decidere se e dove decronizzare voci del ns0. Per quel che mi riguarda utilizzerei una sottopagina della pagina di discussione; eventuali diatribe circa editcount e statistiche passano IMO in secondo piano alla luce di problemi di funzionamento. --Gliu 00:06, 13 feb 2009 (CET)[rispondi]

La decronizzazione del ns0 è già applicata in altri progetti? Il mio unico dubbio rimane quello della applicabilità per mantenere integra la GFDL, perchè spostare l'elenco degli autori dalla sezione apposita potrebbe non essere consentito (già spostare parte della crono in pagina di discussione come testo semplice è considerato violazione formale ma non sostanziale, ed in certi casi, seppur sconsigliato, viene adottata come procedura). Io, una volta stabilita la GFDL-compiliance, sono favorevolissimo a qualsiasi tecnica di decronizzazione. --FollowTheMedia ^usertalk  00:26, 13 feb 2009 (CET)[rispondi]

EDIT: Taluni su #wikipedia consigliano che, in mancanza del gruppo oversight, dovremmo contattare uno steward ogni volta che capita una violazione per rimuovere le singole revisioni. Infattibile imho. Intaseremmo di lavoro gli steward. :S --FollowTheMedia ^usertalk  00:39, 13 feb 2009 (CET)[rispondi]

Se proprio si vogliono evitare problemi con gli editcount si potrebbe sempre creare un redirect "farlocco" come Football Club Internazionale Milano (cronologia fino al 32 febbraio 2040)--Dr Zimbu (msg) 09:03, 13 feb 2009 (CET)[rispondi]

il problema non è l'edit count, è la licenza. concordo con Follow che la soluzione migliore sarebbe portare la figura dell'OS da noi, ma data l'importanza del ruolo si rischia di discutere (inutilmente) mesi sui requisiti minimi, aggravando ancora di molto l'attuale situazione delle voci con cronologia "piena". --valepert 10:14, 13 feb 2009 (CET)[rispondi]

la decronizzazione di fatto è uno spostamento, e si può effettivamente fare preservando la GFDL anche senza note nella pagina di discussione. sposti la voce a Football Club Internazionale Milano (cronologia fino al 32 febbraio 2040) con motivazione: decronizzata, la cronologia continua di là; poi fai copia e incolla del testo dell'ultima revisione dentro Football Club Internazionale Milano (che a questo punto ha 2 revisioni) e se vuoi trasformi Football Club Internazionale Milano (cronologia fino al 32 febbraio 2040) in un redirect. l'unica cosa da decidere è: 1) come chiamare la pagina destinazione dello spostamento; 2) se creare il redirect o meno.

Non bisogna neanche essere admin, al massimo si può poi chiedere a un admin di bloccare la pagina con la cronologia salvata. Per un esempio del risultato vedi qua (pagina vera) e (pagina con la cronologia). --bala^biot 10:50, 13 feb 2009 (CET)[rispondi]

Allo stato attuale non mi risulta che nessuna *.wikipedia adotti tecniche di separazione della cronologia sul namespace principale per problemi di licenza. Se proprio vogliamo procedere in questo modo, direi almeno di chiedere qualche parere su foundation-l prima di procedere. --FollowTheMedia ^usertalk  11:07, 13 feb 2009 (CET)[rispondi]

Problemi che non capisco... comunque il link "cronologia" non mostra tutte le revisioni: che differenza fa seguire un link che dice "mostra le prossime 50" o un link che dice "l'elenco delle revisioni continua qua"?!? --bala^biot 11:24, 13 feb 2009 (CET)[rispondi]

La GFDL obiettivamente è una licenza orripilante. Ho inviato una domanda alla mailing list della fondazione. Vediamo cosa mi rispondono. --FollowTheMedia ^usertalk  11:49, 13 feb 2009 (CET)[rispondi]

La proposta di balabiot e' ottima. Il redirect va messo, altrimenti significherebbe cancellare la nuova voce e addio cronologia. Jalo 12:57, 13 feb 2009 (CET)[rispondi]

Pare una proposta efficace anche a me quella di balabiot, sub judice eventuali dinieghi della Foundation (ma spero di no) ovviamente. Kal - El 13:02, 13 feb 2009 (CET)[rispondi]

Per ora mi è arrivato solo un no. --FollowTheMedia ^usertalk  13:05, 13 feb 2009 (CET)[rispondi]

(confl) Il problema principale è appunto il rischio di violare da soli la GFDL, per cui suggerisco cautela. Per il futuro se si imparasse a non fare 10 edit minimi quando ne basta uno un po' più grosso non sarebbe male. E per gli admin: se quando per qualsiasi motivo ripulire una crono ne approfittate per eliminare anche vandalismi e relativi rollback (con grande dolore dei malati di editcountite, ma nessun problema per la licenza) diventa poi più facile cestinare le revisioni brutte e cattive. --Jaqen [...] 13:12, 13 feb 2009 (CET)[rispondi]

Ma non ci credo che su en.wiki non hanno mai avuto il problema. La voce su Bush avra' decine di migliaia di modifiche. Loro come fanno? Jalo 14:10, 13 feb 2009 (CET)[rispondi]

hanno gli oversight, e non cancellano i copyvio. --bala^biot 14:30, 13 feb 2009 (CET) (la mia proposta in realtà è più o meno la stessa che c'è già in Aiuto:Decronizzare).[rispondi]

Mi sembra di capire dalla risposta data a Followthemedia che prima o poi daranno la possibilità di cancellare le singole revisioni, che permetteranno di aggirare il limite imposto di 5.000 revisioni. Ora:

1. 'sta storiella già ce l'hanno ammollata un anno fa <sarcasmo> e si vede che hanno mantenuto la parola </sarcasmo>;
2. i developer all'epoca non avevano le idee chiare, tanto che se ne uscirono con una funzione che era un ibrido fra oversight e cancellazione selettiva delle singole revisioni, buggata pesantemente e comunque in prospettiva da assegnare ai soli burocrati o addirittura ai soli steward.
3. gli stessi dev fecero "sottilmente" intendere che non consideravano la questione urgente, dal momento che soltanto noi italofoni richiedevamo la cancellazione delle singole revisioni - linkandoci tra l'altro m:Avoid copyright paranoia, che tradotto significa "Non rompeteci le scatole, state facendo casino per una questione da nulla"...

In attesa che venga accordata agli admin la possibilità di cancellare solo le revisioni "cattive", senza ricorrere alla cancellazione+ripristino selettivo, non posso che quotare Jaqen: meglio fare pochi edit corposi che 10/15/20 revisioni minime. E in caso di reiterati vandalismi, consiglio anche io agli amministratori di usare Teknopedia:Cestino per separare la cronologia "pulita" da quella "sporca". -- Sannita - L'admin (a piede) libero 16:24, 13 feb 2009 (CET)[rispondi]

In pagine così revisionate (aggiornate quotidianamente come quelle delle squadre di calcio) il cestino serve a poco. Abbiamo 59 modifiche cancellate su oltre 4500, poco più dell'1%. O si stabilisce di non rimuovere il materiale copyrighted, blasfemo e quant'altro, o è necessario trovare una soluzione. Spostare la crono in un redirect non è una cattiva idea. --Gliu 17:52, 13 feb 2009 (CET)[rispondi]

Il problema va risolto tecnicamente, e possibilmente non con soluzioni di ripiego. Attualmente la soluzione tecnica è ricorrere ad un utente oversight, che per it.Teknopedia vuol dire ricorrere ad un utente steward. Farlo è un problema e obera di lavoro gli steward? Speriamo che si rendano conto dell'importanza del problema anche i developer e facciano in modo che gli amministratori possano cancellare solo delle specifiche revisioni (senza dover cancellare tutto e poi ripristinarle solo alcune) , cosa che gli oversight possono già fare (e quindi non capisco più di tanto perché sia così diverso e complesso creare un istema per gli amministratori. Ora non è che m'immagino che basterebbe fare il copia-incolla del codice, però ...) --ChemicalBit (msg) 19:09, 13 feb 2009 (CET)[rispondi]

Tre considerazioni:

• La decisione di non adottare l'oversight (OS) risale alla fine del 2006. Possiamo riverificare il consenso ora che esiste un caso pratico di utilizzo. Le obiezioni dell'epoca erano in sintesi: 1)poca trasparenza/possibilità di abuso: le revisioni cancellate sono visibili solo agli OS 2)cancellazione quasi-permanente: le revisioni cancellate non sono recuperabili dagli OS, ma dai developer 3)supplemento di fiducia: l'assegnazione della funzione dovrebbe richiedere una votazione ad hoc. HIMO sono obiezioni superabili se la funzione viene affidata a seguito di votazione ad admin di esperienza (da almeno 1 o 2 anni in carica).
• Decronizzare non mi sembra una soluzione. Se una voce contiene un copyvio in crono ed, avendo più di 5000 revisioni, non è cancellabile, "splittare" la voce non permette in ogni caso la ripulitura della cronologia originaria (perché contiene sempre più di 5000 revisioni). Le revisioni affette da copyvio rimangono comunque accessibili perché - per ottemperare alla GFDL - la pagina di discussione della voce decronizzata deve permettere l'accesso alla cronologia originaria (tramite il template {{decron}} o un analogo di {{tradotto da}}). Si sposta (di poco) il problema complicando in compenso la cronistoria editoriale.
• Per quanto sopradetto, Aiuto:Decronizzare dovrebbe, a mio avviso, escludere esplicitamente le pagine non cancellabili (> 5000 revisioni) quando suggerisce la decronizzazione come metodo per facilitare la gestione dei copyvio in cronologie voluminose.

Pertanto l'OS mi sembra l'unica soluzione valida (sia tecnicamente che legalmente) al problema.--Nanae (msg) 20:22, 13 feb 2009 (CET)[rispondi]

2) possiamo usare l'OS per i casi particolari chiedendolo agli steward, e decronizzare preventivamente le pagine sopra le 4500 revisioni. 3) d'accordo. --bala^biot 20:54, 13 feb 2009 (CET)[rispondi]

1) L'oversight in realtà significa spostare su un altro database, e rendere visibili ai soli OS, le revisioni in oggetto. Il che significa che - Dio non voglia - in caso di errore poi dobbiamo scomodare Brion per farcele ridare. Anche per questo motivo, ero e resto contrario ad un oversight in caso di copyviol. Casomai, torniamo a far sentire la nostra voce per la cancellazione selettiva.

2) Concordo. Preciso comunque che, attualmente, esiste il template {{Voce decronizzata}} per i casi di crono spilittate (rintracciabili nel "Cestino").

3) Concordo. Possiamo anche aggiungere il pezzo.

Un'ultima cosa: più che decronizzare preventivamente le voci con più di 4mila revisioni, mantenendo i vandalismi ed eventuali copyviol, si potrebbero passare al setaccio e ripulire dai vandalismi. Certo, non sarà un lavoro facile. -- Sannita - L'admin (a piede) libero 21:05, 13 feb 2009 (CET)[rispondi]

ma il limite è di 5000 revisioni in totale, o di 5000 revisioni visibili? io avevo capito la prima e, se questo è il caso, c'è poco da setacciare... (riguardo l'oversight, per spiegarmi meglio io lo userei solo ed esclusivamente sulle voci che hanno un copyviol e più di 5000 revisioni già adesso. saranno 2/3 al massimo no?) --bala^biot 21:15, 13 feb 2009 (CET)[rispondi]

Humm... Sto guardando una voce a caso tra quelle in cui la crono raggiunge dimensioni 'abnormi' (Juventus Football Club), e noto una caratteristica che mi pare comune a queste 'crono-mostro': le sequenze di edit a nome dello stesso autore. Solo tra le ultime revisioni queste sono 14 revisioni consecutive di Mpiz; queste sono 10 di Danteilperuviano. Scorrendo a ritroso, le sequenze sono frequentissime, a gruppi di 8, 10, a volte anche 20 edit dello stesso autore. Se -per ipotesi- andassero perdute tutte le revisioni intermedie eccetto l'ultima, all'autore verrebbero comunque accreditate tutte le sue modifiche, ma con un unico edit invece che con 10/14. Nel rispetto più totale della GFDL, con la crono della voce che dimagrirebbe un bel po' (...anche gli edit count, ma si sa che i wikipediani sono generosi e disinteressati...). Che ne dite, è un azzardo? ;-) --(Y) - parliamone 23:58, 13 feb 2009 (CET)[rispondi]

Ci sono dei bei record! 29 revisioni per sistemare un paio di immagini! [1] --(Y) - parliamone 00:12, 14 feb 2009 (CET)[rispondi]

Questo azzardo mi piace, tanto i contributi, venendo semplicemente accorpati, restano integri. Certo è che sarà un bel lavoro per i sysop. :) --FollowTheMedia ^usertalk  01:36, 14 feb 2009 (CET)[rispondi]

(conflittato) Yuma, per me lo puoi fare in qualunque momento. Per il resto, semmai la cronologia andrebbe spostata a uno di questi (qualcuno ha letto la discussione precedente?). --Nemo 01:55, 14 feb 2009 (CET)[rispondi]

Ho fatto un test (... ovviamente è reversibile immediatamente al primo vagito di protesta...) su una voce poco 'rischiosa', ovvero la disambigua Attualità che possiede una lunga crono (essendo stata adibita a 'portale attualità'). Ho spulciato nella cronologia, eliminando vandalismi e relativi rollback ma anche edit consecutivi di uno stesso utente. Un lavoro noioso, ma alla fine la crono attuale è un terzo di quella originale, e ad ogni autore sono attribuite esattamente le proprie modifiche (solo con un numero minore di edit). --(Y) - parliamone 02:57, 14 feb 2009 (CET)[rispondi]

Vedo molte idee interessanti... E quoterei Yuma, di 5.000 e passa revisioni le possiamo tranquillamente accorpare ad un migliaio (e anche meno), non soltanto per quelle contigue di un unica utenza, ma per quelle dei bot, per le correzioni minime, (nessuno mai sbotterà se elimino una revisione dove si aggiungeva un unica virgola), i vandalismi stupidi, i vari POV e i vari RB... Dovremmo imparare a lasciare solo le modifiche utili, importanti, con pace dell'edincontite, ricordando che siamo in un enciclopedia.--AnjaManix (msg) 15:07, 14 feb 2009 (CET)[rispondi]

Sono assolutamente contrario alla parte << per le correzioni minime, (nessuno mai sbotterà se elimino una revisione dove si aggiungeva un unica virgola) >> perchè si tratta di un comportamento palesemente contrario alla licenza. So benissimo che sto facendo la figura del rompiscatole cronico ma, un conto è commettere occasionalmente degli errori umani che si traducono in una violazione della GFDL, un altro paio di maniche è far approvare una policy che prevede una sistematica violazione. Dopo voglio vedere con quale faccia riusciremo a pretendere che i riutilizzatori dei contenuti di Teknopedia (es: alcuni quotidiani) o anche solo i contributori rispettino la licenza quando noi siamo i primi ad ignorarla. Piuttosto è meno peggio la decronizzazione. Ma la vera domanda è: non possiamo chiedere che i devs ci abilitino la funzione RevisionDelete per tutti i sysop, che tra l'altro esiste già? --FollowTheMedia ^usertalk  16:33, 14 feb 2009 (CET)[rispondi]

Non ti preoccupare, il rompiscatole non sei tu:-)--AnjaManix (msg) 17:05, 14 feb 2009 (CET)[rispondi]

Al di là della questione della licenza, mi pare molto scomodo (e poco sicuro, in un progetto gesito e curato da volontari) adottare un metodo per fare il quale doveremmospulciarci le cronologie di alcune voci per ridurne il numero di revisioni.

Inoltre per ridurre il numero di revisioni bisognrebbe cancellarne alcune, cosa che attulmente va fatto cancellando tutte le revisioni e poi riprisinandone alcune (eventulmente spostandone alcune ad altra pagina, ecc. ecc. ma non approfondisco qui perché non è necessario), cosa che però non è già possiible con le voci che superano un numero tot di revisioni.

Il problema è strutturale e va risolto strutturalmente. --ChemicalBit (msg) 23:32, 14 feb 2009 (CET)[rispondi]

ribadisco la domanda: ma il limite è di 5000 revisioni in totale, o di 5000 revisioni visibili? io avevo capito la prima e, se questo è il caso, c'è poco da setacciare... --bala^biot 19:36, 15 feb 2009 (CET)[rispondi]

Credo che il limite sia di 5000 versioni nel database, e quindi non c'entra nulla se sono cancellate o meno. L'unica soluzione è spostarle in un'altra voce, ovvero decronizzare. Jalo 00:47, 16 feb 2009 (CET)[rispondi]

[rientro] @FollowTheMedia: e sono sei... :) RevisionDelete è il pasticcio di cui ho parlato più sopra, ovvero "un ibrido fra oversight e cancellazione selettiva delle singole revisioni, buggata pesantemente e comunque in prospettiva da assegnare ai soli burocrati o addirittura ai soli steward". La "RevisionDelete" che serve a noi è diversa e mi sa che facciamo prima a produrcela per i fatti nostri e proporla su BugZilla, così la accetteranno.

@Balabiot: ahimé, purtroppo la prima. Le 5mila revisioni si contano come visibili e cancellate. Anche per questo motivo, di solito, quando faccio una pulizia di crono approfondita, poi passo a splittare le cronologie... -- Sannita - L'admin (a piede) libero 00:50, 16 feb 2009 (CET)[rispondi]

Operazione, Jalo e Sannita, che attualmente non si può tecnicamente fare se la pagina ha già 5.000 revisioni (per "blocco" messo a protezione dall'appesantimento dei server) e che in pagine che hanno molte revisioni ma meno di 5.000 (es. 4.500) si può sì tecnicamente fare, ma a costo di affaticare parecchio i server, giusto? --ChemicalBit (msg) 10:25, 16 feb 2009 (CET)[rispondi]

Sì e no. Sì, nel senso che non si può fare con le pagine con +5.000 revisioni (motivo per cui un annetto fa aprii la discussione). No, nel senso che un'operazione di separazione della cronologia non è faticosa per i server, quanto per chi la fa. :) A parte il tedio di doversi spulciare revisione per revisione una voce, la procedura è anche un bel po' complessa perché prevede una serie di operazioni che vanno fatte nel giusto ordine e con la dovuta attenzione. -- Sannita - L'admin (a piede) libero 11:27, 16 feb 2009 (CET)[rispondi]

@Sannita: Ah ecco, tutto chiaro ora. L'unica via d'uscita, forse, è chiedere a uno steward di ripulire le cronologie troppo grosse (via oversight). A questo punto scenderebbero e di gran lunga sotto le 5000 revisioni. Continuo a ritenere la decronizzazione (preventiva, a 4000 revisioni o giù di lì) il male minore. --bala^biot 11:30, 16 feb 2009 (CET)[rispondi]

L'unica via d'uscita - lo ripeto ancora - è sviluppare noi una nuova "RevisionDelete" (cosa che, a detta di alcuni tecnici con cui ho parlato al raduno amiatino, è una cosa semplicissima da scrivere ed implementare) e proporla agli sviluppatori, dal momento che loro non hanno proprio voglia di impegnarsi a farla.

Per il resto, anche io sono d'accordo sulla decronizzazione di vandalismi e copyviol per le voci che sono sotto il limite di guardia. Talmente d'accordo che lo faccio già da mesi. :) Non sono d'accordo però sul rimuovere interi pacchi di edit validi di un utente, nel senso che ho dubbi sulla legittimità dell'operazione stando alla GFDL. -- Sannita - L'admin (a piede) libero 11:41, 16 feb 2009 (CET)[rispondi]

ah, e allora che stiamo a discutere? :-P --bala^biot 11:56, 16 feb 2009 (CET)[rispondi]

Non ho capito cosa si intende con "sviluppare noi una nuova "RevisionDelete"". Intendi dire di mettere mano al codice di MediaWiki? Jalo 12:20, 16 feb 2009 (CET) PS: Se ne hai parlato con me mi sa che l'hai fatto quando non ero in possesso delle mie facolta' mentali[rispondi]

L'idea di metter mano al codice è uscita fuori alla cena di sabato con gvf. Ad ogni modo, era puramente teorica e valeva solo per evidenziare il disinteresse degli sviluppatori. Poi se qualcuno capace riesce a metter mano al codice e a tirar fuori una proposta valida... ben venga. :) -- Sannita - L'admin (a piede) libero 12:35, 16 feb 2009 (CET)[rispondi]

Al momento le voci con piú di 4000 versioni sono solo Juventus Football Club, Napoli, Football Club Internazionale Milano, Italia, Associazione Calcio Milan: dato che non è mai stato deciso di vietare l'uso delle funzioni di Oversight in it.wiki, che io sappia, mentre è nostra regola di cancellare le versioni in violazione dei diritti d'autore (nostra, perché se ne può fare a meno), l'unica soluzione attuale per rispettare le nostre regole è, in questi casi eccezionali, chiedere a uno steward di nascondere le versioni in violazione, mi pare. --Nemo 15:23, 23 feb 2009 (CET)[rispondi]

Siamo sicuri che sia una procedura del tutto obsoleta? Non ci ho ragionato piú di tanto, ma non sono sicuro che sia tanto bello avere pagine come lo Sportello informazioni con decine di migliaia di versioni in cronologia. --Nemo 12:36, 30 mag 2010 (CEST)[rispondi]

E' stato un errore mio, intendevo obsoleta la decron relativa al NS0, per la quale vi è appunto il nuovo strumento. Tuttavia, come indicato da Sannita nella mia talk, anche quella può rimanere utile.--Marco 27 14:05, 30 mag 2010 (CEST)[rispondi]