Discussioni Wikisource:Bot

BotAdmin

Si necessita una votazione per possedere Bot che possano agire su pagine protette, ergo che abbiano lo status di Admin. Sono già sorte discussioni in proposito, anche sono non sono riuscito a ritrovarle. Cerchiamo quindi in questa sede di definire le regole.

• Pro e contro dei BotAdmin.
• Chi può eventualemente possedere un BotAdmin.
• Cosa può eventualmente fare un BotAdmin.

Aubrey 09:43, 30 ago 2006 (UTC)

Vado rapido ricordando ciò che ci siamo detti tempo fa. qui si trova la discussione.

• Su Source serve un bot che sia admin. A differenza di Pedia noi viviamo di testi bloccati. Con l'iPorkBot sono ammattito imbattendomi nei testi al 100%.
• Eravamo arrivati al punto di considerare i Bot una emanazione dell'utente che lo controlla. In questo la logica più corretta è permettere solo agli amministratori (che abbiano naturalmente conoscenza dello strumento) di gestire un bot admin. Lancio una proposta: se l'utente che gestisce un bot è amministratore di Wikisource, automaticamente tale bot viene flaggato come admin.
• Finalità del botadmin: le medesime del bot normale. Proprio per la nostra natura, ed avendo già usato un bot su Source, le operazioni che può compiere sono diverse ed il blocco delle pagine impedisce ogni genere di modifica.

Stabiliamo le norme, stiliamole e creiamo una pagina di aiuto così da procedere rapidamente. -- iPork → scrivimi 10:45, 30 ago 2006 (UTC)

<notatecnicanonrichiesta>È possibile fare in modo che il bot si logghi con l'account del suo proprietario e modifichi così le pagine protette. Questo ha il vantaggio di visualizzare nelle RC le modifiche potenzialmente pericolose. -- Pietro^Dn 15:20, 30 ago 2006 (UTC)</notatecnicanonrichiesta>

Dici una cosa corretta e ne parlavo proprio oggi con il Magister. Il punto principale è che per noi di Source i testi ambiscono a diventare protetti e con il passare del tempo saranno sempre di più. A differenza degli altri progetti, il blocco non è solo protettivo per fermare le edit-wars e affini ma è sopratutto l'ultima tappa del sistema di controllo della qualità. Per questo, dovendo ad esempio aggiornare le categorie (cosa che mi è capitata per quelle alfabetiche) su tutti i testi, se mi fossi loggato come iPork avrei intasato (a dir poco ^__^) la pagina delle ultime modifiche. -- iPork → scrivimi 16:37, 30 ago 2006 (UTC)

Allora è indispensabile sysoppare il bot. -- Pietro^Dn 07:32, 31 ago 2006 (UTC)

Eccomi!! Premesso che l'iperattività del bot umano iPork intasa le RC anche senza bot (e sia benedetto per questo), ecco i miei dieci eurocent. Ebbene mi rivelo nei miei sogni di onnipotenza: da mesi e mesi sogno di poter usare un bot: offline sto impazzendo per bene a formattare e sbavo d'invidia dietro le prodezze di Un1c0sBot... insomma avete capito. MA, c'è un ma: le mie conoscenze di Python sono pari a quelle di idrogeologia della fossa delle Marianne... zero. Non dubito che prima di sguinzagliare un bot farei fior di esperimenti, e comunque un bot va seguito come un bambino piccolo in una cristalleria, ma capisco che il fatto che io attualmente sia amministratore non garantisce automaticamente che il mio bot non faccia danni. Dunque, previo riconoscimento dell'operato del manovratore, io per default stabilirei un periodo di "rodaggio" dell'operato degli adminbot. Per quanto riguarda il nostro burocrate direi che il suo bot di rodaggio ne ha fatto più che a sufficienza per sysopparlo senza problemi, ma il giorno che altri bot popolino wikipedia per essi sia necessario una settimana di osservazione.

• Un bot con poteri di admin può essere posseduto solo da chi si occupi con altrettanta competenza di bot e di lavoro sporco (ricategorizzazioni, interwiki, modifica di template). Questo può essere facilmente rilevato dall'esame degli edit del manovratore. Ho formulato queste parole in modo che se un utente particolarmente capace e fidato non è admin ma ha un bot da tempo potrebbe occasionalmente aver bisogno di dare poteri di admin al proprio bot, ma è ipotesi peregrina: un utente particolarmente capace e fidato penso non rimanga utente semplice molto a lungo. Mentre per un manovratore admin non vedo troppi impedimenti a un bot admin (previo "allenamento" sopra esposto) al momento attuale non vedo ancora la necessità di bot con poteri di admin manovrati da utenti non admin.
• I compiti di un adminbot li può riferire meglio chi s'intende di bot meglio di me. --εΔω 23:32, 31 ago 2006 (UTC)

• Un criterio semplice per decidere di dare i poteri di bot-admin a un utente potrebbe essere fissare un certo tempo (un mese?) in cui viene testata la capacità e affidabilità nel fare i due compiti separatamente. Quindi, per esempio, se un amministratore (che è tale da più di un mese) "genera" un bot, questo diventerà botAdmin dopo un mese; viceversa se un utente che ha un bot diventa admin, anche il suo bot verrà "promosso" dopo un mese. Ovviamente nel periodo di testing l'utente deve fare un minimo valutabile.
• Per chi non è (e non è intenzionato a diventare) admin, si potrebbe "certificare" la sua admin-compatibilità, con una votazione identica a quella che per diventare admin. Con questa "certificazione" potrebbe avere il BotAdmin con lo stesso procedimento di un "vero" admin.
• Per le finalità del BotAdmin: almeno per adesso, anche per me vanno bene "le medesime del bot normale".
  Per il futuro, se ci fossero molti botAdmin e fosse difficile seguirli, forse è più sicuro che, per esempio, solo blocchino/sblocchino le pagine e poi i bot normali facciano il resto. Comunque ci si potrà pensare se e quando servirà --Qualc1 11:32, 1 set 2006 (UTC)

