Discussioni aiuto:Decronizzare
Proposta
– Il cambusiere --Twice25 • (disc.) 00:20, 8 lug 2006 (CEST)
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)
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)- 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)
- 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)
- Dato che è la stessa cosa che vi supplico di fare per il bar da *settimane*.... l'ho fatto io.
- Bloccate Wikipedia:Recentchanges/archivioRichieste, la nuova pagina purgata è già attiva. --JollyRoger ۩ 17:09, 3 lug 2006 (CEST)
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)
- sottolineando di nuovo che la prossima volta che recupererete il bar andrete incontro all'orrore... --JollyRoger ۩ 17:12, 3 lug 2006 (CEST)
- 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)
- Vi ripeto che però, facendolo per il bar, si sballano le sottpaginazioni. --JollyRoger ۩ 17:41, 3 lug 2006 (CEST)
- 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)
Ok mi offro volontario per il processo di decronizzazione :P--Nick1915 - all you want 13:38, 8 lug 2006 (CEST)
Decronizzazione "impossibile" in ns0
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.
| Voce | Numero di edit |
|---|---|
| Associazione Calcio Milan | 3860 |
| Football Club Internazionale Milano | 3199 |
| Lista di italiani | 3030 |
| Napoli | 2912 |
| Associazione Sportiva Roma | 2826 |
| Società Sportiva Calcio Napoli | 2761 |
| Juventus Football Club | 2752 |
| Italia | 2647 |
| Madonna (cantante) | 2124 |
| Gesù | 2113 |
| Messina | 2063 |
| Nazionale di calcio dell'Italia | 2001 |
| Milano | 1940 |
| Silvio Berlusconi | 1873 |
| Bari | 1857 |
| Benito Mussolini | 1850 |
| Windows Vista | 1845 |
| Società Sportiva Lazio | 1843 |
| Palermo | 1822 |
| Papa Benedetto XVI | 1811 |
| Francesco Guccini | 1772 |
| Salento | 1747 |
| Genoa Cricket and Football Club | 1738 |
| Papa Giovanni Paolo II | 1735 |
| Torino | 1709 |
| Teresa di Lisieux | 1695 |
| Verona | 1645 |
| Sardegna | 1599 |
| Albania | 1591 |
| Attualità | 1584 |
| Unione Calcio Sampdoria | 1530 |
| Trieste | 1502 |
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)
- 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)
- 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)
- Il mio dubbio era proprio questo: se trasferiamo una crono in ns4 (Wikipedia) 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)
- È 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)
- 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 mentaliaggiunte non indispensabili all'enciclopedia. -- .mau. ✉ 09:21, 3 mar 2008 (CET)
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)
- 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)
- 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)
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)
- @ 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)
- 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)
- Se è per questo non sei l'unico. ;D -- Sannita - L'admin (a piede) libero 21:32, 3 mar 2008 (CET)
- 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)
- Imho si potrebbe creare una pagina Wikipedia: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)
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)
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)
- Calma. MediaWiki, come Wikipedia, è un progetto partecipativo, addirittura nato appositamente per Wikipedia. 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)
- 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)
- 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)
- Concordo con Yuma. Vedi qui: Associazione Calcio Milan ha ora 5197 versioni! Nemo 16:51, 1 ago 2008 (CEST)
- 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)
- 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. --Nemo 22:55, 1 ago 2008 (CEST)