Si è aperto il concorso per scrivere decentemente le riflessioni da noi fatte in forma di policy... ^__^ Intanto procedo a flaggare il bot. -- iPork → scrivimi 07:44, 2 set 2006 (UTC)

Di nuovo sugli Admin-bot

Cari amici,

devo far partire una discussione delicata, e mi serve una certa presa di consenso: discutiamo di admin-bot.

• La precedente discussione, molto tempo fa, era iniziata qui, proseguita qui e conclusa qui. Negli ultimi cinque anni la situazione è cmbiata notevolmente.
• Il motivo di un adminbot era l'azione su pagine bloccate: oggi non è più così: si è preferito allentare il blocco, e questo già dice qualcosa sul cambio di orientamento riguardo al problema.
• nonostante la fiducia accordata per votazione ai manovratori, la diffidenza rispetto ad azioni potenzialmente pericolose eseguite invisibilmente dai bot non è una cretinata: se ThomasBot può crere inavvertitamente mille pagine più di quelle richiestegli, non penso che un pur sorvegliatissimo bot possa cancellarle senza pericolo di qualche errorino: sulle intemperanze e sugli imprevisti dei bot può raccontarci qualcosa anche Alex.
• A seguito della discussione sopra citata iPork ha dato accesso sysop al suo bot: oggi purtroppo non abbiamo solo un admin inattivo, ma anche un admin-bot inattivo. Può non importare e in effetti non è una colpa particolare, ma su altri progetti questa situazione non è minimamente ammessa.

Per completare lo scenario faccio presente che

• lo status di bot può essere accordato e revocato dal burocrate, ma lo status di admin una volta accordato dal burocrate può essere revocato solo da uno steward.
• Un admin in possesso di bot può agire da bot con il proprio account di admin, con la conseguenza che può comunque effettuare azioni admin a ritmo e quantità da bot, ma non invisibilmente.

Candalua mi ha chiesto di accordare lo status di admin a CandalBot per cancellare circa mille pagine create erroneamente da ThomasBot. Mi sono rifiutato, in quanto desidero prima avere una più aggiornata presa di consenso, dato che gli scenari che prefiguro sono i seguenti

1. Non solo allo stato attuale non si vogliono degli admin-bot, ma potrebbe essere giunto il momento di revocare lo satus di admin a Utente:iPorkBot
2. si vogliono degli admin-bot, ma non automaticamente, bensì dietro discussione, votazione ecc. ecc., vale a dire che la fiducia accordata all'admin non coincide necessariamente con quella accordata al suo bot
3. si vogliono degli admin-bot e si vuole evitare che gli admin compiano azioni admin di massa in maniera tale da intasare le ultime modifiche, e dunque si flaggano i loro bot.

Evidentemente io propendo per il primo scenario, ma se mi metto a discutere è perché non ritengo di avere la verità in tasca. Sotto con le riflessioni.

P.S. io ho proposto a Candalua di chiedere a uno steward (o su meta) che si accordi al suo bot dei diritti temporanei giusto per il tempo di cancellare quelle pagine... potrebbero esserci soluzioni? - εΔω 17:48, 22 mag 2011 (CEST)

• 

Già ora un bot, manovrato da un admin come me o Candalua, può "agire da admin"; quando il bot trova una situazione che richiede lo status di admin, chiede di agire con l'account del guidatore, e procede con l'account del guidatore. Lo svantaggio è che in quel momento il bot perde il suo status di bot e acquisisce quello di utente normale. La differenza riguarda unicamente:

1. l'assegnazione degli edit al guidatore (gli edit risulteranno fra i contributi utente del guidatore)
2. gli edit compaiono in Ultime Modifiche in mezzo alle altre degli utenti normali ("flooding"): per chi controlla Ultime Modifiche, un bel fastidio.

Nei progetti come il nostro, dove il controllo di Ultime Modifiche non deve essere paranoide perchè l'attività di eventuali trolls e vandali non è così pressante, il punto 2 non è così critico; inoltre, il guidatore può dare un'occhiata a Ultime Modifiche "ripulito" dei propri edit, e quindi il problema è superabile.

Candalua è utente eccezionalmente attento, e quindi la probabilità che combini "pasticci invisibili" è molto bassa; per quanto mi riguarda, io non chiederei mai un account sysop bot per me. --Alex brollo (disc.) 19:25, 22 mag 2011 (CEST)

LOL! Quando ho chiesto il flag, non mi aspettavo una risposta-fiume come questa... :-) quindi risponderò conciso: il "temporaneamente" mi sta bene. Vincerò la mia repulsione verso gli steward e chiederò su Meta. Oppure c'è un'altra soluzione: mi faccio una terza utenza, a cui dare i diritti di admin-bot, e da usare solo per le cancellazioni: poi finito il lavoro la blocco all'infinito, così siamo sicuri che non possono succedere malanni per sbaglio; e può tornare buona per future operazioni di pulizia ― in effetti questa è già la seconda volta, la prima volta ho fatto come suggerisce Alex cioè l'ho lanciato di notte, ma di notte avrei anche altre cose da fare :-) Anche per IPorkBot farei così: lo si blocca così siamo sicuri che nessuno può sgamargli la password e usarlo per fare danni, si lascia un cortese avviso ad IPork, e se un giorno torna può sbloccarlo e riprendere ad usarlo, senza scomodare i nostri gentiliiiiissimi steward...

ok, datemi del testardo, ma l'idea della terza utenza con ampi poteri e poi gettata nel cestino mi appare perversa: già le statistiche degli amministratori sono falsate dalla presenza di admin, bot e un adminbot inattivi; non ho alcuna intenzione di adeguare questa source agli standard di altri progetti con riconferme e altri psicodrammi consimili, ma nemmeno di ignorare che questi dati sono a livello globale non meno importanti del fatto che mille pagine in più sanno falsando le statistiche sulla trascrizione. E poi insomma, se per qualche ora le RC risulteranno inutilizzabili per l'imperversare di un admin cancellatore, vogliamo correre il rischio? io sì. - εΔω 15:57, 23 mag 2011 (CEST)

Capisco. Devo dire che semplicemente non mi ero mai posto il problema. Per me si può fare come dici. E magari, quello si, de-sysoppare qualche utente che sempicemente non c'è più. Ci scriviamo la policy e così ci adeguiamo un po' al resto dei progetti. --Aubrey McFato 16:42, 23 mag 2011 (CEST)

(Comunque, vedete piuttosto di darmi un feedback per questo... la storia dell'adminbot può anche aspettare) Candalùa (disc.) 23:20, 22 mag 2011 (CEST)

Admin-bot: altra discussione

In precedenti discussioni abbiamo provato a definire l'uso degli admin-bot come estensione dell'admin stesso ma con qualche difficoltà. Riassumendo: l'uso di bot con accesso a blocco e cancellazione è utile, ma

ARGOMENTI CONTRO

• 1. l'invisibilità dei bot nelle ultime modifiche non lo rende controllabile da tutti.
  2. anche nelle mani degli utenti più oculati un bot può andare fuori controllo
  3. come ogni utenza inattiva anche i dati di accesso di un'utenza bot possono essere rubati e usati da terzi con fini malevoli

ARGOMENTI A FAVORE

• Un bot può semiproteggere decine o centinaia di pagine validate
• Un bot non intasa le ultime modifiche

A me preme sapere se, senza dare a un bot l'accesso ad amministratore, un amministratore può manovrare il bot con il suo login: a me risulta di sì e questo è a mio parere un argomento definitivo per il bando degli admin-bot.

da quel che ricordo, si può fare, ma tu come utente non sei flaggato, per cui intasi le ultime modifiche. --Aubrey McFato 14:13, 5 set 2011 (CEST)

(Fuori crono) Dimenticavο un particolare importante: un burocrate può dare e revocare il flag di bot: se me lo chiede un admin può acquisire temporaneamente il flag di bot per il tempo strettamente necessario a compiere un'operazione di editing robotico.

In secondo luogo il titolo del post è quel che ne dovrebbe conseguire: il desysopping di iPorkBot è azione che va chiesta agli Steward e quindi richiede una votazione formale. - εΔω 13:02, 5 set 2011 (CEST)

+1: Io desysopperei tutti gli admin (non solo admin-bot) che non sono più attivi da oltre un anno.

Sottoscrivo inoltre l'obiezione di Aubrey. Chiunque può (anche se non dovrebbe) manovrare un bot, senza esserlo, con l'incoveniente di vedere le UltimeModifiche intasate. --Accurimbono (disc) 14:27, 5 set 2011 (CEST)

Accurimbono, Quello dei sysop inattivi è un capitolo più delicato che discuteremo a parte. Rimanendo in-topic, sul flood delle ultime modifiche ci eravamo già espressi in occasione della cancellazione di centinaia di pagine create per errore da ThomasBot (ehm... un caso non casuale). Io non ho percepito alcun lamento per quelle mezza giornata in cui le ultime modifiche hanno visto l'intervento di un admin ipercancellatore, e onestamente sono molto ben disposto a sostenere qualche momento di disagio per una enorme ondata di semiprotezioni iniziale dovuta al lavoro accumulato negli anni, che poi diverrebbe periodica e quindi accettabile una volta esauriti gli arretrati. Recentemente per un errore nello spostamento del bar ho dovuto cancellare almeno un centinaio di redirect, eppure nessuno mi ha fatto notare che non riusciva a gestire le ultime modifiche (che peraltro possono essere elencate fino a un numero di cinquemila). Credo che quello del flood delle ultime modifiche sia un disagio momentaneo e affrontabile a condizione di rendere successivamente le semiprotezioni un'operazione a periodicità abbastanza fitta.

Infine da come stiamo gestendo questa discussione deriverà la ricerca di consenso relativa ai bot globali.

Per favorire gli Steward che non sono tenuti a sapere l'italiano impostiamo una votazione formale εΔω 16:50, 5 set 2011 (CEST)

Tornando agli admin-bot: gli script pywikipedia richiedono di indicare, nelle impostazioni, l'utenza da usare come bot e l'utenza da usare per le operazioni da sysop (che di solito è l'utente "normale"). Se un bot ha anche il flag di amministratore, queste due utenze possono coincidere... ma non necessariamente! Anche se il bot ha il flag di sysop, per le operazioni da sysop non verrà usata l'utenza bot ma l'utenza sysop indicata nelle impostazioni! Ora, io sul mio pc posso avere 2 diverse installazioni di pywikipedia: su una imposto come utenza-sysop la mia utenza personale, sull'altra come utenza-sysop ci metto l'utenza bot. Ed uso questa seconda installazione solo esclusivamente per la protezione delle pagine. Questo significa che le uniche operazioni da sysop non visibili nelle ultime modifiche sarebbero le protezioni, mentre tutte le altre operazioni (cancellazioni, ecc.) rimangono visibili perché fatte con l'utenza normale. Quindi si può dare ad un bot lo status di admin, ma con la condizione di usarlo solo per certi compiti. Se poi questo admin bot corresse in automatico da toolserver, con la propria copia di pywikipedia, sarebbe estremamente improbabile che venisse usato "per sbaglio" per fare cose diverse dalle protezioni, dato che una volta lanciato non ci sarebbe più bisogno di interventi su di esso. L'unico punto debole del ragionamento è che bisogna comunque fidarsi che il manovratore non ne approfitti per i suoi loschi fini... ma questo mi sembra un'ipotesi ancora più remota, visto che già ora abbiamo dei bot ultrapotenti che se volessero potrebbero devastare facilmente mezza wiki, anche senza essere admin. (Spero che in tutto questo garbuglio ci abbiate capito qualcosa, io adesso vado a provare per controllare che sia proprio come ho detto! :-) Candalùa (disc.) 17:30, 5 set 2011 (CEST)

Sì, ho provato su vec dove ho un admin-bot ed è effettivamente così. Inoltre ho provato anche lo script protect.py e funziona. Una volta deciso se usare o no il flag di admin, sarei pronto a partire. Dato che la cosa funziona per categorie, indicatemi esattamente quali sono quelle con le pagine da proteggere, sia ns0 che Pagina (sicuramente è scritto da qualche parte ma a scanso di equivoci...) Candalùa (disc.) 19:04, 5 set 2011 (CEST)

Ottimo Candalua! Lo script protect.py è pubblico? Dove sta? Ciao, --Accurimbono (disc) 12:29, 6 set 2011 (CEST)

qui Candalùa (disc.) 12:34, 6 set 2011 (CEST)

Admin-bot: terza discussione

Riassumendo la questione degli admin-bot (discussione completa qui sopra):

1. Si è deciso tempo fa che testi e pagine portati al 100% devono essere semiprotetti per impedirne la modifica a anonimi o neoiscritti, che potrebbero, anche in buona fede, danneggiare le pagine.
2. Questo lavoro di protezione lo può fare benissimo un bot manovrato da un amministratore (senza andar lontano, mettiamo che sia il sottoscritto).
3. Le pagine che quotidianamente vengono rilette sono tante e (si spera) saranno sempre più in futuro, per cui si rischia di intasare le Ultime modifiche con tutte queste operazioni di protezione.
4. Un admin-bot, cioè un bot a cui decidiamo di dare poteri di amministratore, può svolgere questo compito silenziosamente, senza che la cosa appaia nelle Ultime modifiche.
5. Un admin-bot, se opportunamente configurato da un utente capace (supponiamo sempre -con molta modestia- che sia il sottoscritto), può agire in modo che solo le operazioni di protezione siano "invisibili", mentre tutte le altre operazioni (cancellazioni, blocchi, ecc.) siano effettuate con l'utenza del manovratore e rimangano perfettamente visibili nelle Ultime modifiche.

Quindi: sareste d'accordo ad estendere i miei poteri di amministratore anche a Utente:CandalBot con la clausola che vengano utilizzati esclusivamente per le operazioni di protezione? Candalùa (disc.) 13:03, 13 set 2011 (CEST)

• --Xavier121 14:08, 13 set 2011 (CEST)
• A ragion veduta (confrontando nei dettagli tecnici e nell'appropriatezza del linguaggio il pasticcione, anche se creativo, Alebot rispetto a CandalBot) --Alex brollo (disc.) 14:19, 14 set 2011 (CEST)
• - εΔω 16:37, 13 set 2011 (CEST) parliamone. Non sono pregiudizialmente contrario allo scenario che proponi e che mi pare ragionevole, ma distinguiamo discussione da votazione, e cerchiamo di porre dei limiti in modo tale che se la situazione si ripresenti questi costituiscano una linea guida condivisa.

Provo ad aggiungere un paio di clausole di sicurezza, sempre ricordando che il flag di bot è revocabile senza problemi, ma quello di admin deve essere revocato da uno steward e dunque la procedura è più lunga e delicata dato che gli steward si muovono solo dietro esplicitazione di un chiaro consenso locale.

• prima clausola: non abbiamo veramente bisogno di un admin-bot, si tratta più di una comodità che di una necessità, dunque un admin-bot deve essere manovrato da un amministratore attivo. L'inattività di un admin-bot per un periodo congruo (due mesi vanno bene?) gli fa perdere lo status di admin.
• seconda clausola: per facilitarne il controllo un admin-bot deve compiere solo operazioni per cui sia necessario il flag di admin, cioè solo le operazioni di semiprotezione (ma mi viene in mente la futura cancellazione di migliaia di pagine con includiInfotesto): le altre operazioni robotiche siano affidate a un altro bot anche se dello stesso manovratore.
• terza clausola: meglio eccedere con la burocrazia e passare ad una votazione formale. Ovviamente l'admin che manovra il bot deve essere utente altamente esperto e fidato, ma non basta: se io (amministratore di lungo corso, manovratore di bot ma incapace di manovrare decentemente un bot) decidessi di dare lo status di admin al mio bot basandomi sulla fiducia che mi è stata accordata compirei un pericoloso arbitrio — e infatti come riprova della fiducia che la comunità ripone in me mi guardo bene dal prendere tali decisioni —. Infine in generale è meglio che le promozioni ad amministratore siano sempre ben documentate. Possiamo scegliere un iter più breve o un sistema di silenzio assenso, ma non decidiamo tra un bicchiere di vino e una chiacchiera faceta.

Non pretendo di aver ragione su tutto, ma definiamo tutti i punti poco chiari. - εΔω 16:37, 13 set 2011 (CEST)

Nessuna obiezione sulle 3 clausole, farò un'utenza ad hoc che credo chiamerò ProtectoBot :-) Candalùa (disc.) 15:10, 14 set 2011 (CEST)

Admin-Bot: Ultima discussione

Cari amici,

Direi che siamo all'ultima puntata della vicenda, per cui andiamo alla ratifica finale: sarà ripetitiva ma desidero che partecipi il maggior numero di utenti possibile.

1. Recentemente abbiamo assistito alla cancellazione di massa di migliaia di pagine: spero che il "pericolo di inondazione delle RC" paventato precedentemente sia stato vissuto senza tutto il disagio che gli si attribuiva: con questo desidero chiedere conferma del fatto che un admin-bot evidentemente distinto da un bot comune e registrato ad hoc procederà solo alle semiprotezioni: le cancellazioni, anche quelle effettuate usando un bot, andranno effettuate con il nickname dell'admin e non del bot rimanendo così nelle ultime modifiche.
2. Non vogliamo admin-bot inattivi per abbandono: due mesi di inattività equivalgono alla neutralizzazione (desysop e deflag) del bot
3. Infine chiamatemi paranoico e burocrate: anche per il nuovo bot di Candalua chiedo una votazione formale. Facciamola durare una sola settimana con sistema di silenzio assenso, ma desidero che anche questo passo resti registrato e archiviato con tutti i crismi. Lo so, questo significa che vi sto chiedendo di esprimervi sia qui che in un secondo momento sullo stesso argomento ma portate pazienza, in realtà qui si sta decidendo di una linea guida, più avanti si deciderà di un'adminship.

Ora esprimetevi qui sotto, grazie. - εΔω 19:08, 7 ott 2011 (CEST)

• (con entusiasmo) Resta comunque aperta per casi particolari l'opzione inversa: assegnare temporaneamente (per il tempo strettamente necessario: anche poche ore) il flag di bot a un'utente sysop che sia anche bot-driver. Si otterrebbe la scomparsa di ogni modifica del sysop da UltimeModifiche, ma non ho idea se poi le modifiche ricomparirebbero in UltimeModifiche nel momento del de-flagging del temporaneo status di bot.... bisognerebbe provare. --Alex brollo (disc.) 01:32, 8 ott 2011 (CEST)
• --Xavier121 11:26, 8 ott 2011 (CEST)

Richiesta rimozione dalla tabella "Bot attivi" dei Bot non più attivi

Propongo che la tabella sia aggiornata per riflettere la situazione reale dei BOT flaggati, inoltre andrebbero rimossi i Bot che non sono più attivi, cioè quelli con zero edit negli ultimi 12 mesi. Di quelli attualmente presenti nella tabella i seguenti:

• Speciale:Contributi/AuBot 20:09, 19 mag 2011
• Speciale:Contributi/Bot-e 11:26, 20 gen 2011
• Speciale:Contributi/Cswikisource-bot 19:53, 10 gen 2012
• Speciale:Contributi/Interwiki-Bot 12:25, 5 mar 2011
• Speciale:Contributi/ScriboniusBot 02:14, 1 ott 2011
• Speciale:Contributi/555.bot 20:41, 26 dic 2008
• Speciale:Contributi/MenoBot 15:53, 29 giu 2013
• Speciale:Contributi/VolkovBot 14:26, 18 set 2010

Anche il mio Bot è da tempo inutilizzato e non andrebbe aggiunto all'elenco. Che ne dite? --Accurimbono (disc) 14:33, 4 apr 2015 (CEST)

Piuttosto che cancellarli dalla lista, forse sarebbe meglio metterli in una tabella "BOT inattivi", per ragioni di archivio. Se tornassero attivi possono sempre richiedere il flag e l'interimento in tabella. --Accurimbono (disc) 14:40, 4 apr 2015 (CEST)

• per la tabella "bot inattivi" Can da Lua (disc.) 10:36, 7 apr 2015 (CEST)
•  anzi, più mille: per noi burocrati avere un elenco serve per tener traccia di disattivazioni e riattivazioni. - εΔω 11:39, 7 apr 2015 (CEST)

Important: maintenance operation on September 1st

Leggi questo messaggio in un'altra lingua

Wikimedia Foundation sottoporrà a test il suo data center secondario. Lo scopo è accertarsi che Wikipedia e gli altri wiki Wikimedia riescano a rimanere online anche dopo un disastro. Al fine di garantire che tutto funzioni a dovere, il dipartimento tecnologico di Wikimedia ha bisogno di condurre un test programmato. Il test dimostrerà se è possibile passare da un data center all'altro in sicurezza. Diversi team si prepareranno per il test e saranno a disposizione per correggere qualsiasi problema imprevisto che si dovesse verificare.

Tutto il traffico sarà instradato sul data center secondario martedì 1º settembre.

Sfortunatamente, a causa di alcune limitazioni di MediaWiki, le attività di modifica saranno interrotte nel mentre. Ci scusiamo per il disagio, stiamo lavorando per minimizzarlo in futuro.

Sarai in grado di leggere, ma non di modificare, tutti i wiki per un breve periodo di tempo.

• Martedì 1º settembre non potrai effettuare modifiche per al massimo un'ora. Il test avrà inizio alle 14:00 UTC (15:00 BST, 16:00 CEST, 10:00 EDT, 19:30 IST, 07:00 PDT, 23:00 JST e 02:00 NZST di mercoledì 2 settembre in Nuova Zelanda).
• Se proverai a effettuare o pubblicare modifiche durante il suddetto orario, visualizzerai un messaggio di errore. Speriamo che nessuna modifica venga persa durante questi pochi minuti, ma non possiamo garantirlo. Se visualizzi il messaggio di errore, attendi fino a che tutto non torni alla normalità. Da quel momento in poi potrai salvare di nuovo le tue modifiche. Per ogni eventualità, ti suggeriamo comunque di farne prima una copia.

Altre conseguenze:

• I processi in background saranno più lenti e alcuni potrebbero interrompersi. I link rossi potrebbero non essere aggiornati con la solita velocità. Se crei una voce per cui esiste già un link entrante a partire da un'altra voce, il collegamento rimarrà rosso più a lungo del solito. Alcuni script in esecuzione da molto tempo dovranno essere fermati.
• Ci sarà un congelamento del codice di MediaWiki durante la settimana del 1º settembre 2020. Tutti gli aggiornamenti non essenziali del codice di MediaWiki non avranno luogo.

Questo progetto potrebbe essere posticipato se necessario. Puoi consultare la tabella di marcia su wikitech.wikimedia.org. Ogni cambiamento sarà annunciato nella tabella di marcia. Ci saranno ulteriori avvisi riguardo a questo test. Per favore, condividi queste informazioni con la tua comunità.

User:Trizek (WMF) (talk) 12:30, 31 ago 2020 (CEST)

Important: maintenance operation on October 27

Aiutaci a tradurre nella tua lingua Grazie.

This is a reminder of a message already sent to your wiki.

On Tuesday, October 27 2020, all wikis will be in read-only mode for a short period of time.

You will not be able to edit for up to an hour on Tuesday, October 27. The test will start at 14:00 UTC (14:00 WET, 15:00 CET, 10:00 EDT, 19:30 IST, 07:00 PDT, 23:00 JST, and in New Zealand at 03:00 NZDT on Wednesday October 28).

Background jobs will be slower and some may be dropped. This may have an impact on some bots work.

Know more about this operation.

-- User:Trizek (WMF) (talk) 10:25, 26 ott 2020 (CET)

Server switch

Leggi questo messaggio in un'altra lingua • Aiutaci a tradurre nella tua lingua

Wikimedia Foundation sta effettuando test di passaggio tra il suo data center primario e secondario. Lo scopo è accertarsi che Wikipedia e gli altri wiki Wikimedia riescano a rimanere online anche dopo un disastro. Al fine di garantire che tutto funzioni a dovere, il dipartimento tecnologico di Wikimedia ha bisogno di condurre un test programmato. Il test dimostrerà se è possibile passare da un data center all'altro in sicurezza. Diversi team si prepareranno per il test e saranno a disposizione per correggere qualsiasi problema imprevisto che si dovesse verificare.

Sfortunatamente, a causa di alcune limitazioni di MediaWiki, tutte le attività di modifica dovranno interrompersi durante lo scambio. Ci scusiamo per il disagio, stiamo lavorando per minimizzarlo in futuro.

Sarai in grado di leggere, ma non di modificare, tutti i wiki per un breve periodo di tempo.

• Martedì 29 giugno 2021 non sarà possibile effettuare modifiche per al massimo un'ora. Il test avrà inizio alle 14:00 UTC (07:00 PDT, 10:00 EDT, 15:00 WEST/BST, 16:00 CEST, 19:30 IST, 23:00 JST e 02:00 NZST di mercoledì 30 giugno in Nuova Zelanda).
• Se proverai a effettuare o pubblicare modifiche durante il suddetto orario, visualizzerai un messaggio di errore. Speriamo che nessuna modifica venga persa durante questi pochi minuti, ma non possiamo garantirlo. Se dovessi visualizzare il messaggio di errore, attendi fino a che tutto non torni alla normalità. Da quel momento in poi potrai pubblicare di nuovo le tue modifiche. Per ogni eventualità, ti suggeriamo comunque di salvartene una copia nel frattempo.

Altre conseguenze:

• I processi in background saranno più lenti e alcuni potrebbero interrompersi. I link rossi potrebbero non essere aggiornati con la solita velocità. Se crei una voce per cui esiste già un link entrante a partire da un'altra voce, il collegamento rimarrà rosso più a lungo del solito. Alcuni script in esecuzione da molto tempo dovranno essere fermati.
• Ci sarà un congelamento del codice di MediaWiki durante la settimana del 28 giugno. Tutti gli aggiornamenti non essenziali del codice di MediaWiki non avranno luogo.

Questo progetto potrebbe essere posticipato se necessario. Consulta la tabella di marcia su wikitech.wikimedia.org. Ogni cambiamento sarà annunciato nella tabella di marcia. Ci saranno ulteriori avvisi riguardo a questo test. Un banner apparirà su tutti i wiki a 30 minuti dall'inizio dell'operazione. Per favore, condividi queste informazioni con la tua comunità.

SGrabarczuk (WMF) 03:23, 27 giu 2021 (CEST)

Server switch

Leggi questo messaggio in un'altra lingua • Aiutaci a tradurre nella tua lingua

Wikimedia Foundation sta effettuando test di passaggio tra il suo data center primario e secondario. Lo scopo è accertarsi che Wikipedia e gli altri wiki Wikimedia riescano a rimanere online anche dopo un disastro. Al fine di garantire che tutto funzioni a dovere, il dipartimento tecnologico di Wikimedia ha bisogno di condurre un test programmato. Il test dimostrerà se è possibile passare da un data center all'altro in sicurezza. Diversi team si prepareranno per il test e saranno a disposizione per correggere qualsiasi problema imprevisto che si dovesse verificare.

Tutto il traffico sarà instradato nuovamente sul data center primario martedì 14 settembre 2021.

Sfortunatamente, a causa di alcune limitazioni di MediaWiki, tutte le attività di modifica dovranno interrompersi durante lo scambio. Ci scusiamo per il disagio, stiamo lavorando per minimizzarlo in futuro.

Sarai in grado di leggere, ma non di modificare, tutti i wiki per un breve periodo di tempo.

• Martedì 14 settembre 2021 non sarà possibile effettuare modifiche per al massimo un'ora. Il test avrà inizio alle 14:00 UTC (07:00 PDT, 10:00 EDT, 15:00 WEST/BST, 16:00 CEST, 19:30 IST, 23:00 JST e 02:00 NZST di mercoledì 15 settembre in Nuova Zelanda).
• Se proverai a effettuare o pubblicare modifiche durante il suddetto orario, visualizzerai un messaggio di errore. Speriamo che nessuna modifica venga persa durante questi pochi minuti, ma non possiamo garantirlo. Se dovessi visualizzare il messaggio di errore, attendi fino a che tutto non torni alla normalità. Da quel momento in poi potrai pubblicare di nuovo le tue modifiche. Per ogni eventualità, ti suggeriamo comunque di salvartene una copia nel frattempo.

Altre conseguenze:

• I processi in background saranno più lenti e alcuni potrebbero interrompersi. I link rossi potrebbero non essere aggiornati con la solita velocità. Se crei una voce per cui esiste già un link entrante a partire da un'altra voce, il collegamento rimarrà rosso più a lungo del solito. Alcuni script in esecuzione da molto tempo dovranno essere fermati.
• La distribuzione del codice dovrebbe avvenire normalmente come le altre settimane. However, some case-by-case code freezes could punctually happen if the operation require them afterwards.

Questo progetto potrebbe essere posticipato se necessario. Consulta la tabella di marcia su wikitech.wikimedia.org. Ogni cambiamento sarà annunciato nella tabella di marcia. Ci saranno ulteriori avvisi riguardo a questo test. Un banner apparirà su tutti i wiki a 30 minuti dall'inizio dell'operazione. Per favore, condividi queste informazioni con la tua comunità.

SGrabarczuk (WMF) (discussione) 03:10, 11 set 2021 (CEST)

Bots need to upgrade to Pywikibot 6.6.1

Dear bot operators, bots running Pywikibot must upgrade to version 6.6.1 otherwise they will break when deprecated API parameters are removed. If you have any questions or need help in upgrading, please reach out using one of the Pywikibot communication channels.

Thanks, Legoktm (talk) 20:02, 22 set 2021 (CEST)

Your wiki will be in read only soon

Leggi questo messaggio in un'altra lingua • Aiutaci a tradurre nella tua lingua

Wikimedia Foundation sta effettuando test di passaggio tra il suo data center primario e quello secondario. Lo scopo è accertarsi che Wikipedia e le altre wiki Wikimedia riescano a rimanere online anche dopo un disastro. Al fine di garantire che tutto funzioni a dovere, il dipartimento tecnologico di Wikimedia ha bisogno di condurre un test programmato. Il test dimostrerà se è possibile passare da un data center all'altro in sicurezza. Diversi team si prepareranno per il test e saranno a disposizione per correggere qualsiasi problema imprevisto che si dovesse verificare.

Tutto il traffico sarà commutato il giorno 1 marzo. Il test avrà inizio alle 14:00 UTC.

Sfortunatamente, a causa di alcune limitazioni di MediaWiki, tutte le attività di modifica dovranno essere interrotte mentre si effettua il cambio. Ci scusiamo per il disagio, stiamo lavorando per minimizzarlo in futuro.

Sarai in grado di leggere, ma non di modificare, tutte le wiki per un breve periodo di tempo.

• Il giorno mercoledì 1 marzo 2023 non sarà possibile effettuare modifiche per al massimo un'ora.
• Se proverai a modificare o a salvare durante il periodo di sospensione, vedrai apparire un messaggio d'errore. Speriamo che nessuna modifica venga persa durante questi pochi minuti, ma non possiamo garantirlo. Se vedi apparire il messaggio di errore, per cortesia attendi fino a che non sia tornato tutto alla normalità. Da quel momento potrai salvare le tue modifiche. È comunque consigliabile fare prima una copia delle modifiche, per essere pronti a ogni eventualità.

Altre conseguenze:

• I processi in background saranno più lenti e alcuni potrebbero interrompersi. I link rossi potrebbero non essere aggiornati velocemente come al solito. Se crei una voce per cui esiste già un link entrante a partire da un'altra voce, il collegamento rimarrà rosso più a lungo del solito. Alcuni script in esecuzione di lunga durata dovranno essere fermati.
• La distribuzione del codice dovrebbe avvenire normalmente come le altre settimane. Tuttavia, alcuni blocchi nell'aggiornamento del codice potrebbero avvenire puntualmente se l'operazione lo dovesse richiedere in seguito.
• GitLab non sarà disponibile per circa 90 minuti.

Il progetto potrebbe essere posticipato se necessario. Puoi leggere la tabella di marcia su wikitech.wikimedia.org. Ogni cambiamento sarà annunciato nella tabella di marcia. Ci saranno ulteriori avvisi riguardo a questo test. Un banner apparirà su tutte le wiki 30 minuti prima dell'inizio dell'operazione. Per favore, condividi queste informazioni con la tua comunità.

Trizek (WMF) (Discussione) 22:24, 27 feb 2023 (CET)

La tua wiki presto sarà in modalità solo lettura

Leggi questo messaggio in un'altra lingua • Aiutaci a tradurre nella tua lingua

Wikimedia Foundation sta effettuando test di passaggio tra il suo data center primario e quello secondario. Lo scopo è accertarsi che Wikipedia e le altre wiki Wikimedia riescano a rimanere online anche dopo un disastro. Al fine di garantire che tutto funzioni a dovere, il dipartimento tecnologico di Wikimedia ha bisogno di condurre un test programmato. Il test dimostrerà se è possibile passare da un data center all'altro in sicurezza. Diversi team si prepareranno per il test e saranno a disposizione per correggere qualsiasi problema imprevisto che si dovesse verificare.

Tutto il traffico sarà commutato il giorno 26 aprile. Il test avrà inizio alle 14:00 UTC.

Sfortunatamente, a causa di alcune limitazioni di MediaWiki, tutte le attività di modifica dovranno essere interrotte mentre si effettua il cambio. Ci scusiamo per il disagio, stiamo lavorando per minimizzarlo in futuro.

Sarai in grado di leggere, ma non di modificare, tutte le wiki per un breve periodo di tempo.

• Il giorno mercoledì 26 aprile 2023 non sarà possibile effettuare modifiche per al massimo un'ora.
• Se proverai a modificare o a salvare durante il periodo di sospensione, vedrai apparire un messaggio d'errore. Speriamo che nessuna modifica venga persa durante questi pochi minuti, ma non possiamo garantirlo. Se vedi apparire il messaggio di errore, per cortesia attendi fino a che non sia tornato tutto alla normalità. Da quel momento potrai salvare le tue modifiche. È comunque consigliabile fare prima una copia delle modifiche, per essere pronti a ogni eventualità.

Altre conseguenze:

• I processi in background saranno più lenti e alcuni potrebbero interrompersi. I link rossi potrebbero non essere aggiornati velocemente come al solito. Se crei una voce per cui esiste già un link entrante a partire da un'altra voce, il collegamento rimarrà rosso più a lungo del solito. Alcuni script in esecuzione di lunga durata dovranno essere fermati.
• La distribuzione del codice dovrebbe avvenire normalmente come le altre settimane. Tuttavia, alcuni blocchi nell'aggiornamento del codice potrebbero avvenire puntualmente se l'operazione lo dovesse richiedere in seguito.
• GitLab non sarà disponibile per circa 90 minuti.

Il progetto potrebbe essere posticipato se necessario. Puoi leggere la tabella di marcia su wikitech.wikimedia.org. Ogni cambiamento sarà annunciato nella tabella di marcia. Ci saranno ulteriori avvisi riguardo a questo test. Un banner apparirà su tutte le wiki 30 minuti prima dell'inizio dell'operazione. Per favore, condividi queste informazioni con la tua comunità.

MediaWiki message delivery 03:21, 21 apr 2023 (CEST)

La tua wiki presto sarà in modalità solo lettura

Leggi questo messaggio in un'altra lingua • Aiutaci a tradurre nella tua lingua

Wikimedia Foundation scambierà il traffico tra i suoi data center. Lo scopo è accertarsi che Wikipedia e le altre wiki Wikimedia riescano a rimanere online anche dopo un disastro. Al fine di garantire che tutto funzioni a dovere, il dipartimento tecnologico di Wikimedia ha bisogno di condurre un test programmato. Il test dimostrerà se è possibile passare da un data center all'altro in sicurezza. Diversi team si prepareranno per il test e saranno a disposizione per correggere qualsiasi problema imprevisto che si dovesse verificare.

Tutto il traffico sarà commutato il giorno 20 settembre. Il test avrà inizio alle 14:00 UTC.

Sfortunatamente, a causa di alcune limitazioni di MediaWiki, tutte le attività di modifica dovranno essere interrotte mentre si effettua il cambio. Ci scusiamo per il disagio, stiamo lavorando per minimizzarlo in futuro.

Sarai in grado di leggere, ma non di modificare, tutte le wiki per un breve periodo di tempo.

• Il giorno mercoledì 20 settembre 2023 non sarà possibile effettuare modifiche per al massimo un'ora.
• Se proverai a modificare o a salvare durante il periodo di sospensione, vedrai apparire un messaggio d'errore. Speriamo che nessuna modifica venga persa durante questi pochi minuti, ma non possiamo garantirlo. Se vedi apparire il messaggio di errore, per cortesia attendi fino a che non sia tornato tutto alla normalità. Da quel momento potrai salvare le tue modifiche. È comunque consigliabile fare prima una copia delle modifiche, per essere pronti a ogni eventualità.

Altre conseguenze:

• I processi in background saranno più lenti e alcuni potrebbero interrompersi. I link rossi potrebbero non essere aggiornati velocemente come al solito. Se crei una voce per cui esiste già un link entrante a partire da un'altra voce, il collegamento rimarrà rosso più a lungo del solito. Alcuni script in esecuzione di lunga durata dovranno essere fermati.
• La distribuzione del codice dovrebbe avvenire normalmente come le altre settimane. Tuttavia, alcuni blocchi nell'aggiornamento del codice potrebbero avvenire puntualmente se l'operazione lo dovesse richiedere in seguito.
• GitLab non sarà disponibile per circa 90 minuti.

Il progetto potrebbe essere posticipato se necessario. Puoi leggere la tabella di marcia su wikitech.wikimedia.org. Ogni cambiamento sarà annunciato nella tabella di marcia. Ci saranno ulteriori avvisi riguardo a questo test. Un banner apparirà su tutte le wiki 30 minuti prima dell'inizio dell'operazione. Per favore, condividi queste informazioni con la tua comunità.

Trizek_(WMF) (talk) 11:30, 15 set 2023 (CEST)