Negli ultimi giorni sto scrivendo un bot che svolga in automatico le operazioni relative alle nuove riconferme (i 7 punti sotto "Istruzioni per avviare una riconferma" nella pagina associata a questa). La cosa di per sé non è facile, e ho dovuto rinunciare molto rapidamente a renderlo utilizzabile anche in altre wiki perché, almeno in questo caso, la burocrazia non è localizzabile (non in tempi utili). Tuttavia, c'è almeno una cosa che forse si potrebbe semplificare: l'inserimento di funzioni aggiuntive nella pagina della riconferma. Le istruzioni dicono che bisogna prima creare la pagina substando lo schema e poi, se l'utente ha funzioni aggiuntive, aggiungere tali funzioni al testo generato. La mia proposta è quella di farlo automaticamente dal template dello schema. Sinceramente non so se sia fattibile con la sola wikisintassi, in alternativa si può passare a modulo Lua. A quel punto si possono aggiungere parametri opzionali allo schema, ad es. |burocrate = sì. Pareri? --Daimona Eaytoy(Scrivimi!)16:49, 1 apr 2019 (CEST)[rispondi]
Dimenticavo, ci sarebbe anche un'altra cosa: il quorum. In questo caso, la mia proposta è di usare una pagina nel ns4 dedicata, che contenga soltanto il quorum. Ad esempio Wikipedia:Amministratori/Sistema di voto/Quorum/Attuale, con dentro soltanto il valore stesso, così da poter substare tale pagina ovunque ci sia bisogno (ovvero non solo per le riconferme, ma anche nelle elezioni etc.). --Daimona Eaytoy(Scrivimi!)16:53, 1 apr 2019 (CEST)[rispondi]
Ri-dimenticavo. Per quale motivo si specifica se l'utente ha accesso a OTRS? Si tratta di un gruppo globale la cui menzione non mi sembra utile. Altrimenti perché non menzionare, ad esempio, utenti global sysop, steward, abusefilter-helper etc? E inoltre: l'assenza del ruolo di WP:AI è solo una dimenticanza? --Daimona Eaytoy(Scrivimi!)17:09, 1 apr 2019 (CEST)[rispondi]
Se usi le parole chiave "automatizzare" e "semplificare" hai già conquistato i nostri cuori :-) Per me quegli accorgimenti vanno bene. Sui flag da segnalare, diciamo che le riconferme valide anche nei panni di burocrate e CU hanno più senso che per gli altri flag per via della seconda elezione locale che hanno a carico, ma non saprei.--Sakretsu (炸裂) 17:18, 1 apr 2019 (CEST)[rispondi]
Eheh ;-) Stavo pensando a come applicare nel pratico entrambe le opzioni, in particolare per il quorum. Ho provato con una pagina che includa solo {{#expr:...}} (preso da {{Quorum}}), ma rimane il fatto che aggiornarla a mano non è il massimo. --Daimona Eaytoy(Scrivimi!)18:52, 1 apr 2019 (CEST)[rispondi]
Per quello mi sa che non ci sia alternativa alla buona vecchia manina. Non è comunque un dato che si aggiorna ad alta frequenza.--Sakretsu (炸裂) 19:55, 1 apr 2019 (CEST)[rispondi]
O volendo posso aggiungerlo ai task del bot, ma non subito. Se non ci sono pareri contrari, domani creo la pagina in oggetto. Poi a decidere se usarla o meno, ed eventualmente come migliorarla, di tempo ce n'è. --Daimona Eaytoy(Scrivimi!)20:25, 1 apr 2019 (CEST)[rispondi]
La riconferma di OTRS sarà qualche reminiscenza di regole passate. Magari qualcuno dei "Grandi Antichi" può confermarcelo. Da parte mia posso assicurarvi che accettare o meno un agente nel "servizio clienti della WMF" aka "OTRS" è una procedura totalmente indipendente da una riconferma fallita (anche se la cosa potrebbe comunque suscitare una discussione lato OTRS). --Ruthven(msg)11:11, 2 apr 2019 (CEST)[rispondi]
Ho buttato giù una bozza anche per lo schema, che trovate qui. Per provarla c'è questa mia sandbox, con le 4 versioni che si ottengono a seconda dei parametri. Subst e spazi a parte, è stato più semplice del previsto farlo in wikitesto. Gli OTRS sono già esclusi dalla bozza, mentre per il quorum non ho avuto idee migliori :/ --Daimona Eaytoy(Scrivimi!)17:29, 2 apr 2019 (CEST)[rispondi]
[← Rientro] Dunque, noto che alla fine le proposte che ho fatto sono tantine, riassumo quindi qui sotto lo stato attuale.
Aggiungere i parametri datacheckuser e databurocrate allo schema per le riconferme così da non doverli aggiungere a mano (già visibile qui).
Rimuovere la dicitura "con funzioni OTRS ..." dallo schema perché non se ne coglie l'utilità
Creare una pagina nel ns4 destinata a contenere il quorum, substabile in modo da restituire soltanto il numero stesso
Risolvere il fatto che {{VotazioniRCnews}} è editabile solo da admin. Un'idea è di utilizzare una sottopagina JSON del bot (esempio), che però ha due svantaggi: 1-Sarebbe modificabile solo dagli AI (oltre che dal bot stesso, naturalmente) e 2-Avrà bisogno di essere modificata, perché (per ora) il bot non gestisce la chiusura delle riconferme e non credo gestirà mai la trasformazione di tacita in votazione. Altre idee non me ne vengono, perché o si abbassa il livello di protezione del template, o il bot non può modificarlo.
Il primo punto mi sembra quello più semplice, e in assenza di pareri contrari procederei ad implementarlo in giornata, dato che si tratta soltanto di una finesse tecnica. Sul secondo mi sembra che ci sia accordo ma possiamo aspettare. Su 3 e 4 sono aperto a ulteriori idee, perché quelle attuali non mi convincono granché. --Daimona Eaytoy(Scrivimi!)11:46, 3 apr 2019 (CEST) P.S. Dimenticavo: al momento sarei dell'idea di non chiedere il flag di bot. Primo perché si attiverebbe soltanto una volta al giorno, con una quantità di modifiche sufficientemente bassa da non dover essere nascosta. Secondo, perché si occuperebbe di modificare pagine che richiedono visibilità, come quella delle votazioni e la talk, e le modifiche effettuate da bot non sarebbero visibili agli utenti che le nascondono.[rispondi]
Questa discussione mi era sfuggita... per fortuna ho notato nelle RC che stavi tramando per togliermi il lavoro proprio ora che l'ho sottratto a Sakretsu :-P
Ovviamente Fortemente favorevole a qualsiasi automatizzazione. Per punti:
Fortemente favorevole: molto più ordinato!
Favorevole la riconferma ad admin non ha nulla a che fare con il ruolo su OTRS (mi sono sempre chiesto anche io perchè andasse indicato)
con {{Quorum|tabella=si}} la tabella stessa e la stringa conclusiva;
con {{Quorum|tabella=no}} solo il valore numerico del quorum, utilizzabile dal bot;
Ma è proprio necessaria la protezione completa a {{VotazioniRCnews}}? Non basterebbe una semiprotezione?
(4 bis) La chiusura delle tacite non mi sembra una cosa difficile da bottizzare: se alla scadenza della settimana non sono ancora state trasformate manualmente in votazione, si protegge e si chiude. Se facesse questo IMHO si potrebbe tranquillamente dare il flag di A-Bot (e incidentalmente risolvere anche il problema {{VotazioniRCnews}})
(4 ter e 5 bis) Se non si vuole dare il flag di A-Bot, si potrebbe tenere noi il compito di proteggere le procedure scadute, e lasciare al bot la trafila burocratica di archiviazione per le sole procedure già protette; a quel punto la parte sulle tacite del {{VotazioniRCnews}} la gestirebbe sempre il bot (tranne in caso di votazione di riconferma): e quindi possiamo tirar fuori dal {{VotazioniRCnews}} il valore per le tacite e metterlo in un JSON, dato che l'intervento di un AI sarebbe richiesto solo nei rari casi di votazione.
[@ Equoreo] Grazie per i pareri! Allora a questo punto faccio 1 e 2 insieme in serata se non ci sono opposizioni. Riguardo al 3: sì, andrebbe bene. L'importante è che sia substabile in modo da ottenere il solo numero. Il flag di admin-bot senz'altro risolverebbe varie cose, in particolare la modifica del votazioniRCnews e la possibilità di chiudere le riconferme. Chiaramente però non è una cosa da prendere alla leggera. --Daimona Eaytoy(Scrivimi!)13:22, 3 apr 2019 (CEST)[rispondi]
Tanto che siamo in ballo, con la modifica allo schema includerei anche la rimozione dei parametri per il tempo di inizio e fine, mettendoli direttamente dentro allo schema in includeonly. --Daimona Eaytoy(Scrivimi!)14:55, 3 apr 2019 (CEST)[rispondi]
[← Rientro] Allora... Per il quorum come dicevo all'inizio non mi vengono soluzioni ottimali perché comunque rimane un dato da aggiornare a mano. Ciò detto, la mia proposta è la seguente: 1 - Identificare una pagina che dovrà essere aggiornata costantemente (sia essa Wikipedia:Amministratori/Sistema di voto/Quorum/Attuale, o anche {{Quorum}}). 2 - In tale pagina saranno hardcodati i nomi degli ultimi candidati e relativi partecipanti. 3 - La pagina in oggetto accetterà un parametro, ad esempio |testo=, che se valorizzato restituirà anche (guarda un po') il testo di accompagnamento. A quel punto: Wikipedia:Amministratori/Sistema_di_voto/Quorum includerà tale pagina con |testo=sì e senza subst, e lo schema la substerà senza parametri. Che ne dite? Riguardo al votazioniRCnews, al momento mi preoccupa poco. A dire la verità la protezione sysop mi sembra adeguata (è molto visibile, incluso in messaggio di sistema). Le opzioni temporanee sono admin-bot oppure riduzione a SP (se necessarie). Per il lungo termine, vedremo se e quando il bot si occuperà anche delle chiusure. --Daimona Eaytoy(Scrivimi!)11:11, 4 apr 2019 (CEST)[rispondi]
Apro con gioia un'altra discussione per sottoporre alla comunità due problemi che ho trovato nell'automatizzare le riconferme admin con User:BotRiconferme. Prima, una breve introduzione: stando alle linee guida, la data di prima riconferma è determinata nel seguente modo: se l'utente è burocrate o CU, si prende il giorno più recente tra queste due elezioni, altrimenti è la data di elezione ad admin. Inoltre, ogni anno la data di riconferma viene spostata in avanti di una quantità pari alla durata della riconferma corrente.
Esempio: se Utente:Tizio è stato eletto il 12 novembre 2017, la sua prima riconferma inizierà il 12 novembre 2018; supponendo che la riconferma 2018 sia tacita della durata di una settimana, la riconferma 2019 inizierà il 12 + 7 = 19 novembre.
Questo approccio ha come risultato che calcolare la data di riconferma non è immediato, perché a partire dalla data del flag bisogna andare avanti aggiungendo prima 7 giorni e poi un anno; immagino (ma non ho verificato) che i bisestili vengano contati solo nella settimana di riconferma, che quindi ha una durata fissa di 7 giorni, ma non nel "salto" di un anno.
Esempio 1: riconferma finita il 25 febbraio 2016 => la successiva inizia il 25 febbraio 2017, 366 giorni dopo;
Esempio 2: riconferma iniziata il 28 febbraio 2016 finisce il 6 aprile e non il 7, ovvero 7 giorni dopo.
Se inoltre una riconferma passata non fosse stata tacita, lo slittamento sarebbe superiore alla settimana, e di una durata variabile a seconda del momento di apertura del voto. Questo rende la data di riconferma molto più difficile da calcolare, e ci porta alla prima proposta: evitare slittamenti di tempo tra una riconferma e l'altra.
Esempio: se la data di elezione di Tizio è il 25 dicembre 2005, TUTTI gli anni la riconferma di Tizio inizia il 25 dicembre, punto e basta.
A mio avviso non c'è necessità di fiscalismo con quella settimana in meno, che finisce soltanto col complicare le cose. Nota: si potrebbe obiettare che basterebbe una lista con le date della prossima riconferma (come in WP:Amministratori/Lista), senza doverle calcolare ogni volta. Il che è vero, ma mantenere una tale lista è a mio avviso di poca utilità e a rischio di errore, dato che stiamo parlando di oltre 100 amministratori da gestire. Mini-nota: la proposta avrebbe anche il vantaggio di non dover aggiornare WP:Amministratori/Lista ad ogni avvenuta riconferma.
Ma non è finita qui. La proposta sopra è a mio avviso auspicabile, ma non necessaria. Ciò che a mio avviso è NECESSARIO è allineare nuovamente le date di riconferma di tutti gli admin. Con o senza settimane di slittamento non importa, ma al momento molte di esse sono sfasate. Principalmente a causa di "errori umani": dimenticanza di far partire la riconferma il giorno prefissato. Esempio: questa procedura è finita il 28 gennaio, ma quella dell'anno successivo è partita il 30 gennaio. Di date sballate in questo senso ce ne sono tante. Per farsi un'idea, le ho raccolte con uno script automatico, di cui trovate l'output nel cassetto seguente.
Sfasamenti delle riconferme
GIUSTE
Ale Sasso: Expected and actual = 26 April 2019
Amarvudol: Expected and actual = 28 March 2020
ArtAttack: Expected and actual = 14 June 2019
Buggia: Expected and actual = 29 March 2020
Carlomartini86: Expected and actual = 28 April 2019
Ceppicone: Expected and actual = 25 June 2019
Civvì: Expected and actual = 20 February 2020
Daimona Eaytoy: Expected and actual = 22 September 2019
Dan Kenshi: Expected and actual = 20 January 2020
Dimitrij Kasev: Expected and actual = 02 April 2020
Dome: Expected and actual = 13 May 2019
Equoreo: Expected and actual = 10 January 2020
Er Cicero: Expected and actual = 24 August 2019
Erinaceus: Expected and actual = 21 May 2019
Euphydryas: Expected and actual = 03 February 2020
Fabyrav: Expected and actual = 11 April 2020
Gianfranco: Expected and actual = 20 July 2019
Hypergio: Expected and actual = 23 August 2019
Kirk39: Expected and actual = 11 December 2019
M&A: Expected and actual = 09 October 2019
Melquíades: Expected and actual = 10 January 2020
Mess: Expected and actual = 03 May 2019
Narayan89: Expected and actual = 12 March 2020
Ombra: Expected and actual = 14 April 2020
Parma1983: Expected and actual = 22 September 2019
Retaggio: Expected and actual = 10 May 2019
Ripepette: Expected and actual = 04 March 2020
Sakretsu: Expected and actual = 15 August 2019
Valerio Bozzolan: Expected and actual = 11 April 2020
ValterVB: Expected and actual = 28 April 2019
Vegetable: Expected and actual = 10 December 2019
SBAGLIATE
%Pier%: Expected = 18 February 2020, actual = 20 February 2020
.avgas: Expected = 26 November 2019, actual = 27 November 2019
.mau.: Expected = 20 February 2020, actual = 24 February 2020
.snoopy.: Expected = 20 January 2020, actual = 17 January 2020
Abisys: Expected = 14 August 2019, actual = 16 August 2019
Alkalin: Expected = 05 April 2020, actual = 07 April 2020
Antonio1952: Expected = 25 May 2019, actual = 24 May 2019
Aplasia: Expected = 10 December 2019, actual = 12 December 2019
Archenzo: Expected = 14 October 2019, actual = 08 April 2020
Ary29: Expected = 12 February 2020, actual = 28 December 2019
Ask21: Expected = 17 March 2020, actual = 11 August 2019
BohemianRhapsody: Expected = 16 January 2020, actual = 17 January 2020
Bradipo Lento: Expected = 26 May 2019, actual = 27 May 2019
Bramfab: Expected = 27 July 2019, actual = 14 April 2019
Bultro: Expected = 16 October 2019, actual = 20 October 2019
Burgundo: Expected = 26 July 2019, actual = 28 June 2019
Carlomorino: Expected = 12 July 2019, actual = 13 July 2019
Castagna: Expected = 12 April 2020, actual = 18 April 2019
Caulfield: Expected = 11 July 2019, actual = 12 July 2019
Delfort: Expected = 09 June 2019, actual = 10 June 2019
Doc.mari: Expected = 30 December 2019, actual = 31 December 2019
Dr Zimbu: Expected = 14 January 2020, actual = 17 January 2020
Elwood: Expected = 03 April 2020, actual = 05 April 2020
Epìdosis: Expected = 29 January 2020, actual = 30 January 2020
Esculapio: Expected = 05 December 2019, actual = 01 December 2019
Eumolpo: Expected = 26 May 2019, actual = 27 May 2019
Eustace Bagge: Expected = 24 June 2019, actual = 25 June 2019
FeltriaUrbsPicta: Expected = 10 August 2019, actual = 11 August 2019
Fringio: Expected = 13 October 2019, actual = 14 October 2019
Gac: Expected = 12 April 2019, actual = 10 February 2020
Guidomac: Expected = 01 April 2020, actual = 14 April 2020
Horcrux: Expected = 12 June 2019, actual = 14 June 2019
Ignisdelavega: Expected = 26 November 2019, actual = 28 November 2019
Ilario: Expected = 12 September 2019, actual = 27 January 2020
IndyJr: Expected = 17 March 2020, actual = 19 March 2020
Jaqen: Expected = 02 August 2019, actual = 21 August 2019
Kal-El: Expected = 26 January 2020, actual = 25 January 2020
Klaudio: Expected = 20 January 2020, actual = 21 January 2020
KS: Expected = 05 August 2019, actual = 16 August 2019
L736E: Expected = 17 January 2020, actual = 28 December 2019
Laurentius: Expected = 17 December 2019, actual = 28 December 2019
Lepido: Expected = 14 September 2019, actual = 17 September 2019
Madaki: Expected = 06 April 2020, actual = 21 January 2020
Marcok: Expected = 22 May 2019, actual = 17 January 2020
MM: Expected = 23 November 2019, actual = 16 November 2019
MapiVanPelt: Expected = 03 February 2020, actual = 05 February 2020
Melos: Expected = 10 June 2019, actual = 12 November 2019
Moroboshi: Expected = 16 June 2019, actual = 18 June 2019
Nicolabel: Expected = 15 June 2019, actual = 16 June 2019
Nubifer: Expected = 14 January 2020, actual = 17 January 2020
Osk: Expected = 30 June 2019, actual = 06 July 2019
Paginazero: Expected = 12 April 2019, actual = 17 January 2020
Pequod76: Expected = 18 May 2019, actual = 19 May 2019
Phantomas: Expected = 07 April 2020, actual = 05 April 2020
Phyrexian: Expected = 18 May 2019, actual = 19 May 2019
Pierpao: Expected = 26 July 2019, actual = 25 July 2019
Pil56: Expected = 26 February 2020, actual = 12 February 2020
RanZag: Expected = 22 September 2019, actual = 25 September 2019
Remulazz: Expected = 24 January 2020, actual = 27 January 2020
Roberto Mura: Expected = 02 November 2019, actual = 20 August 2019
Rojelio: Expected = 24 March 2020, actual = 29 March 2020
Ruthven: Expected = 06 September 2019, actual = 31 August 2019
Sannita: Expected = 14 April 2019, actual = 05 May 2019
Sanremofilo: Expected = 01 January 2020, actual = 05 January 2020
Shivanarayana: Expected = 27 February 2020, actual = 26 February 2020
Soprano71: Expected = 05 November 2019, actual = 29 October 2019
Superchilum: Expected = 17 September 2019, actual = 10 September 2019
Supernino: Expected = 07 July 2019, actual = 11 July 2019
Syrio: Expected = 01 May 2019, actual = 03 May 2019
Threecharlie: Expected = 10 February 2020, actual = 13 February 2020
Tirinto: Expected = 13 November 2019, actual = 28 November 2019
Tooby: Expected = 14 February 2020, actual = 14 March 2020
Torsolo: Expected = 14 February 2020, actual = 11 March 2020
Vale93b: Expected = 09 May 2019, actual = 10 May 2019
Valepert: Expected = 05 September 2019, actual = 06 September 2019
Veneziano: Expected = 28 January 2020, actual = 30 January 2020
Vituzzu: Expected = 14 June 2019, actual = 13 June 2019
Yiyi: Expected = 25 January 2020, actual = 27 January 2020
Ovviamente potrebbero esserci errori nella lista sopra, ma 78 sbagliate a fronte di 31 giuste mi sembra un dato alquanto preoccupante. Dato che il bot dovrebbe assicurare regolarità in futuro, la seconda proposta è di correggere le date "errate", impostando la prossima riconferma alla data che dovrebbe essere. Ovvero quella "expected" se non vogliamo attuare la proposta 1, quella di elezione in caso contrario.
Scusate la lunghezza del pippone sopra, e ovviamente chiedete se c'è qualcosa di non chiaro.--Daimona Eaytoy(Scrivimi!)13:28, 9 apr 2019 (CEST)[rispondi]
[× Conflitto di modifiche][@ Daimona Eaytoy] So che potrebbe suonare buffo, ma ho notato che manca nella lista degli Amministratori il Filtro Anti Abusi, che è a tutti gli effetti un amministratore. E' una svista o una mancanza voluta? Potrebbe essere utile lasciare anche a lui una pagina di riconferma per commentare l'operato dei blocchi attuati dai filtri, segnalare problemi ricorrenti, proposte per nuovi filtri, ecc.--Lemure Saltante olim DaoLR 14:14, 9 apr 2019 (CEST)[rispondi]
[↓↑ fuori crono][@ Lemure Saltante] Ma ROTFL, se ci sono problemi con i filtri lo si segnala subito! Non si aspetta la riconferma dell'admin. :-D Elencarlo sarebbe solo una scelta folkloristica... diciamo che l'elenco attuale è composto da admin umani. --.avgas14:27, 9 apr 2019 (CEST)[rispondi]
La stessa cosa la segnalai appena nominato nel 20182017. Abolire tutto la vedo dura anche se non sono contrario. In alternativa basterebbe abolire la settimana anche perchè l'amministratore non smette di essere amministratore nella settimana. è un allungamento senza motivazione. Basta far partire la riconferma un anno dopo alla stessa data--Pierpao.lo(listening)14:21, 9 apr 2019 (CEST)[rispondi]
Per quanto mi riguarda, si può benissimo allineare la data al giorno di elezione, senza spostamenti. Non hanno senso e - informaticamente parlando - complicano inutilmente le cose. --.avgas14:27, 9 apr 2019 (CEST)[rispondi]
[× Conflitto di modifiche][@ Blackcat] A dire il vero, il conteggio preciso non mi interessa molto. Per come la vedo io, la riconferma annuale è un'occasione per commenti, critiche, un'occasione per il desysoppaggio etc. Che avviene mentre l'utente è ancora admin: è, diciamo, una cosa "tranquilla" e non vedo motivo di esser fiscali alla settimana. Se ci sono problemi con l'amministratore non dovrebbe servire di aspettare la riconferma annuale, e una settimana in più o in meno direi che non fa differenza. Mi sembra solo un avvitamento burocratico tranquillamente evitabile. Sulla tua seconda proposta ci sarebbe tanto da dire, ma va ben oltre lo scopo di questa discussione (e sarebbe una cosa molto, molto più lunga). [@ Lemure Saltante] In effetti la proposta è buffa... Non si tratta di una persona, e non è "a tutti gli effetti un amministratore". Ha i diritti solo perché vedere un utente non flaggato bloccare la gente farebbe molto strano, e comunque stiamo già cercando di togliergli il flag backend. Una riconferma per un utente che neanche esiste mi sembra un'utopia, se ci sono problemi o proposte per i filtri c'è WP:RAA. Forse sarebbe carino avere pagine separate, una per i problemi e una per le proposte, come su eswiki o enwiki, ma direi che il sistema attuale va comunque bene. --Daimona Eaytoy(Scrivimi!)14:34, 9 apr 2019 (CEST)[rispondi]
Beh sì, che non si tratta di una persona lo sapevo :) E se non fosse flaggato credo nemmeno potrebbe bloccare gli utenti, come utente semplice. La mia idea verteva soprattutto per i commenti/proposte non urgenti sul suo operato, in modo da non intasare WP:RAA, comunque era solo un'idea buttata lì :D--Lemure Saltante olim DaoLR 14:41, 9 apr 2019 (CEST)[rispondi]
Della settimana-bonus si era discusso un anno e mezzo fa, concludendo che rientrava nella vasta categoria dei problemi che non meritano di essere risolti. Se per motivi informatici ora passa alla categoria dei problemi problemosi, allineiamo tutto alla data di ultima votazione (elezione, riconferma, assegnazioni di funzioni superiori) e tanti saluti.--Equoreo (msg) 14:48, 9 apr 2019 (CEST)[rispondi]
[× Conflitto di modifiche] Ieri pomeriggio con Daimona avevo controllato alcune vecchie date di riconferma e ci eravamo accorti di alcune discrepanze sorte negli anni, che avevano comportato inspiegabili slittamenti anche di un mese e mezzo per motivi che ci sono apparsi ignoti. Direi quindi che una settimana avanti o indietro non influisca particolarmente, perciò, in vista della creazione del bot per le riconferme in automatico, per semplificare le cose sono decisamente Favorevole a evitare gli slittamenti--Parma198314:53, 9 apr 2019 (CEST)[rispondi]
[← Rientro][@ Lemure Saltante] Certo che può bloccarli senza essere flaggato :-) Il blocco viene eseguito saltando i controlli dei permessi, il flag è solo estetico, v. ad es. phab:T212268. Direi che in ogni caso per commenti sul filtro ci sono altre pagine (e.g. Discussioni aiuto:Filtro anti abusi o l'officina). [@ Equoreo] Concordo che in assenza di motivi validi non sia un problema urgente. Al momento, però, la motivazione c'è. Diciamo che la rimozione della settimana (a differenza dell'allineamento) non è troppo necessaria, ma tanto che ci siamo... Voglio dire, se dobbiamo riallineare 78 admin su 109, riallineiamoli tutti in modo da averli allineati anche in futuro. Comunque nella prima proposta ho detto esplicitamente di far cadere la riconferma nel giorno del flag (di qualunque flag si tratti) proprio per evitare di dover tenere una lista di 78 casi particolari. --Daimona Eaytoy(Scrivimi!)14:55, 9 apr 2019 (CEST)[rispondi]
A dire il vero pensavo fosse già così ma sbagliavo: giusto che la riconferma avvenga sempre, e non solo il primo anno, alla data dell'elezione, quindi Favorevole.--KirkDimmi!19:05, 9 apr 2019 (CEST)[rispondi]
[@ Parma1983, Daimona Eaytoy] Posso sbagliare (vado a memoria) ma credo che alcuni slittamenti si spieghino perché (1) le vecchie votazioni di revoca "resettavano" la data della riconferma; (2) in alcuni casi l'admin ha chiesto di anticipare la riconferma per evitare che cadesse in un periodo in cui non avrebbe potuto rispondere a eventuali domande (ad es. a causa di ferie senza connessione a internet). L'unico problema nella proposta mi pare proprio questo legato a questo secondo punto: prendiamo l'esempio di Tizio, eletto il 25 dicembre: se un anno decidesse di passare le vacanze di Natale in fondo a una grotta non avrebbe nessun modo di rispondere alle domande, e se decidesse di trasformarla in una tradizione non potrebbe farlo mai. Può sembrare un'ipotesi fantasiosa ma io una cosa del genere l'ho fatta e non ho editato per 3 settimane (ok non in fondo una grotta e non ero totalmente senza internet, ma comunque senza computer e con connessioni del cavolo). Quindi Contrario/a alla proposta se si esclude la possibilità di anticipare (escluderei quella di posticipare) la riconferma in caso di richiesta motivata. --Jaqen[...]20:51, 9 apr 2019 (CEST)[rispondi]
[@ Jaqen] Il problema è reale, pur tenendo conto del fatto che, come dicevo sopra, la riconferma è solo un'occasione "programmata", non l'unico momento in cui si possono fare commenti, critiche o domande all'admin. Solitamente le elezioni avvengono in periodi dell'anno non deserti, il che dovrebbe evitare il problema per molte riconferme. Ciò detto, nessun problema a implementare nel codice del bot la possibilità di riconferme anticipate. A patto che 1-venga usata con parsimonia: come dicevo sopra, la riconferma non è così "cruciale", quindi eviterei di anticipare se non ci sono buoni motivi (lasciati al buon senso); 2-nonostante l'anticipazione, la riconferma per l'anno successivo torna alla data regolare, a meno che l'admin non chieda uno spostamento permanente. Queste due cose per evitare una lista di 100 eccezioni. Ma comunque, nei limiti di questi due punti, direi che la cosa è solo un'aggiunta alla proposta iniziale, e non la esclude. --Daimona Eaytoy(Scrivimi!)21:30, 9 apr 2019 (CEST)[rispondi]
[@ Jaqen] Il caso cui accennavo prima dello slittamento in avanti (non indietro) di un mese e mezzo non è collegato nemmeno a eventuali votazioni di riconferma o a elezioni a CU, ma è effettivamente piuttosto vecchio. Per il resto, concordo con Daimona sul concedere la possibilità, solo in casi motivati, di anticipare la data sia per l'anno in corso sia in modo permanente; lascerei invece invariato il resto della sua proposta. Tra l'altro, se si dovesse davvero verificare un caso come quello di cui hai fatto l'esempio, nelle condizioni attuali andrebbe a finire che ogni anno quell'admin dovrebbe chiedere di anticipare la data di una settimana, perché ogni anno si ripresenterebbe lo stesso problema; uno spostamento permanente alla settimana prima risolverebbe invece il problema ;)--Parma198300:19, 10 apr 2019 (CEST)[rispondi]
Contrario alla proposta. Probabilmente la mia opinione è dettata dal fatto che sono completamente ignorante in materia, ma per me si sta affrontando un non-problema dando una soluzione legata a mancanza di alternative informaticamente valide. Ma non voglio proprio credere che sia così! Mi spiego: che una riconferma di admin parta con uno o due giorni (ma anche sette) di ritardo non mi sembra proprio un problema; e se un admin dura in carica 372 giorni prima di affrontare una riconferma, anziché 365, tanto meglio! E implementare un automatismo che consenta di evitare per il futuro questo non-problema, mi sembra una mera banalità. Io opererei così: a) faccio fare tutte le operazioni di avvio di riconferma ad un bot (immagino debba creare la sotto pagina, mettere i link in questa e altre pagine coinvolte, avvisare l'admin...); b) faccio in modo che questo bot agisca andandosi a leggere una lista aggiornata (lista che a quanto pare già c'è); c) chi si occupa di chiudere l'operazione di riconferma si occupa anche di aggiornare la lista di cui al punto b). E' davvero così complicata la questione? A me non sembra, anche se, essendo a diguno di bot e procedure di riconferma, magari dico una grossa fesseria. --CuriosityDestroyer (msg) 12:20, 10 apr 2019 (CEST)[rispondi]
[@ CuriosityDestroyer] Se ho aperto la discussione, l'ho fatto perché non ci sono soluzioni soddisfacenti, i ritardi casuali sono un problema pre-esistente e questa è un'occasione per risolverlo. Ciò che proponi, al netto delle varie altre operazioni del bot che non sono oggetto delle mie proposte, è esattamente ciò che in apertura preannunciavo con "si potrebbe obiettare che...". Si tratterebbe di fare un listone di 110 admin come quello esistente, di cui per una trentina vale una regola fissa, e per gli altri 80 il giorno è completamente casuale. Ma poi chi lo tiene aggiornato? Chi ne verifica la correttezza? E anzi, perché tenerlo aggiornato (o scrivere altro codice apposito) quando si può utilizzare questa lista, che è già pulita e semplice da controllare (anche in automatico)? Oltre a questo, in informatica come ovunque è fondamentale distinguere tra ciò che è semplice e ciò che è buono. Quando si tratta di codice le cose solo semplici, i cosiddetti "hack", penalizzano inevitabilmente la qualità del codice e finiscono solo per renderlo più complicato da capire e mantenere (xkcd correlato per gli amanti del genere). La lista di eccezioni per le riconferme ne è un esempio. A margine, se le proposte in apertura venissero approvate, preciso che non ci sarebbe assolutamente nulla da fare "a mano": basta far partire il bot e ci penserà lui a riallineare le riconferme quando sarà il momento.--Daimona Eaytoy(Scrivimi!)12:38, 10 apr 2019 (CEST)[rispondi]
[× Conflitto di modifiche][@ Jaqen] Stando alla nota 3 di questa pagina, le votazioni di revoca resettano ancora la data di riconferma (sono il solito puntiglioso :-) ). L'obiezione di Jaqen è sensata (tra l'altro abbiamo admin eletti in pieno agosto, il 24 dicembre...), ma non credo sarà un problema risolverlo.
[@ CuriosityDestroyer] Il problema era proprio il contrario: perchè un admin dovrebbe restare in carica 372 giorni? Allora facciamo 400 giorni (che è bello tondo) o 444 (così, per vezzo) :-) La cosa più sensata sarebbe farli restare in carica un anno, ma le regole prevedevano diversamente e cambiarle avrebbe richiesto discussioni inutili per una questione tutto sommato inutile. Ora la questione inutile rischia di richiedere lavoro informatico aggiuntivo (non sarebbe impossibile comunque): dobbiamo complicare il codice del bot per non toccare il 372 giorni? Per inciso (sempre perchè io sono pignolo :-) ) Daimona sta lavorando affinchè il bot, non solo apra, ma chiuda anche le procedure. --Equoreo (msg) 12:44, 10 apr 2019 (CEST)[rispondi]
Con rispetto per tutti - anche per il Tempo! - davvero stiamo discutendo di 1 settimana in più o 1 in meno? Per me è indifferente, purché si affidi al bot questo lavoro che attualmente è svolto da umani sprecando inutilmente risorse. Informaticamente parlando è meglio la data fissa, però per tagliare la testa al toro, farei prendere come riferimento la data dell'ultima riconferma in modo che se si anticipa per qualche motivo - non si sono mai anticipate con troppa leggerezza, eviterei di perdere tempo su questo punto; in ogni caso anticipare non nuoce a nessuno per cui è una leggerezza dai toni piuttosto annacquati - l'anno dopo ci si allinea automaticamente sulla nuova data. E' più probabile che se uno non può rispondere in un periodo X, non lo possa fare anche l'anno dopo piuttosto del contrario, direi. Tanto più che è come si è fatto fin ora. --.avgas13:04, 10 apr 2019 (CEST)[rispondi]
Dunque... Riguardo alle votazioni di riconferma, vedo due possibilità: 1 - si modificano le regole e non si fanno slittare le riconferme (cosa che non mi piace molto) 2- si usa il parametro di cui parlavo sopra per impostare una nuova data, dato che le votazioni di riconferma sono un evento abbastanza raro. Sto appunto implementando il parametro in questione, però ripeto che a mio avviso occorre parsimonia... IMHO il solo fatto che sia una data non accessibile non basta: se proprio l'admin ci tiene a dire qualcosa (o altri utenti vogliono tanto fargli domande che richiedono risposta urgente), ci sono tutti gli altri giorni dell'anno per farlo. Faccio inoltre un'altra precisazione. Non è nello scopo di questa discussione stabilire se siano giusti 365 giorni, 372 o qualsiasi altra quantità, a mio avviso anzi non fa differenza. Il succo della proposta è che se anziché 372 ne scegliamo 365, diventa molto più facile gestire le riconferme in automatico, al di là di quanto un numero possa essere più bello o più adatto di un altro. [@ .avgas] In realtà ciò che dici è possibile con l'implementazione che sto portando avanti. Se si vuole uno shift permanente, c'è un parametro apposito che permette di anticipare tutte le riconferme future. Allinearsi alla data di ultima riconferma richiederebbe comunque di avere una lista con le date delle ultime riconferme, per questo proponevo di tornare alla data di flag. --Daimona Eaytoy(Scrivimi!)14:11, 10 apr 2019 (CEST)[rispondi]
[← Rientro][↓↑ fuori crono][@ Daimona Eaytoy], capisco benissimo, ma imho è un inutile livello di complessità. Posto che per me già le riconferme sono inutili, e non lo dico da oggi, se vedi sopra ci sono miei scritti di sette od otto anni fa che dicono le stesse cose (per ovvii motivi: se un sysop è bravo e non controverso non c'è bisogno di riconferma, se è problematico non si può tenere il dossier su di lui in frigo fino alla prossima riconferma, e se dovessero passare 11 mesi chi s'è visto s'è visto), a questo punto, visto che si è deciso di continuare a votare periodicamente se tenerci o meno un sysop una settimana in più in carica non è un vulnus più di quanto sarebbe tenerne uno inadatto un giorno di più. -- SERGIO(aka the Blackcat)15:31, 10 apr 2019 (CEST)[rispondi]
[↓↑ fuori crono][@ Blackcat] L'"inutile livello di complessità" è mantenere lo slittamento di una settimana. Per un bot, è molto più semplice se la riconferma inizia tutti gli anni lo stesso giorno. E se vogliamo automatizzare le riconferme, è ovvio che (entro certi limiti) bisogna utilizzare il metro di complessità della macchina e non dell'umano. Su quanto le riconferme possano essere utili ci sarebbe fin troppo da dire. Anzi, condivido quanto hai detto: se ci sono problemi con un admin, non bisogna certo aspettare la riconferma. Però come dicevo, è fuori dallo scopo di questa discussione. --Daimona Eaytoy(Scrivimi!)15:46, 10 apr 2019 (CEST)[rispondi]
[↓↑ fuori crono][@ Daimona Eaytoy], si può decidere di fare uno scaglionamento trimestrale, che per il primo anno anticipa o posticipa di 45 giorni la procedura di riconferma e a regime la annualizza: per esempio, se un admin scade tra il 15 novembre e il 15 febbraio la riconferma dura dal 1° al 14 gennaio (la fai lunnga 2 settimane per dare tempo a tutti di vedere tutte le riconferme del periodo), se scadono tra il 16 febbraio e il 15 maggio li rinnovi 1° al 14 aprile, tra il 16 maggio e il 15 agosto li rinnovi dal 1° al 14 luglio e tra il 16 agosto e il 15 novembre li rinnovi dal 1° al 14 ottobre. L'anno successivo hai tutto cadenzato e hai messo in campo una soluzione elegante. -- SERGIO(aka the Blackcat)16:43, 10 apr 2019 (CEST)[rispondi] PS e per i neoadmin hai due vie: o decidi che se sono eletti entrano in carica il primo giorno del trimestre successivo oppure vanno in riconferma la prima volta nel trimestre dove cade il primo anno dall'assunzione della carica.
Cerco di fare un riassunto delle "modifiche regolamentari" opportune ([@ Daimona Eaytoy] se sbaglio, correggimi):
La riconferma inizia ordinariamente nell'anniversario dell'ultima elezione a sysop, burocrate o CU;
Le votazioni di riconferma non rinviano più la data della successiva riconferma;
Anticipare la riconferma su richiesta dell'admin non ha effetti sulla data delle riconferme successive (che restano l'anniversario dell'elezione);
Un admin può chiedere di anticipare la riconferma una tantum o permanentemente;
Interim: nessuno! Il giorno di entrata in funzione del bot le date delle prossime riconferme vengono riportate indietro al primo anniversario di elezione;
Per quegli admin la cui data di prossima riconferma slitti nel passato si apre immediatamente una procedura di riconferma;
La cosa non ha influenza sulla data di riconferma dell'anno successivo.
Questo dovrebbe semplificare al massimo il compito di Daimona. Lo so che qualche admin potrebbe trovarsi a dover essere riconfermato due volte in pochi mesi: direi che ce ne possiamo fare una ragione; da un lato non credo che gli admin vivano la riconferma come il Giorno del Giudizio, dall'altro non credo che la Comunità aspetti coi fucili spianati tale giorno per impallinare il sysop di turno.
Obiezioni, controproposte ecc. sono benvenute, ma ricordiamo l'adagio (oltre che regola d'oro di ogni ingegnere): l'ottimo è nemico del bene!--Equoreo (msg) 14:59, 10 apr 2019 (CEST)[rispondi]
[@ Equoreo] Grazie per il riassunto! Direi che è tutto corretto, tranne:
Per le votazioni di riconferma, c'è anche l'alternativa che possano continuare a rinviare la data (cioè non cambiare nulla) utilizzando il parametro per lo spostamento permanente
(Puntigliosità) nel pratico è equivalente, ma la data prescelta non è "l'ultima tra elezione a sysop, burocrate o CU", ma "l'ultima tra burocrate e CU, oppure sysop". Cioè se un utente fosse eletto prima CU e poi sysop (cosa da noi non possibile), conterebbe comunque la data di CU. In realtà, visto che (burocrate OR CU) => sysop, andrebbero rewordate le linee guida, ma pazienza, si tratta appunto di una puntigliosità.
Facendo partire il bot per gli allineamenti, alle date nel passato non succede nulla. La procedura viene semplicemente aperta il giorno stabilito dalle date di elezione. Quindi sì, potrebbe succedere che per un admin passi pochissimo tra una riconferma e la successiva, e per un altro passi più di un anno.
Era solo per semplificare le cose... casomai capitasse, dovremmo poi stare a ricordarci quali sono anticipi permanenti volontari, quali dovuti a votazione... Comunque, per me è lo stesso.
Buono a sapersi, ma appunto solo puntigliosità.
Immaginavo che il bot ignorasse tutte le date passate: andrebbero aperte a mano (oppure si pone un anticipo una tantum in tutti i casi necessari). Servirebbe per evitare ogni rischio di prolungamento oltre l'anno: facilmente si rischierebbe di avere admin con quasi due anni di "mandato" senza conferma (probabilmente irrilevante, ma ci coprirebbe da pretestuose polemiche su admin prorogati senza adeguata procedura comunitaria); insomma, il caro vecchio melius abundare quam deficere.--Equoreo (msg) 17:29, 10 apr 2019 (CEST)[rispondi]
Io sono favorevole, volevo solo proporre una possibilità aggiuntiva, visto che abbiamo i burocrati qui, nel caso qualcuno dovesse essere eletto sotto vacanze al posto di dover decidere l'anno dopo se anticipare solo una volta o per sempre non sarebbe più semplice proporgli, appena eletto, come alternativa di postporre l'attrlbuzione l'attribuzione del flag, di una decina di giorni per esempio, e far partire le riconferme non alla data dell'elezione ma dell'attribuzione del flag. --Pierpao.lo(listening)17:39, 10 apr 2019 (CEST)[rispondi]
[@ Equoreo] Per punti: 1 - Sì certo, diciamo però che non c'è una vera e propria proposta in quel senso, solo le due alternative possibili. 2 - Sì, senza dubbio. 3 - Questo secondo me va valutato prima di far partire il bot. Si fa una lista di quanto tempo passerebbe tra l'ultima riconferma admin e la prossima programmata dal bot, e si anticipano una tantum quelle con i tempi troppo lunghi. [@ Pierpao] Secondo me non sarebbe molto utile, sempre perché come sopra la riconferma non è l'unica occasione per parlare con un admin. Ma comunque, credo sia fuori dallo scopo di questa discussione. --Daimona Eaytoy(Scrivimi!)18:20, 10 apr 2019 (CEST)[rispondi]
Contrario Che qualcuno debba essere riconfermato due volte in pochi mesi mi pare del tutto inaccettabile. Ed anche avere un sacco di riconferme che partirebbero tutte assieme mi pare problematico. Se automatizzare le riconferme deve creare più problemi di quelli che risolve piuttosto lasciamole manuali e teniamoci il rischio che qualche riconferma parta in ritardo. --Jaqen[...]20:02, 10 apr 2019 (CEST)[rispondi]
[@ Jaqen] Il problema delle riconferma doppia si avrebbe solo il primo anno, per riassestare la situazione e portarla a regime. Dopo quell'unica volta non si avrebbe più nessun problema di questo genere.
Aggiungo solo un'altra cosa: il problema delle attuali riconferme eseguite a mano non è il rischio di far partire in ritardo qualche riconferma, ma la macchinosità del sistema. Sia l'avvio che la chiusura di una riconferma sono procedure lunghe e noiose, che fanno perdere inutilmente un sacco di tempo anche ai più esperti. Io ne ho aperta una una volta e ne ho chiusa un'altra un'altra volta e in entrambi i casi ho impiegato più di 20 minuti; con più esperienza ci vuole ovviamente meno tempo, ma è sempre comunque tempo buttato, che nell'ultimo anno o più si è sobbarcato quasi sempre [@ Sakretsu]--Parma198320:30, 10 apr 2019 (CEST)[rispondi]
[← Rientro][@ Jaqen] A mio avviso non è "del tutto inaccettabile", ma al massimo "fastidioso". Ma in ogni caso, per scansare eventuali dubbi, ho preparato una lista degli slittamenti assoluti basandomi su quella cassettata sopra. Il risultato è qui sotto. Per ogni utente, vengono riportati i giorni di differenza tra quando il bot farebbe partire la prossima riconferma, e quando invece dovrebbe partire secondo la lista. Numeri negativi = anticipo, positivi = posticipo.
Differenze assolute date riconferma
%Pier%: -2
.avgas: -1
.mau.: -4
.snoopy.: 3
Abisys: -2
Alkalin: -2
Antonio1952: 1
Aplasia: -2
Archenzo: -177
Ary29: 46
Ask21: 219
BohemianRhapsody: -1
Bradipo Lento: -1
Bramfab: 104
Bultro: -4
Burgundo: 28
Carlomorino: -1
Castagna: 360
Caulfield: -1
Delfort: -1
Doc.mari: -1
Dr Zimbu: -3
Elwood: -2
Epìdosis: -1
Esculapio: 4
Eumolpo: -1
Eustace Bagge: -1
FeltriaUrbsPicta: -1
Fringio: -1
Gac: -304.04166666667
Guidomac: -13
Horcrux: -2
Ignisdelavega: -2
Ilario: -137.04166666667
IndyJr: -2
Jaqen: -19
Kal-El: 1
Klaudio: -1
KS: -11
L736E: 20
Laurentius: -11
Lepido: -3
Madaki: 75.958333333333
Marcok: -240.04166666667
MM: 7
MapiVanPelt: -2
Melos: -155.04166666667
Moroboshi: -2
Nicolabel: -1
Nubifer: -3
Osk: -6
Paginazero: -280.04166666667
Pequod76: -1
Phantomas: 2
Phyrexian: -1
Pierpao: 1
Pil56: 14
RanZag: -3
Remulazz: -3
Roberto Mura: 74
Rojelio: -5
Ruthven: 6
Sannita: -21
Sanremofilo: -4
Shivanarayana: 1
Soprano71: 7.0416666666667
Superchilum: 7
Supernino: -4
Syrio: -2
Threecharlie: -3
Tirinto: -15
Tooby: -28.958333333333
Torsolo: -25.958333333333
Vale93b: -1
Valepert: -1
Veneziano: -2
Vituzzu: 1
Yiyi: -2
Al di là del fatto che lo script è grezzo, che la lista sopra potrebbe contenere errori, e che alcuni sono decimali a causa del bisestile: non vedo problemi per la stragrande maggioranza degli admin. Per comodità di lettura riporto sotto la lista dei soli admin per cui la differenza è, in valore assoluto, maggiore di 10 giorni.
Slittamenti superiori ai 10 giorni
Archenzo: -177
Ary29: 46
Ask21: 219
Bramfab: 104
Burgundo: 28
Castagna: 360
Gac: -304.04166666667
Guidomac: -13
Ilario: -137.04166666667
Jaqen: -19
KS: -11
L736E: 20
Laurentius: -11
Madaki: 75.958333333333
Marcok: -240.04166666667
Melos: -155.04166666667
Paginazero: -280.04166666667
Pil56: 14
Roberto Mura: 74
Sannita: -21
Tirinto: -15
Tooby: -28.958333333333
Torsolo: -25.958333333333
E per ancor più comodità, quelli superiori al mese
Slittamenti superiori al mese
Archenzo: -177
Ary29: 46
Ask21: 219
Bramfab: 104
Castagna: 360
Gac: -304.04166666667
Ilario: -137.04166666667
Madaki: 75.958333333333
Marcok: -240.04166666667
Melos: -155.04166666667
Paginazero: -280.04166666667
Roberto Mura: 74
Prendendo per buoni dati e calcolo, sono 11 persone (quello di Castagna è un FP dovuto all'imminente riconferma, in realtà sono 6 giorni) che per iniziare si possono gestire a mano. --Daimona Eaytoy(Scrivimi!)20:32, 10 apr 2019 (CEST)[rispondi]
Mi accorgo solo ora di aver sbagliato i conti: questi sarebbero i risultati se continuassimo a tenere gli slittamenti di una settimana. Rifarò il conto, probabilmente domani. --Daimona Eaytoy(Scrivimi!)21:14, 10 apr 2019 (CEST)[rispondi]
Comunque io da informatico (o presunto tale) non posso che essere estremamente Favorevole alla proposta di Daimona Eaytoy. Se lo "slittamento" fosse fastidioso, invece del reset alla data di PRIMO rinnovo, si potrebbe utilizzare la data di ULTIMO rinnovo, così tutto resterebbe in passo di un anno a partire da "ora". --Lepido (msg) 23:38, 10 apr 2019 (CEST)[rispondi]
[× Conflitto di modifiche] Perdonatemi se non leggo tutto e se questa domanda è già stata fatta, ma qual è il problema di riconfermare i vecchi admin secondo la loro ultima data di riconferma invece che quella di elezione? edit: ecco, [@ Lepido] mi ha preceduto e si è spiegato pure meglio :-)--Sakretsu (炸裂) 23:41, 10 apr 2019 (CEST)[rispondi]
[@ Lepido] Lì entra in gioco la proposta di utilizzare tutti gli anni la data del flag, così da non dover calcolare shift progressivi di una settimana. Comunque ho ricalcolato gli shift con il nuovo sistema, che metto qui sotto.
Prossima riconferma via bot vs attuale
%Pier%: Prossima ric. 03 December 2019 anziché 20 February 2020 (anticipata di 79 giorni)
.avgas: Prossima ric. 19 November 2019 anziché 27 November 2019 (anticipata di 8 giorni)
.mau.: Prossima ric. 21 November 2019 anziché 24 February 2020 (anticipata di 95 giorni)
.snoopy.: Prossima ric. 28 October 2019 anziché 17 January 2020 (anticipata di 81 giorni)
Abisys: Prossima ric. 31 July 2019 anziché 16 August 2019 (anticipata di 16 giorni)
Ale Sasso: Prossima ric. 29 March 2020 anziché 26 April 2019 (posticipata di 338 giorni)
Alkalin: Prossima ric. 22 February 2020 anziché 07 April 2020 (anticipata di 45 giorni)
Amarvudol: Prossima ric. 07 March 2020 anziché 28 March 2020 (anticipata di 21 giorni)
Antonio1952: Prossima ric. 18 May 2019 anziché 24 May 2019 (anticipata di 6 giorni)
Aplasia: Prossima ric. 29 October 2019 anziché 12 December 2019 (anticipata di 44 giorni)
Archenzo: Prossima ric. 08 July 2019 anziché 08 April 2020 (anticipata di 275 giorni)
ArtAttack: Prossima ric. 07 June 2019 anziché 14 June 2019 (anticipata di 7 giorni)
Ary29: Prossima ric. 20 November 2019 anziché 28 December 2019 (anticipata di 38 giorni)
Ask21: Prossima ric. 27 January 2020 anziché 11 August 2019 (posticipata di 169 giorni)
BohemianRhapsody: Prossima ric. 05 December 2019 anziché 17 January 2020 (anticipata di 43 giorni)
Bradipo Lento: Prossima ric. 12 May 2019 anziché 27 May 2019 (anticipata di 15 giorni)
Bramfab: Prossima ric. 11 May 2019 anziché 14 April 2019 (posticipata di 27 giorni)
Buggia: Prossima ric. 01 March 2020 anziché 29 March 2020 (anticipata di 28 giorni)
Bultro: Prossima ric. 07 August 2019 anziché 20 October 2019 (anticipata di 74 giorni)
Burgundo: Prossima ric. 10 May 2019 anziché 28 June 2019 (anticipata di 49 giorni)
Carlomartini86: Prossima ric. 14 April 2019 anziché 28 April 2019 (anticipata di 14 giorni)
Carlomorino: Prossima ric. 14 June 2019 anziché 13 July 2019 (anticipata di 29 giorni)
Castagna: Prossima ric. 22 February 2020 anziché 18 April 2019 (posticipata di 310 giorni)
Caulfield: Prossima ric. 13 June 2019 anziché 12 July 2019 (anticipata di 29 giorni)
Ceppicone: Prossima ric. 25 June 2019 anziché 25 June 2019 (posticipata di 0 giorni)
Civvì: Prossima ric. 06 February 2020 anziché 20 February 2020 (anticipata di 14 giorni)
Daimona Eaytoy: Prossima ric. 15 September 2019 anziché 22 September 2019 (anticipata di 7 giorni)
Dan Kenshi: Prossima ric. 13 January 2020 anziché 20 January 2020 (anticipata di 7 giorni)
Delfort: Prossima ric. 28 April 2019 anziché 10 June 2019 (anticipata di 43 giorni)
Dimitrij Kasev: Prossima ric. 19 March 2020 anziché 02 April 2020 (anticipata di 14 giorni)
Doc.mari: Prossima ric. 09 December 2019 anziché 31 December 2019 (anticipata di 22 giorni)
Dome: Prossima ric. 25 March 2020 anziché 13 May 2019 (posticipata di 317 giorni)
Dr Zimbu: Prossima ric. 12 November 2019 anziché 17 January 2020 (anticipata di 66 giorni)
Elwood: Prossima ric. 20 February 2020 anziché 05 April 2020 (anticipata di 45 giorni)
Epìdosis: Prossima ric. 08 January 2020 anziché 30 January 2020 (anticipata di 22 giorni)
Equoreo: Prossima ric. 10 January 2020 anziché 10 January 2020 (posticipata di 0 giorni)
Er Cicero: Prossima ric. 20 July 2019 anziché 24 August 2019 (anticipata di 35 giorni)
Erinaceus: Prossima ric. 14 May 2019 anziché 21 May 2019 (anticipata di 7 giorni)
Esculapio: Prossima ric. 12 September 2019 anziché 01 December 2019 (anticipata di 80 giorni)
Eumolpo: Prossima ric. 14 April 2019 anziché 27 May 2019 (anticipata di 43 giorni)
Euphydryas: Prossima ric. 20 January 2020 anziché 03 February 2020 (anticipata di 14 giorni)
Eustace Bagge: Prossima ric. 20 May 2019 anziché 25 June 2019 (anticipata di 36 giorni)
Fabyrav: Prossima ric. 28 March 2020 anziché 04 April 2020 (anticipata di 7 giorni)
FeltriaUrbsPicta: Prossima ric. 20 July 2019 anziché 11 August 2019 (anticipata di 22 giorni)
Fringio: Prossima ric. 29 September 2019 anziché 14 October 2019 (anticipata di 15 giorni)
Gac: Prossima ric. 16 February 2020 anziché 10 February 2020 (posticipata di 6 giorni)
Gianfranco: Prossima ric. 06 July 2019 anziché 20 July 2019 (anticipata di 14 giorni)
Guidomac: Prossima ric. 21 January 2020 anziché 07 April 2020 (anticipata di 77 giorni)
Horcrux: Prossima ric. 15 May 2019 anziché 14 June 2019 (anticipata di 30 giorni)
Hypergio: Prossima ric. 09 August 2019 anziché 23 August 2019 (anticipata di 14 giorni)
Ignisdelavega: Prossima ric. 17 September 2019 anziché 28 November 2019 (anticipata di 72 giorni)
Ilario: Prossima ric. 13 June 2019 anziché 27 January 2020 (anticipata di 228 giorni)
IndyJr: Prossima ric. 03 February 2020 anziché 19 March 2020 (anticipata di 45 giorni)
Jaqen: Prossima ric. 17 May 2019 anziché 21 August 2019 (anticipata di 96 giorni)
Kal-El: Prossima ric. 26 January 2020 anziché 25 January 2020 (posticipata di 1 giorni)
Kirk39: Prossima ric. 04 December 2019 anziché 11 December 2019 (anticipata di 7 giorni)
Klaudio: Prossima ric. 28 October 2019 anziché 21 January 2020 (anticipata di 85 giorni)
KS: Prossima ric. 20 May 2019 anziché 16 August 2019 (anticipata di 88 giorni)
L736E: Prossima ric. 06 December 2019 anziché 28 December 2019 (anticipata di 22 giorni)
Laurentius: Prossima ric. 24 September 2019 anziché 28 December 2019 (anticipata di 95 giorni)
Lepido: Prossima ric. 27 July 2019 anziché 17 September 2019 (anticipata di 52 giorni)
M&A: Prossima ric. 02 October 2019 anziché 09 October 2019 (anticipata di 7 giorni)
Madaki: Prossima ric. 29 December 2019 anziché 21 January 2020 (anticipata di 23 giorni)
MapiVanPelt: Prossima ric. 06 January 2020 anziché 05 February 2020 (anticipata di 30 giorni)
Marcok: Prossima ric. 20 February 2020 anziché 17 January 2020 (posticipata di 34 giorni)
Melos: Prossima ric. 08 April 2020 anziché 12 November 2019 (posticipata di 148 giorni)
Melquíades: Prossima ric. 10 January 2020 anziché 10 January 2020 (posticipata di 0 giorni)
Mess: Prossima ric. 26 April 2019 anziché 03 May 2019 (anticipata di 7 giorni)
MM: Prossima ric. 31 August 2019 anziché 16 November 2019 (anticipata di 77 giorni)
Moroboshi: Prossima ric. 12 May 2019 anziché 18 June 2019 (anticipata di 37 giorni)
Narayan89: Prossima ric. 22 January 2020 anziché 12 March 2020 (anticipata di 50 giorni)
Nicolabel: Prossima ric. 27 April 2019 anziché 16 June 2019 (anticipata di 50 giorni)
Nubifer: Prossima ric. 10 December 2019 anziché 17 January 2020 (anticipata di 38 giorni)
Ombra: Prossima ric. 31 March 2020 anziché 07 April 2020 (anticipata di 7 giorni)
Osk: Prossima ric. 28 April 2019 anziché 06 July 2019 (anticipata di 69 giorni)
Paginazero: Prossima ric. 12 January 2020 anziché 17 January 2020 (anticipata di 5 giorni)
Parma1983: Prossima ric. 15 September 2019 anziché 22 September 2019 (anticipata di 7 giorni)
Pequod76: Prossima ric. 27 April 2019 anziché 19 May 2019 (anticipata di 22 giorni)
Phantomas: Prossima ric. 20 January 2020 anziché 05 April 2020 (anticipata di 76 giorni)
Phyrexian: Prossima ric. 20 April 2019 anziché 19 May 2019 (anticipata di 29 giorni)
Pierpao: Prossima ric. 19 July 2019 anziché 25 July 2019 (anticipata di 6 giorni)
Pil56: Prossima ric. 27 November 2019 anziché 12 February 2020 (anticipata di 77 giorni)
RanZag: Prossima ric. 28 July 2019 anziché 25 September 2019 (anticipata di 59 giorni)
Remulazz: Prossima ric. 08 November 2019 anziché 27 January 2020 (anticipata di 80 giorni)
Retaggio: Prossima ric. 03 May 2019 anziché 10 May 2019 (anticipata di 7 giorni)
Ripepette: Prossima ric. 17 December 2019 anziché 04 March 2020 (anticipata di 78 giorni)
Roberto Mura: Prossima ric. 31 August 2019 anziché 20 August 2019 (posticipata di 11 giorni)
Rojelio: Prossima ric. 31 December 2019 anziché 29 March 2020 (anticipata di 89 giorni)
Ruthven: Prossima ric. 30 August 2019 anziché 31 August 2019 (anticipata di 1 giorni)
Sakretsu: Prossima ric. 08 August 2019 anziché 15 August 2019 (anticipata di 7 giorni)
Sannita: Prossima ric. 28 January 2020 anziché 05 May 2019 (posticipata di 268 giorni)
Sanremofilo: Prossima ric. 27 November 2019 anziché 05 January 2020 (anticipata di 39 giorni)
Shivanarayana: Prossima ric. 30 January 2020 anziché 26 February 2020 (anticipata di 27 giorni)
Soprano71: Prossima ric. 03 September 2019 anziché 29 October 2019 (anticipata di 56 giorni)
Superchilum: Prossima ric. 16 July 2019 anziché 10 September 2019 (anticipata di 56 giorni)
Supernino: Prossima ric. 02 June 2019 anziché 11 July 2019 (anticipata di 39 giorni)
Syrio: Prossima ric. 27 March 2020 anziché 03 May 2019 (posticipata di 329 giorni)
Threecharlie: Prossima ric. 23 December 2019 anziché 13 February 2020 (anticipata di 52 giorni)
Tirinto: Prossima ric. 02 October 2019 anziché 28 November 2019 (anticipata di 57 giorni)
Tooby: Prossima ric. 22 November 2019 anziché 14 March 2020 (anticipata di 113 giorni)
Torsolo: Prossima ric. 22 November 2019 anziché 11 March 2020 (anticipata di 110 giorni)
Vale93b: Prossima ric. 18 April 2019 anziché 10 May 2019 (anticipata di 22 giorni)
Valepert: Prossima ric. 18 July 2019 anziché 06 September 2019 (anticipata di 50 giorni)
Valerio Bozzolan: Prossima ric. 28 March 2020 anziché 04 April 2020 (anticipata di 7 giorni)
ValterVB: Prossima ric. 14 April 2019 anziché 28 April 2019 (anticipata di 14 giorni)
Vegetable: Prossima ric. 26 November 2019 anziché 10 December 2019 (anticipata di 14 giorni)
Veneziano: Prossima ric. 19 November 2019 anziché 30 January 2020 (anticipata di 72 giorni)
Vituzzu: Prossima ric. 31 May 2019 anziché 13 June 2019 (anticipata di 13 giorni)
Yiyi: Prossima ric. 21 December 2019 anziché 27 January 2020 (anticipata di 37 giorni)
E come sopra, per facilità di consultazione:
Riconferme con più di un mese di differenza
%Pier%: Prossima ric. 03 December 2019 anziché 20 February 2020 (anticipata di 79 giorni)
.mau.: Prossima ric. 21 November 2019 anziché 24 February 2020 (anticipata di 95 giorni)
.snoopy.: Prossima ric. 28 October 2019 anziché 17 January 2020 (anticipata di 81 giorni)
Ale Sasso: Prossima ric. 29 March 2020 anziché 26 April 2019 (posticipata di 338 giorni)
Alkalin: Prossima ric. 22 February 2020 anziché 07 April 2020 (anticipata di 45 giorni)
Aplasia: Prossima ric. 29 October 2019 anziché 12 December 2019 (anticipata di 44 giorni)
Archenzo: Prossima ric. 08 July 2019 anziché 08 April 2020 (anticipata di 275 giorni)
Ary29: Prossima ric. 20 November 2019 anziché 28 December 2019 (anticipata di 38 giorni)
Ask21: Prossima ric. 27 January 2020 anziché 11 August 2019 (posticipata di 169 giorni)
BohemianRhapsody: Prossima ric. 05 December 2019 anziché 17 January 2020 (anticipata di 43 giorni)
Bultro: Prossima ric. 07 August 2019 anziché 20 October 2019 (anticipata di 74 giorni)
Burgundo: Prossima ric. 10 May 2019 anziché 28 June 2019 (anticipata di 49 giorni)
Castagna: Prossima ric. 22 February 2020 anziché 18 April 2019 (posticipata di 310 giorni)
Delfort: Prossima ric. 28 April 2019 anziché 10 June 2019 (anticipata di 43 giorni)
Dome: Prossima ric. 25 March 2020 anziché 13 May 2019 (posticipata di 317 giorni)
Dr Zimbu: Prossima ric. 12 November 2019 anziché 17 January 2020 (anticipata di 66 giorni)
Elwood: Prossima ric. 20 February 2020 anziché 05 April 2020 (anticipata di 45 giorni)
Er Cicero: Prossima ric. 20 July 2019 anziché 24 August 2019 (anticipata di 35 giorni)
Esculapio: Prossima ric. 12 September 2019 anziché 01 December 2019 (anticipata di 80 giorni)
Eumolpo: Prossima ric. 14 April 2019 anziché 27 May 2019 (anticipata di 43 giorni)
Eustace Bagge: Prossima ric. 20 May 2019 anziché 25 June 2019 (anticipata di 36 giorni)
Guidomac: Prossima ric. 21 January 2020 anziché 07 April 2020 (anticipata di 77 giorni)
Ignisdelavega: Prossima ric. 17 September 2019 anziché 28 November 2019 (anticipata di 72 giorni)
Ilario: Prossima ric. 13 June 2019 anziché 27 January 2020 (anticipata di 228 giorni)
IndyJr: Prossima ric. 03 February 2020 anziché 19 March 2020 (anticipata di 45 giorni)
Jaqen: Prossima ric. 17 May 2019 anziché 21 August 2019 (anticipata di 96 giorni)
Klaudio: Prossima ric. 28 October 2019 anziché 21 January 2020 (anticipata di 85 giorni)
KS: Prossima ric. 20 May 2019 anziché 16 August 2019 (anticipata di 88 giorni)
Laurentius: Prossima ric. 24 September 2019 anziché 28 December 2019 (anticipata di 95 giorni)
Lepido: Prossima ric. 27 July 2019 anziché 17 September 2019 (anticipata di 52 giorni)
Marcok: Prossima ric. 20 February 2020 anziché 17 January 2020 (posticipata di 34 giorni)
Melos: Prossima ric. 08 April 2020 anziché 12 November 2019 (posticipata di 148 giorni)
MM: Prossima ric. 31 August 2019 anziché 16 November 2019 (anticipata di 77 giorni)
Moroboshi: Prossima ric. 12 May 2019 anziché 18 June 2019 (anticipata di 37 giorni)
Narayan89: Prossima ric. 22 January 2020 anziché 12 March 2020 (anticipata di 50 giorni)
Nicolabel: Prossima ric. 27 April 2019 anziché 16 June 2019 (anticipata di 50 giorni)
Nubifer: Prossima ric. 10 December 2019 anziché 17 January 2020 (anticipata di 38 giorni)
Osk: Prossima ric. 28 April 2019 anziché 06 July 2019 (anticipata di 69 giorni)
Phantomas: Prossima ric. 20 January 2020 anziché 05 April 2020 (anticipata di 76 giorni)
Pil56: Prossima ric. 27 November 2019 anziché 12 February 2020 (anticipata di 77 giorni)
RanZag: Prossima ric. 28 July 2019 anziché 25 September 2019 (anticipata di 59 giorni)
Remulazz: Prossima ric. 08 November 2019 anziché 27 January 2020 (anticipata di 80 giorni)
Ripepette: Prossima ric. 17 December 2019 anziché 04 March 2020 (anticipata di 78 giorni)
Rojelio: Prossima ric. 31 December 2019 anziché 29 March 2020 (anticipata di 89 giorni)
Sannita: Prossima ric. 28 January 2020 anziché 05 May 2019 (posticipata di 268 giorni)
Sanremofilo: Prossima ric. 27 November 2019 anziché 05 January 2020 (anticipata di 39 giorni)
Soprano71: Prossima ric. 03 September 2019 anziché 29 October 2019 (anticipata di 56 giorni)
Superchilum: Prossima ric. 16 July 2019 anziché 10 September 2019 (anticipata di 56 giorni)
Supernino: Prossima ric. 02 June 2019 anziché 11 July 2019 (anticipata di 39 giorni)
Syrio: Prossima ric. 27 March 2020 anziché 03 May 2019 (posticipata di 329 giorni)
Threecharlie: Prossima ric. 23 December 2019 anziché 13 February 2020 (anticipata di 52 giorni)
Tirinto: Prossima ric. 02 October 2019 anziché 28 November 2019 (anticipata di 57 giorni)
Tooby: Prossima ric. 22 November 2019 anziché 14 March 2020 (anticipata di 113 giorni)
Torsolo: Prossima ric. 22 November 2019 anziché 11 March 2020 (anticipata di 110 giorni)
Valepert: Prossima ric. 18 July 2019 anziché 06 September 2019 (anticipata di 50 giorni)
Veneziano: Prossima ric. 19 November 2019 anziché 30 January 2020 (anticipata di 72 giorni)
Yiyi: Prossima ric. 21 December 2019 anziché 27 January 2020 (anticipata di 37 giorni)
Riconferme con più di 3 mesi di differenza
.mau.: Prossima ric. 21 November 2019 anziché 24 February 2020 (anticipata di 95 giorni)
Ale Sasso: Prossima ric. 29 March 2020 anziché 26 April 2019 (posticipata di 338 giorni)
Archenzo: Prossima ric. 08 July 2019 anziché 08 April 2020 (anticipata di 275 giorni)
Ask21: Prossima ric. 27 January 2020 anziché 11 August 2019 (posticipata di 169 giorni)
Castagna: Prossima ric. 22 February 2020 anziché 18 April 2019 (posticipata di 310 giorni)
Dome: Prossima ric. 25 March 2020 anziché 13 May 2019 (posticipata di 317 giorni)
Ilario: Prossima ric. 13 June 2019 anziché 27 January 2020 (anticipata di 228 giorni)
Jaqen: Prossima ric. 17 May 2019 anziché 21 August 2019 (anticipata di 96 giorni)
Laurentius: Prossima ric. 24 September 2019 anziché 28 December 2019 (anticipata di 95 giorni)
Melos: Prossima ric. 08 April 2020 anziché 12 November 2019 (posticipata di 148 giorni)
Sannita: Prossima ric. 28 January 2020 anziché 05 May 2019 (posticipata di 268 giorni)
Syrio: Prossima ric. 27 March 2020 anziché 03 May 2019 (posticipata di 329 giorni)
Tooby: Prossima ric. 22 November 2019 anziché 14 March 2020 (anticipata di 113 giorni)
Torsolo: Prossima ric. 22 November 2019 anziché 11 March 2020 (anticipata di 110 giorni)
Pertanto, la mia proposta è la seguente: gli shift sotto ai 3 mesi (sia in avanti che indietro) li direi tollerabili, dato che si tratterebbe di una distanza variabile tra i 9 e 15 mesi tra due riconferme. Per gli altri, si può risolvere caso per caso. Tendenzialmente, direi, utilizzando il parametro per anticipare le riconferme. --Daimona Eaytoy(Scrivimi!)09:21, 11 apr 2019 (CEST) P.S. Per quanto riguarda gli shift "grossi" (300+ giorni), un'idea sarebbe di far partire la riconferma "subito". Solo che, di questo passo, da ora a quando partirà il bot potrebbero presentarsi tempistiche e soluzioni diverse.[rispondi]
Proposta alternativa
Posto che le riconferme mi pare ci sia sempre l'idea che vengano mantenute, ma se ci semplificassimo la vita e facessimo tutte le riconferme nella stessa settimana. Potrà sembrare strano, ma se riescono a farlo in meta per le riconferme degli steward, per una procedura transwiki e per diritti degli utenti ben più rilevanti, non vedo perchè non importarlo qui, evitandoci tutte queste metodiche che, alla fine, risultano sempre un pochino macchinose. Se poi quell'anno, in quella riconferma, quel tale sysop proprio non ce la fa a essere presente per seguire la procedura, allora solo per quella volta si può anche anticipare, senza troppa WP:BUROCRAZIA. --Aplasia18:17, 10 apr 2019 (CEST)[rispondi]
Direi che sono spalmate più che altro perchè è una riconferma annuale e le date di candidatura/elezioni sono fondamentalmente casuali; è una situazione che è venuta a crearsi e non voluta, e lo si vede anche dalla distribuzione assolutamente non omogenea delle procedure. Considerando anche la partecipazione pregressa e la procedura tacita non vedo come potrebbe esserci realmente confusione. --Aplasia18:26, 10 apr 2019 (CEST)[rispondi]
Beh te parti dal presupposto che le riconferme vengano appunto riconfermate sempre, e quindi non necessitino di una discussione vera e propria, ma nel caso in cui sorgessero invece dei dubbi e si dovesse entrare eventualmente in votazione poi l'accavallamento di più procedure nella stessa settimana potrebbe creare un problema. È un'eventualità poco probabile, ma secondo me non vale la pena rischiare, tanto al bot credo che non faccia differenza una volta impostata una data fissa per ogni amministratore. --gothnespresso18:32, 10 apr 2019 (CEST)[rispondi]
Credo che il motivo per cui gli steward vengono confermati una volta all'anno sia legato anche al fatto che vengono eletti una volta all'anno, tutti concentrati nelle stesse settimane. Le riconferme poi durano 3 settimane di votazioni e un'ulteriore settimana (o più) di discussione da parte della Commissione elettorale, che deve decidere se riconfermare o meno. Un sistema nel complesso piuttosto macchinoso, che sinceramente preferirei evitare qui da noi per gli admin ;)--Parma198318:47, 10 apr 2019 (CEST)[rispondi]
Assolutamente contrario. Credo molto fiduciosamente che non succederà mai ma è inutile negarlo noi italiani siamo "calorosi" nelle discussioni;, immaginate due discussioni in contemporanea nella ipotesi assai improbabile ma possibile che due amministratori finiscano ai ferri corti. Già gestire una riconferma prima e poi l'altra sarebbe assai drammatico; figuriamoci in contemporanea--Pierpao.lo(listening)19:15, 10 apr 2019 (CEST)[rispondi]
Contrario Le riconferme tutte la stessa settimana avrebbero senso solo se gli admin fossero eletti tutti la stessa settimana. --Jaqen[...]20:05, 10 apr 2019 (CEST)[rispondi]
Ripartiamo da capo
Allora, riassumo qui quanto discusso sopra ad uso e consumo di chi si è perso o chi si vuole aggiungere alla discussione senza doversi leggere il mattone precedente. User:BotRiconferme è quasi pronto, e rimangono due problemi da risolvere prima di farlo partire:
Le riconferme slittano di una settimana ogni anno. Ovvero, se la mia riconferma quest'anno dura dal 5 al 12 aprile, l'anno prossimo inizia il 12 aprile.
Per circa 80 admin, in passato ci sono stati ulteriori slittamenti involontari, spesso dovuti alla dimenticanza di far partire la riconferma.
Ora, per il bot calcolare lo slittamento di cui al punto 1 non è banale. Inoltre, visto il problema del punto 2, calcolare gli slittamenti non sarebbe sufficiente per gli 80 admin che sono sfasati. L'unica soluzione sarebbe pertanto mantenere una lista delle ultime date di riconferma in JSON, da tenere costantemente aggiornata, cosa ancora una volta inutilmente dispendiosa e difficile da gestire. Pertanto, la mia proposta è la seguente:
Da ora in poi, TUTTE le riconferme iniziano lo stesso giorno di elezione (come scritto qui nelle prime tre righe), senza slittamenti;
Quando il bot verrà attivato, allineerà le riconferme di tutti gli admin, eliminando sia gli slittamenti di una settimana, sia quelli "involontari".
Seguono alcune precisazioni emerse in seguito a discussione:
Non si sta discutendo se sia più corretto un intervallo di 365 o 372 giorni tra due riconferme; nessuno dei due è di per sé preferibile, ma il primo è più semplice da gestire via bot;
In caso di comprovata necessità, un admin può richiedere l'anticipazione della sua riconferma (una tantum per la successiva o permanentemente), che sarà gestita in automatico dal bot;
In caso di votazione di revoca (e non votazione di riconferma), la riconferma sarà anticipata permanentemente a quella data nella configurazione del bot;
Nel momento in cui il bot verrà attivato e inizierà a riallineare le date, ogni admin sarà messo in riconferma NON dopo un anno esatto dall'ultima riconferma, ma un po' prima o un po' dopo; per avere un'idea dell'impatto di questo problema, ho creato una lista un po' grezza con la data prevista dal bot vs quella programmata (cercare cassetto "Prossima riconferma via bot vs attuale" e i due successivi). La proposta in questo caso è di allineare direttamente gli slittamenti inferiori ai tre mesi e di gestire caso per caso i rimanenti (circa una decina). Il modo esatto di gestire questi ultimi va deciso quando questa discussione sarà a buon punto, creando una lista più precisa.
Nota (aggiunta in seguito): Ho scovato un altro problema. Al momento, per CU, admin e burocrati si considera come data di elezione quella del termine della procedura, e non quella in cui si è ricevuto il flag. Nella maggioranza dei casi non ci sono differenze, ma in alcuni casi sì. Riporto in seguito quelli relativi agli admin.
Differenze elezione-flag
.mau.: 20/11/2005 - 21/11/2005
Abisys: 31/07/2016 - 01/08/2016
Antonio1952: 17/05/2017 - 18/05/2017
Bultro: 06/08/2008 - 07/08/2008
Kal-El: 25/01/2019 - 26/01/2019
Phantomas: 14/01/2008 - 20/01/2008
Pierpao: 18/07/2017 - 19/07/2017
Ripepette: 16/12/2007 - 17/12/2007
Sannita: 27/01/2007 - 28/01/2007
Tirinto: 16/10/2012 - 02/10/2012
Tooby: 09/12/2006 - 22/11/2006
Torsolo: 14/12/2006 - 22/11/2006
Vituzzu: 31/12/2007 - 01/01/2008
In questo caso, a maggior ragione, per il bot è discretamente più complesso cercare la data di elezione che non del flag. Dato che le differenze sono perlopiù minime (e che comunque, finché non riceve il flag uno non è a tutti gli effetti sysop/CU), propongo di aggiornare le linee guida e considerare come data quella del flag.
--Daimona Eaytoy(Scrivimi!)17:28, 11 apr 2019 (CEST) con l'aiuto di Parma1983[rispondi]
Scusate se faccio una domanda cretina, ma perchè il bot non può banalmente fare partire ogni riconferma 365 gionri dopo l'ultima, che motivo c'è per recuperare le discrasie passate?--Pierpao.lo(listening)17:58, 11 apr 2019 (CEST)[rispondi]
[@ Pierpao] Come ho già scritto un paio di volte sopra, ciò che dici è fattibile solo se, appunto, si ha una lista di 110 "ultime date". Il punto è: ma chi ce lo fa fare? Perché tenere una lista di 110 date non facile da aggiornare, difficile da vedere se sia corretta, e da aggiornare ogni volta che finisce una riconferma, oltre a dover scrivere altro codice per farlo? Con la proposta sopra ci si evitano sbattimenti del genere e le riconferme diventano più gestibili sia manualmente che automaticamente. --Daimona Eaytoy(Scrivimi!)18:03, 11 apr 2019 (CEST)[rispondi]
ho capito questo perché le date di nomina il bot le prende direttamente da log. Quindi concordo: la cosa più semplice é usare la data del primo flag e dimenticarci di quelle delle procedure. -- Pierpao
Scusate la domanda stupida: ma non è semplice tenere un log in stile file di testo, anche su una pagina su wiki, che il bot aggiorna automaticamente e da cui legge i dati? Se le riconferme le chiude in automatico non può semplicemente inserire come nuova riconferma la data corrente + 1 anno (chissene dei bisestili)? --Ripe (msg) 19:55, 11 apr 2019 (CEST)[rispondi]
[@ Ripepette] Vedi subito sopra cosa ho detto a Pierpao. Fare si può fare, ma chi ce lo fa fare? Forse sarebbe anche semplice, ma a mio avviso non ne vale la pena perché sarebbe difficile da mantenere. In ogni caso, è più semplice usare sempre la stessa data. E per più semplice intendo che non c'è da fare niente di nuovo, il bot è già programmato per farlo. Anzi, si toglierebbe anche la necessità di aggiornare WP:Amministratori/Lista ad ogni riconferma. Insomma, si taglierebbe la testa al toro su vari fronti. --Daimona Eaytoy(Scrivimi!)20:01, 11 apr 2019 (CEST)[rispondi]
Per me non è un problema, lo chiedevo solo perché ad occhio mi sembra più semplice fare questa modifica al codice che non trovare consenso qui ;) comunque, scherzi a parte, per me va bene un po' tutto, se togliamo lavoro agli umani tanto di guadagnato e amen per i particolari (anche se ad occhio mi sfugge la difficoltà nel mantenere una lista che si modifica in automatico, però appunto questo è un particolare) --Ripe (msg) 21:08, 11 apr 2019 (CEST)[rispondi]
Concordo con quanto scritto da Lepido e Sakretsu ieri (interventi delle 23:38 e delle 23:41 del 10 aprile): da oggi in avanti le riconferme possono anche non slittare più di una settimana ma, aggiungo, non si può pensare di azzerare lo slittamento che si è accumulato in 14 anni sconvolgendo 57 procedure. È il bot che deve essere al servizio della Comunità e non la Comunità al servizio del bot per cui, considerando anche che, in caso di elezione a CU o burocrate, la successiva riconferma deve ripartire dalla data del nuovo incarico, o il bot è in grado di gestire una tabella con la data di ultima elezione oppure, per quel che mi riguarda, sono Fortemente contrario/a. --Antonio1952 (msg) 21:47, 11 apr 2019 (CEST)[rispondi]
Io personalmente sono Favorevole. Fatico a capire perché sconvolgere (ellapeppa che paroloni!) 57 procedure dovrebbe essere un problema. Certo che se non fosse necessario sarebbe meglio, e certo che è il bot che lavora per noi e non viceversa, ma se con questo immane sacrificio possiamo aiutare il bot a lavorare per noi meglio, allora vada. --Syrioposso aiutare?23:29, 11 apr 2019 (CEST)[rispondi]
[← Rientro][@ Ripepette] "più semplice fare questa modifica al codice che non trovare consenso qui" Ha! Hai tanta, tanta ragione... Il punto è che vorrei fare un lavoro pulito e semplice da mantenere, evitando soluzioni temporanee e quant'altro. [@ Antonio1952] Sì, certo, il fatto è che la mia proposta, oltre a favorire il bot, favorisce anche la comunità. Perché oggettivamente, tra slittamenti di una settimana e slittamenti involontari, è venuto fuori un troiaio con le riconferme. Fare un po' di ordine riallineando tutto sarebbe benefico anche per gli umani, oltre che per le macchine. Inoltre, le date di CU/burocrate non le ho nominate perché il bot è già in grado di gestirle e di aggiornare la riconferma automaticamente: seguendo una regola! Non seguendo una lista le cui date sono letteralmente aleatorie. Ma soprattutto, straquoto [@ Syrio]: "sconvolgere" mi sembra davvero inadeguato in questo contesto. Voglio dire, stiamo parlando di procedure di riconferma che nella quasi totalità dei casi sono tranquille e semi-desertiche chiacchierate. Ancora una volta durante questa discussione, mi chiedo se si stia parlando di riconferme, oppure di maxi-udienze.--Daimona Eaytoy(Scrivimi!)10:15, 12 apr 2019 (CEST)[rispondi]
Favorevole come detto da altri ben venga l'automatizzazione di ciò che è ripetitivo e noioso. Favorevole a far coincidere la riconferma con la data di elezione: mi sembra la soluzione più razionale. Pazienza se per un anno molte delle riconferme saranno anticipate, dall'anno prossimo si torna a regime --Ombra10:31, 13 apr 2019 (CEST)[rispondi]
Come ho detto Favorevole; non è la data di elezione ma la data del primo flag che il bot appunto pesca dal sistema e non da una pagina scritta da noi; per questo è meglio, è meno sensibile ad errori umani. Infine il sistema forse sconvolge la procedura ma la procedura era in contraddzione con quanto scritto che la cadenza della riconferma è annuale. Annuale non è stata sia per la settimana sia per gli errori. Più o meno il bot pareggia i conti, e ciascuno dovrebbe (se non ho capito male) essere riconfermato esattamente un tot di anni dopo la prima flaggatura--Pierpao.lo(listening)13:33, 13 apr 2019 (CEST)[rispondi]
[@ Daimona Eaytoy], tre domande tecniche sul funzionamento del bot (da perfetto ignorante di linguaggi di programmazione):
Dove trova la data in cui far partire la riconferma tacita?
Come sa se, entro una settimana, sono stati raggiunti i 15 voti validi contrari per cui deve partire la votazione di riconferma?
Come sa se, al termine delle 2 settimane (o meglio delle 336 ore), è stato superato il quorum dei votanti e c'è stata un maggioranza di contrari superiore ad un terzo per cui si deve procedere alla revoca del sysop?
A partire da questa lista di date di elezione. Applicando la proposta di questa discussione, il bot deve semplicemente cercare il massimo di quelle tre date, e quello è il giorno di riconferma. Se la proposta non venisse approvata, ci vorrà un'ulteriore lista.
Qui ci sono tre risposte da dare: 1 - in realtà il bot non si pone il problema di "entro una settimana": guarda semplicemente se la procedura è aperta (e considera una procedura aperta se è inclusa in WP:Amministratori/Riconferma annuale). 2 - Il bot non controlla se i voti sono validi; volendo può farlo, ma per ora ho assunto che i voti saranno sempre validi. 3 - Riguardo al conteggio di per sé, il bot fa ciò che farebbe un umano: conta il numero di righe che iniziano con un cancelletto nella sezione dei voti (con due accorgimenti: che ci sia solo il cancelletto, e nessun altro carattere di inizio lista, ed escludendo il # ... di esempio).
Anche in questo caso, divido in tre: 1 - Il momento di termine della procedura è preciso al minuto e viene estratto dalla stringa "la votazione [...] ha termine il xxx alle yyy". 2 - Il quorum viene estratto dalla stringa di cui sopra, e viene confrontato con il conteggio dei voti favorevoli (ottenuto esattamente come quello dei contrari al punto 2); 3 - Avendo il conteggio di contrari e favorevoli, è immediato vedere se c'è la maggioranza di 2/3.
Visto che esiste una tabella perché non aggiungere, oltre a sysop, bureaucrat e checkuser, una casella tipo "Ultima riconferma manuale" (o con qualsivoglia altro titolo) in cui inserire la data dell'ultima riconferma con l'attuale sistema così da evitare gli inconvenienti di cui avevo parlato. Siccome siamo tutti d'accordo nel non far più slittare di una settimana le riconferme, la casella non servirebbe né per i quattro che sono alla prima riconferma né per i 13 come noi due che siamo alla seconda; tutti gli altri andrebbero in riconferma un anno dopo l'ultima; ad esempio, Archenzo dovrebbe avere nella nuova casella la data 08/04/19 e Ale Sasso il 26/04/18 (tanto per citare i casi estremi di proroga/anticipo).
I casi di voto non valido ci sono stati. Normalmente questi voti vengono rimossi o in corso di votazione o alla fine da parte di chi chiude la votazione; con il bot c'è il rischio che qualche voto dato in zona Cesarini possa falsare sia il caso di passaggio da tacita a votazione che l'esito della votazione. IMHO andrebbe introdotto qualche controllo "umano". --Antonio1952 (msg) 11:54, 15 apr 2019 (CEST)[rispondi]
[← Rientro][@ Antonio1952] La pagina in questione accetta già dei parametri aggiuntivi per anticipare la riconferma una tantum o permanentemente (vedi esempio). A mio avviso, tanto che siamo in ballo, vale la pena di ballare e standardizzare tutte le date. Nei casi estremi, ad esempio, si potrebbe dividere l'allineamento in 2: così, anziché anticipare di 180 giorni, si potrebbe anticipare di 90 giorni quest'anno, e 90 l'anno prossimo. Sono talmente pochi casi che a mio avviso il lavoro da fare è poco. Comunque fra qualche giorno, quando avrò risolto le altre questioni tecniche e burocratiche, cerco di stilare una nuova lista con le differenze tra date, però più precisa, così da decidere meglio il da farsi. Riguardo ai voti non validi, sì senz'altro il problema esiste. Ho scelto di non trattarlo principalmente per tre motivi: il primo è che comunque è facile accorgersi per un umano se un voto non è valido (e solitamente le votazioni di riconferma sono molto trafficate). Il secondo è che rimane comunque un evento raro, come dici: serve che il voto invalido venga inserito subito prima del passaggio del bot, e che quel singolo voto faccia la differenza tra tacita e votazione. Il terzo è che leggere la sintassi wiki non è sempre semplice per un bot, e rischia di non riuscire a capire di chi è il voto. Un compromesso potrebbe essere di far passare il bot meno spesso, ad es. ogni due ore anziché ogni mezz'ora (solo per quanto riguarda l'apertura delle votazioni), così da dare più tempo agli umani di strikkare eventuali voti non validi. --Daimona Eaytoy(Scrivimi!)12:05, 15 apr 2019 (CEST)[rispondi]
Uno scaglionamento regolare avrebbe molti vantaggi, fra cui assicurare equo trattamento a tutti e mettere finalmente a sopire le lamentele sulle riconferme in presunti periodi di stanca. Poi bisogna vedere i costi (cioè se sia più complicato da gestire). Nemo07:53, 16 apr 2019 (CEST)[rispondi]
Tiriamo le somme
La discussione è qui da un po' di tempo (riassunto: uno e due), di interventi ce ne sono stati tanti, direi che è giunto il momento di tirare le somme. Premetto che tralascio le proposte troppo "innovative" che cambierebbero radicalmente (o eliminerebbero del tutto) le riconferme: non rientrano negli scopi di questa discussione. Mi sembra che ci sia consenso sull'eliminazione della settimana "extra", che la possibilità di anticipare le riconferme sia stata implementata come richiesto, e che non sia un problema utilizzare la data di flag anziché quella di elezione (le differenze sono minime). L'unico punto più caldo sembra essere il riallineamento "forzato" delle riconferme. Ho quindi ricostruito da capo la lista degli slittamenti, che incollo qui sotto:
Slittamenti, lista definitiva
Carlomartini86: 14 April 2020 anziché 28 April 2019 (posticipo 352 giorni)
ValterVB: 14 April 2020 anziché 28 April 2019 (posticipo 352 giorni)
Bramfab: 11 May 2019 anziché 21 April 2020 (anticipo 346 giorni)
Vale93b: 18 April 2020 anziché 10 May 2019 (posticipo 344 giorni)
Ale Sasso: 29 March 2020 anziché 26 April 2019 (posticipo 338 giorni)
Phyrexian: 20 April 2020 anziché 19 May 2019 (posticipo 337 giorni)
Syrio: 27 March 2020 anziché 03 May 2019 (posticipo 329 giorni)
Eumolpo: 14 April 2020 anziché 27 May 2019 (posticipo 323 giorni)
Dome: 25 March 2020 anziché 13 May 2019 (posticipo 317 giorni)
Archenzo: 08 July 2019 anziché 08 April 2020 (anticipo 275 giorni)
Sannita: 28 January 2020 anziché 05 May 2019 (posticipo 268 giorni)
Ilario: 13 June 2019 anziché 27 January 2020 (anticipo 228 giorni)
Ask21: 27 January 2020 anziché 11 August 2019 (posticipo 169 giorni)
Melos: 09 April 2020 anziché 12 November 2019 (posticipo 149 giorni)
Tooby: 22 November 2019 anziché 14 March 2020 (anticipo 113 giorni)
Torsolo: 22 November 2019 anziché 11 March 2020 (anticipo 110 giorni)
Jaqen: 17 May 2019 anziché 21 August 2019 (anticipo 96 giorni)
Laurentius: 24 September 2019 anziché 28 December 2019 (anticipo 95 giorni)
.mau.: 21 November 2019 anziché 24 February 2020 (anticipo 95 giorni)
Rojelio: 31 December 2019 anziché 29 March 2020 (anticipo 89 giorni)
KS: 20 May 2019 anziché 16 August 2019 (anticipo 88 giorni)
Klaudio: 28 October 2019 anziché 21 January 2020 (anticipo 85 giorni)
Guidomac: 21 January 2020 anziché 14 April 2020 (anticipo 84 giorni)
.snoopy.: 28 October 2019 anziché 17 January 2020 (anticipo 81 giorni)
Esculapio: 12 September 2019 anziché 01 December 2019 (anticipo 80 giorni)
Remulazz: 08 November 2019 anziché 27 January 2020 (anticipo 80 giorni)
%Pier%: 03 December 2019 anziché 20 February 2020 (anticipo 79 giorni)
Ripepette: 17 December 2019 anziché 04 March 2020 (anticipo 78 giorni)
MM: 31 August 2019 anziché 16 November 2019 (anticipo 77 giorni)
Pil56: 27 November 2019 anziché 12 February 2020 (anticipo 77 giorni)
Phantomas: 20 January 2020 anziché 05 April 2020 (anticipo 76 giorni)
Bultro: 07 August 2019 anziché 20 October 2019 (anticipo 74 giorni)
Veneziano: 19 November 2019 anziché 30 January 2020 (anticipo 72 giorni)
Ignisdelavega: 17 September 2019 anziché 28 November 2019 (anticipo 72 giorni)
Osk: 28 April 2019 anziché 06 July 2019 (anticipo 69 giorni)
Dr Zimbu: 12 November 2019 anziché 17 January 2020 (anticipo 66 giorni)
RanZag: 29 July 2019 anziché 25 September 2019 (anticipo 58 giorni)
Tirinto: 02 October 2019 anziché 28 November 2019 (anticipo 57 giorni)
Soprano71: 03 September 2019 anziché 29 October 2019 (anticipo 56 giorni)
Superchilum: 16 July 2019 anziché 10 September 2019 (anticipo 56 giorni)
Castagna: 22 February 2020 anziché 18 April 2020 (anticipo 56 giorni)
Lepido: 27 July 2019 anziché 17 September 2019 (anticipo 52 giorni)
Threecharlie: 24 December 2019 anziché 13 February 2020 (anticipo 51 giorni)
Valepert: 18 July 2019 anziché 06 September 2019 (anticipo 50 giorni)
Nicolabel: 27 April 2019 anziché 16 June 2019 (anticipo 50 giorni)
Narayan89: 22 January 2020 anziché 12 March 2020 (anticipo 50 giorni)
Burgundo: 10 May 2019 anziché 28 June 2019 (anticipo 49 giorni)
Elwood: 20 February 2020 anziché 05 April 2020 (anticipo 45 giorni)
Alkalin: 22 February 2020 anziché 07 April 2020 (anticipo 45 giorni)
IndyJr: 03 February 2020 anziché 19 March 2020 (anticipo 45 giorni)
Aplasia: 29 October 2019 anziché 12 December 2019 (anticipo 44 giorni)
BohemianRhapsody: 05 December 2019 anziché 17 January 2020 (anticipo 43 giorni)
Delfort: 28 April 2019 anziché 10 June 2019 (anticipo 43 giorni)
Sanremofilo: 27 November 2019 anziché 05 January 2020 (anticipo 39 giorni)
Supernino: 02 June 2019 anziché 11 July 2019 (anticipo 39 giorni)
Ary29: 20 November 2019 anziché 28 December 2019 (anticipo 38 giorni)
Nubifer: 10 December 2019 anziché 17 January 2020 (anticipo 38 giorni)
Moroboshi: 12 May 2019 anziché 18 June 2019 (anticipo 37 giorni)
Yiyi: 21 December 2019 anziché 27 January 2020 (anticipo 37 giorni)
Eustace Bagge: 20 May 2019 anziché 25 June 2019 (anticipo 36 giorni)
Er Cicero: 20 July 2019 anziché 24 August 2019 (anticipo 35 giorni)
Marcok: 20 February 2020 anziché 17 January 2020 (posticipo 34 giorni)
Horcrux: 15 May 2019 anziché 14 June 2019 (anticipo 30 giorni)
MapiVanPelt: 06 January 2020 anziché 05 February 2020 (anticipo 30 giorni)
Caulfield: 13 June 2019 anziché 12 July 2019 (anticipo 29 giorni)
Carlomorino: 14 June 2019 anziché 13 July 2019 (anticipo 29 giorni)
Buggia: 01 March 2020 anziché 29 March 2020 (anticipo 28 giorni)
Shivanarayana: 30 January 2020 anziché 26 February 2020 (anticipo 27 giorni)
Madaki: 29 December 2019 anziché 21 January 2020 (anticipo 23 giorni)
FeltriaUrbsPicta: 20 July 2019 anziché 11 August 2019 (anticipo 22 giorni)
Doc.mari: 09 December 2019 anziché 31 December 2019 (anticipo 22 giorni)
L736E: 06 December 2019 anziché 28 December 2019 (anticipo 22 giorni)
Epìdosis: 08 January 2020 anziché 30 January 2020 (anticipo 22 giorni)
Pequod76: 28 April 2019 anziché 19 May 2019 (anticipo 21 giorni)
Amarvudol: 07 March 2020 anziché 28 March 2020 (anticipo 21 giorni)
Fringio: 29 September 2019 anziché 14 October 2019 (anticipo 15 giorni)
Bradipo Lento: 12 May 2019 anziché 27 May 2019 (anticipo 15 giorni)
Abisys: 01 August 2019 anziché 16 August 2019 (anticipo 15 giorni)
Civvì: 06 February 2020 anziché 20 February 2020 (anticipo 14 giorni)
Euphydryas: 20 January 2020 anziché 03 February 2020 (anticipo 14 giorni)
Valerio Bozzolan: 28 March 2020 anziché 11 April 2020 (anticipo 14 giorni)
Fabyrav: 28 March 2020 anziché 11 April 2020 (anticipo 14 giorni)
Ombra: 31 March 2020 anziché 14 April 2020 (anticipo 14 giorni)
Gianfranco: 06 July 2019 anziché 20 July 2019 (anticipo 14 giorni)
Hypergio: 09 August 2019 anziché 23 August 2019 (anticipo 14 giorni)
Vegetable: 26 November 2019 anziché 10 December 2019 (anticipo 14 giorni)
Dimitrij Kasev: 19 March 2020 anziché 02 April 2020 (anticipo 14 giorni)
Vituzzu: 31 May 2019 anziché 13 June 2019 (anticipo 13 giorni)
Roberto Mura: 31 August 2019 anziché 20 August 2019 (posticipo 11 giorni)
.avgas: 19 November 2019 anziché 27 November 2019 (anticipo 8 giorni)
ArtAttack: 07 June 2019 anziché 14 June 2019 (anticipo 7 giorni)
Daimona Eaytoy: 15 September 2019 anziché 22 September 2019 (anticipo 7 giorni)
Retaggio: 03 May 2019 anziché 10 May 2019 (anticipo 7 giorni)
Dan Kenshi: 13 January 2020 anziché 20 January 2020 (anticipo 7 giorni)
Sakretsu: 08 August 2019 anziché 15 August 2019 (anticipo 7 giorni)
Kirk39: 04 December 2019 anziché 11 December 2019 (anticipo 7 giorni)
Erinaceus: 14 May 2019 anziché 21 May 2019 (anticipo 7 giorni)
Parma1983: 15 September 2019 anziché 22 September 2019 (anticipo 7 giorni)
Mess: 26 April 2019 anziché 03 May 2019 (anticipo 7 giorni)
M&A: 02 October 2019 anziché 09 October 2019 (anticipo 7 giorni)
Pierpao: 19 July 2019 anziché 25 July 2019 (anticipo 6 giorni)
Antonio1952: 18 May 2019 anziché 24 May 2019 (anticipo 6 giorni)
Gac: 16 February 2020 anziché 10 February 2020 (posticipo 6 giorni)
Paginazero: 12 January 2020 anziché 17 January 2020 (anticipo 5 giorni)
Kal-El: 26 January 2020 anziché 25 January 2020 (posticipo 1 giorni)
Ruthven: Già OK al 31 August 2019
Ceppicone: Già OK al 25 June 2019
Equoreo: Già OK al 10 January 2020
Melquíades: Già OK al 10 January 2020
In realtà, gli slittamenti molto alti si possono vedere anche al contrario, pertanto la mia proposta è di forzare l'allineamento per tutte le differenze inferiori ai 100 giorni e procedere così per le altre.
(Nota: in "giorno xxx anziché yyy" si intende che il bot la farebbe partire nel giorno xxx, mentre la data attuale sarebbe yyy.)
Per i seguenti admin (con la differenza >260):
Carlomartini86: 14 April 2020 anziché 28 April 2019
ValterVB: 14 April 2020 anziché 28 April 2019
Vale93b: 18 April 2020 anziché 10 May 2019
Ale Sasso: 29 March 2020 anziché 26 April 2019
Phyrexian: 20 April 2020 anziché 19 May 2019
Syrio: 27 March 2020 anziché 03 May 2019
Eumolpo: 14 April 2020 anziché 27 May 2019
Dome: 25 March 2020 anziché 13 May 2019
quest'anno la facciamo partire il giorno già stabilito (la seconda data) e l'anno prossimo il bot la fa partire nella prima data.
Per i seguenti admin, quest'anno la facciamo partire in una data intermedia (riportata dopo ogni admin), l'anno prossimo in quella stabilita dal flag.
Ilario: 13 June 2019 anziché 27 January 2020 => 5 ottobre 2019
Ask21: 27 January 2020 anziché 11 August 2019 => 2 novembre 2019
Melos: 09 April 2020 anziché 12 November 2019 => 26 gennaio 2020
Tooby: 22 November 2019 anziché 14 March 2020 => 18 gennaio 2020
Torsolo: 22 November 2019 anziché 11 March 2020 => 16 gennaio 2020
Sannita: 28 January 2020 anziché 05 May 2019 => 16 settembre 2019
Archenzo: 08 July 2019 anziché 08 April 2020 => 22 novembre 2019
Unico caso "particolare" è
Bramfab: 11 May 2019 anziché 21 April 2020
per il quale direi di forzare comunque l'allineamento all'11 maggio 2020.
Chiaramente, tutti questi anticipi, posticipi, riallineamenti etc. saranno gestiti quasi completamente dal bot. L'unica cosa da fare a mano è inserire le nuove date una tantum nel JSON del bot, che le rimuoverà da solo dopo aver fatto partire la riconferma. Può andare? --Daimona Eaytoy(Scrivimi!)15:16, 23 apr 2019 (CEST)[rispondi]
Fortemente contrario/a Mi sfugge quale sia l'indiscutibile vantaggio nell'allineare le date di riconferma alla data del primo flag tenendo conto che per farlo dobbiamo accettare, ad esempio, che Archenzo vada in riconferma fra 2,5 mesi pur essendo stato riconfermato 15 giorni fa o che Vale93b, invece di andarci fra 15 giorni, ci vada fra 11 mesi e cioè 23 mesi dopo l'ultima riconferma.
[@ Antonio1952] Il vantaggio l'ho già spiegato varie volte più sopra: non servirebbe di mantenere una lista arbitraria di date. Personalmente non vedo una riconferma come un processo, quindi a me sembra totalmente "accettabile" uno slittamento di qualche mese. In effetti, finché si parla di pochi mesi, sono io a non capire dove sia il problema. Ciò detto, per Archenzo e Sannita c'era un errore nella lista sopra (slittamento troppo lungo) e ho provveduto a correggerlo. Quindi, ad esempio, Archenzo andrà in riconferma circa 8 mesi dopo la sua ultima riconferma, e quella successiva sarà circa altri 8 mesi dopo. Inoltre, come ho scritto sopra, Vale93b è uno di quegli admin per cui la proposta è: quest'anno la riconferma parte nel giorno già prefissato (per lui il 15 maggio), e l'anno prossimo nel giorno "voluto dal bot" (18 aprile). Quindi l'unico "slittamento" in questo caso è che ci sarà una distanza di 11 mesi tra due riconferme, e non di 23. Potresti cortesemente rivalutare il tuo parere alla luce di queste osservazioni? --Daimona Eaytoy(Scrivimi!)10:08, 24 apr 2019 (CEST)[rispondi]
Favorevole l'utilità è da oggi per sempre, eventuali inconvenienti sono solo per una manciata di riconferme attuali; una volta superate quelle, non c'è nessun problema. Davvero vogliamo bloccare un miglioramento a lungo termine per avere solo all'inizio delle procedure con giorni un po' sfasati rispetto al solito? KISS, dai. --Superchilum(scrivimi)11:54, 24 apr 2019 (CEST)[rispondi]
[× Conflitto di modifiche]Favorevole, mantenere una sola colonna di date è una soluzione fastidiosa nel primo anno, ma ottimale nel lungo periodo. Però anticiperei o posticiperei l'anno verificando se la differenza fra data giorno+mese dell'elezione e della ultima riconferma sia maggiore o minore di 6 mesi. In questo modo ci saranno admin che vengono riconfermati con 6 mesi di anticipo e altri con 6 mesi di ritardo, ma mi sembra un problema minore rispetto all'attendere quasi un anno in più e non bisognerà correggere arbitrariamente casi particolari. --Horcrux (msg) 12:00, 24 apr 2019 (CEST)[rispondi]
[↓↑ fuori crono][@ Daimona Eaytoy] e se facessimo di mese in mese? cosi avremmo [mese -> numero admin eletti] : 1 -> 11, 2 -> 6, 3 -> 7, 4 -> 7, 5 -> 10, 6 -> 8, 7 -> 11, 8 -> 3, 9 -> 9, 10 -> 6, 11 -> 10, 12 -> 13, cosi in agosto avremmo 3 riconferme, ed in dicembre massimo 12?? sarebbe un problema? --.snoopy.✉18:27, 24 apr 2019 (CEST)[rispondi]
Continua a non essermi per nulla chiaro perché la proposta di Antonio1952 sia così complicata tecnicamente. Poi beh, se la scelta deve essere per forza tra fare così e continuare a fare a mano, che si faccia così, ci mancherebbe. Però, se devo esprimermi su questa proposta, contatemi come contrario: dovrebbe essere il bot ad adattarsi alle richieste della comunità, non viceversa. --Ripe (msg) 13:31, 24 apr 2019 (CEST)[rispondi]
[↓↑ fuori crono]Commento: Quella che a me invece sfugge è la motivazione alla base di tanta ostilità nei confronti di questa proposta, che servirebbe solamente a semplificare le cose. In questi anni, senza che nessuno abbia protestato, a mano sono stati effettuati numerosi errori che, indipendentemente dagli slittamenti settimanali di anno in anno, hanno comportato spostamenti nelle riconferme nella maggior parte dei casi di pochi giorni, ma talvolta anche di 2 o 3 mesi (corrispondenti proprio ai casi in cui la correzione sarebbe più drastica). La lista che riporta le date di elezione ad admin/CU/burocrate sarebbe automaticamente gestita dal bot e contemporaneamente sarebbe immediatamente verificabile da chiunque; una lista che invece riportasse una serie di date di fatto casuali sarebbe molto meno gestibile da un bot e quindi soggetta a possibili errori, oltre che, in caso di necessità, molto più difficilmente verificabile. Io non sono un tecnico, ma mi pare ovvio che più le cose sono semplici più sia facile gestire un bot che già di suo, dovendo tener conto di numerose variabili, ha un'architettura sicuramente complessa. Dovendo quindi scegliere se semplificare le cose a fronte di un disagio una tantum o complicarle per sempre pur di evitare una volta quel disagio che nella stragrande maggioranza dei casi sarebbe minimo, non ho sinceramente alcun dubbio--Parma198314:41, 24 apr 2019 (CEST)[rispondi]
Ma non è che si richiede qualcosa di complicato, si tratta solo di associare a ogni admin una data (che si può pure lasciare fissa) diversa da quella di elezione. Una bazzeccola in confronto ad aver scritto lo script attuale. --Ripe (msg) 16:16, 24 apr 2019 (CEST)[rispondi]
[@ Ripepette] (rispondo anche al tuo altro commento sopra): non è complicato, semplicemente è più difficile da mantenere. In effetti, nessuno ci costringe a mantenere il listone di cui sopra quando si può usare ciò che è già stato scritto, che usa direttamente le date dei flag. Come avevo già detto un po' più sopra, non è solo una questione di facile/difficile, ma anche di semplice/difficile da mantenere e controllare. --Daimona Eaytoy(Scrivimi!)17:20, 24 apr 2019 (CEST)[rispondi]
Favorevole grande semplificazione, facciamo solo attenzione in questa fase transitoria alle riconferme che arriverebbero dopo più di un anno per evitare il problema che qualcuno possa chiedere su meta un deflag come era successo ad esempio quando ci eravamo dimenticati di avviare la riconferma a CU di Rojelio cosa che poi ovviamente siamo riusciti a bloccare aprendo subito la riconferma ma che può essere fastidioso. --Abisys (msg) 13:47, 24 apr 2019 (CEST)[rispondi]
Incerto, ma tendente al contrario: nel mio caso c'è un anticipo di un mesetto, al quale in linea teorica non sono contrario, dal 24 agosto al 20 luglio. Dal punto di vista pratico però mi dà piuttosto fastidio perché le mie ferie estive le faccio tradizionalmente nella seconda quindicina di luglio, in genere lontano da tutto e da tutti (wiki compresa, evidentemente), quindi durante la mia riconferma non avrei mai la possibilità di seguire la procedura, né di commentare e/o rispondere a eventuali richieste. Lo trovo assai limitante, se non addirittura controproducente. C'e soluzione? --Er Cicero14:41, 24 apr 2019 (CEST)[rispondi]
[@ Er Cicero] Questo problema è già stato evidenziato e risolto: in casi come questi uno può chiedere di anticipare una tantum o permanentemente la data della riconferma (così come si può fare già ora); il bot è già in grado di gestire queste eccezioni--Equoreo (msg) 14:46, 24 apr 2019 (CEST).[rispondi]
Incerto A naso mi sembra inutilmente complicato. Non è più semplice prendere le date attualmente presenti in tabella e fare per tutti "+365 giorni"? --Retaggio(msg)18:15, 24 apr 2019 (CEST)[rispondi]
[@ Retaggio] Al contrario! Per parlare nel pratico: questo è il pezzo di codice che determina la data di riconferma a partire dai flag. Certo, avendo una data fissa nella lista si potrebbe sostituire con una singola riga, ma al prezzo di dover aggiungere 1 - tutte le date attuali alla lista (e sono già 300 righe, quantitativamente parlando :D), 2-del codice che aggiorni tale lista in caso di elezione a burocrate o CU, che richiederebbe grossomodo la stessa quantità di codice di quello attuale. In più, come dicevo sopra, la lista arbitraria non è verificabile ed è più difficile da mantenere. --Daimona Eaytoy(Scrivimi!)18:26, 24 apr 2019 (CEST)[rispondi]
Ti credo senza dubbio alcuno che per la strutturazione del codice sia così, ma fare "+365 per tutti" rimane molto molto più semplice per la comprensione umana, per l'utilità e per il mantenimento del significato della procedura di riconferma... --Retaggio(msg)19:03, 24 apr 2019 (CEST)[rispondi]
[@ Retaggio] Però, se è solo per comprensibilità e si vuole avere una lista con tutte le date, il bot può generarla in un baleno, partendo dalle date di elezione come nella mia proposta. Anzi, in realtà una lista del genere andrà messa in WP:Amministratori/Lista, al posto delle colonne "ultima riconferma" e "prossima riconferma". A dire il vero, secondo me è abbastanza comprensibile anche da Utente:BotRiconferme/List.json: la data di riconferma è giorno/mese del flag riportato. Bisogna fare un max se ci sono anche burocrate e/o CU, ma sono pochi casi. --Daimona Eaytoy(Scrivimi!)19:54, 24 apr 2019 (CEST)[rispondi]
[@ Daimona Eaytoy] Io ho fatto due esempi a caso, se questi sono stati risolti ce ne sono comunque altri eclatanti tipo Phyrexian, Eumolpo e Dome che invece di andare in riconferma fra un mese ci vanno fra 11/12 mesi e quindi 22/23 mesi dopo la precedente riconferma. Poi ci sono i 7 del secondo elenco (Ilario ... Archenzo) che in due anni avrebbero 3 riconferme e i 46 la cui riconferma verrebbe anticipata da 1 a 3 mesi. Più approfondisco e più mi convinco che non ne vale la pena.
Dal punto di vista tecnico, se, come hai detto, il bot legge la data più alta nella tabella Utente:BotRiconferme/List.json non vedo quale sia il problema ad inserirvi le date dell'ultima riconferma, sarebbe un lavoro che si fa adesso e che non è più necessario aggiornare. Non vorrei che il problema nasca dal desiderio di far fare tutto al bot: il completamento della tabella si può benissimo fare a mano (io sono disponibile) senza bisogno di complicare il codice del bot, così come credo che a mano andranno aggiunte le eccezioni come quella richiesta più sopra da Er Cicero. --Antonio1952 (msg) 22:07, 24 apr 2019 (CEST)[rispondi]
Antonio scusa ma io non vedo dove sia il problema, è normale che quando si mettono a posto le cose ci siano delle discontinuità, ma è meglio gestirle non andando a fare accrocchi che poi si portano dietro negli anni. Che senso ha andare a scrivere del codice per gestire delle eccezioni che servono solo in questa fase di transizione, io sarei più contento fare adesso i salti adesso di qualche mese ma poi avere tutto in ordine per i prossimi 50 anni piuttosto andare ad inserire cose che poi ci portiamo dietro per sempre. Le cose semplici sono sempre quelle che durano di più e funzionano meglio. --Abisys (msg) 22:34, 24 apr 2019 (CEST)[rispondi]
[@ Abisys], le cose finora hanno funzionato non dico benissimo ma sicuramente bene. Infatti il tutto nasce dall'idea, sicuramente lodevole ma altrettanto sicuramente non scaturente da una problematicità, di automatizzare il sistema. Non vedo perché ci dobbiamo sobbarcare di un transitorio solo per evitare la differenza fra te che verresti sempre riconfermato nella data della tua ultima riconferma (16 agosto) ed io che verrei riconfermato sempre nella data del mio flag (18 maggio). --Antonio1952 (msg) 22:47, 24 apr 2019 (CEST)[rispondi]
Scusa Antonio ma sai che incombenza pazzesca ci dobbiamo sobbarcare :) cerchiamo di avere un po' di flessibilità e facciamo le cose per bene subito o non le facciamo per nulla. Ma mi sembra che sia lodevole l'idea quindi portiamola avanti nel modo corretto tecnicamente non mettiamo stampelle inutili. Il record corretto in WP è quello della data di nomina, non ne aggiungerei un altro, non che sia difficile farlo tecnicamente è che non è il modo corretto di procedere. Quando si fa una procedura si cerca sempre di evitarne le storture non strettamente necessarie. Il problema principale delle procedure bancarie, ad esempio, è stata quella di voler ad ogni costo garantire la massima continuità, il risultato è codice non più mantenibile e costi di gestione che fanno sì che sia più conveniente trasferire gli utenti e le nostre banche soffrono pesantemente l'aggressione di nuove strutture più dinamiche. Questo solo per darti la mia visione sul perché sia errato a mio avviso mettere mano al json anche se subito può sembrare la cosa più semplice del mondo. Poi questa è la mia visione da tecnico. --Abisys (msg) 23:11, 24 apr 2019 (CEST)[rispondi]
Però, come detto su, è il bot che dovrebbe andare incontro alle richieste della comunità e non viceversa, il "modo corretto" si deve decidere comunitariamente. Ora, per me automatizzare è senza dubbio conveniente, quindi se l'unico modo per farlo è così (e io critico questo aut aut), ok, si faccia così. Però imho è sbagliato proprio il modo di porsi, se la comunità fa una richiesta il bot dovrebbe venir programmato adeguatamente ad essa. La difficile manutenzione consiste nell'avere una lista in più che a ogni sysop associa una data, direi che il paragone con la gestione delle procedure bancarie è moolto esagerato :) comunque amen, si faccia così perché è inutile perderci chissà quanto tempo dietro, però il modo corretto di procedere non è questo --Ripe (msg) 23:36, 24 apr 2019 (CEST)[rispondi]
[← Rientro][@ Antonio1952] No, anche gli esempi che hai fatto sopra sono sbagliati. Per dirne uno, l'ultima riconferma di Dome è finita il 13 maggio 2018; come scritto a inizio sezione, la proposta nel suo caso (e idem per gli altri 7 nel primo elenco) è che quest'anno parte il 13 maggio (2019), l'anno prossimo il 25 marzo. Così i tempi tra due riconferme saranno rispettivamente di un anno esatto e 10 mesi e mezzo. Niente a che vedere con 22-23 mesi. Per gli altri sì, ci sarebbero 3 riconferme in due anni e slittamenti di 1-3 mesi, che però a mio avviso sono totalmente tollerabili perché piccoli. Il punto della mia proposta l'ha pienamente colto e spiegato Abisys: è un problema di metodo, non di difficoltà. [@ Ripepette] Ciò che dici sarebbe vero, però in questo caso il bot non è la causa, ma l'occasione. Nel senso, la semplificazione l'ho proposta perché sto scrivendo il bot, questo è vero. Tuttavia non semplifica la vita al bot, ma agli umani. Secondo me è una semplificazione che porta benefici alla comunità, con o senza bot. --Daimona Eaytoy(Scrivimi!)09:44, 25 apr 2019 (CEST)[rispondi]
(f.c.)[@ Daimona Eaytoy], scusa la pedanteria ma sopra hai scritto «Nota: in "giorno xxx anziché yyy" si intende che il bot la farebbe partire nel giorno xxx, mentre la data attuale sarebbe yyy.» e per Dome hai scritto «Dome: 25 March 2020 anziché 13 May 2019» per cui ne deduco che la riconferma di Dome dovrebbe partire il 25/03/2020 (giorno xxx) invece che il 13/05/2019 (giorno yyy). Poi se hai scritto una cosa diversa da quello che penseresti di fare è un errore tuo non mio! --Antonio1952 (msg) 15:49, 25 apr 2019 (CEST)[rispondi]
[↓↑ fuori crono][@ Antonio1952] Forse non mi sono spiegato: sì, la nota che dici c'è e si riferisce a tutte le liste. Però c'è scritto: "Per i seguenti admin (con la differenza >260): [... segue lista ...] quest'anno la facciamo partire il giorno già stabilito (la seconda data) e l'anno prossimo il bot la fa partire nella prima data." e analogamente per le due liste successive. --Daimona Eaytoy(Scrivimi!)16:49, 25 apr 2019 (CEST)[rispondi]
Per i seguenti admin (con la differenza >260):
[lista di 8 admin e delle date che dovrebbero essergli associate, fra cui Dome]
quest'anno la facciamo partire il giorno già stabilito (la seconda data) e l'anno prossimo il bot la fa partire nella prima data.
Quindi la prossima riconferma di Dome (e analogamente per gli altri: sono tutti quelli la cui riconferma cade a cavallo della riorganizzazione) sarebbe il 13 maggio 2019 (come è oggi), mentre la successiva il 25 marzo 2020 (riallineata).
Quello che non capisco è perchè tutta questa polemica per un periodo di transizione... Qual è il problema se una riconferma riparte per un solo anno sfasata rispetto all'anno precedente? C'è qualche admin che è così turbato dalla riconferma da aver bisogno di 365 giorni (non uno di meno) per riprendersi? Temiamo che se un admin venisse riconfermato dopo 14 mesi invece che 12 potrebbe sfruttare i due mesi extra per instaurare una dittatura? Abbiamo accettato per anni ritardi di giorni, settimane, mesi, perchè nessuno si prendeva la briga di far partire le riconferme e ora è una catastrofe cambiarne il ritmo per un anno? O forse siamo così affezionati ai nostri cavilli che, quando spunta l'occasione, piuttosto che aggiornare e semplificare, accettando una momentanea turbolenza, preferiamo impiccarci ad essi? Proprio non capisco...--Equoreo (msg) 17:30, 25 apr 2019 (CEST)[rispondi]
PS: Ripe ha ragione sul metodo, in linea di principio, ma stiamo parlando di una quisquilia! Che effetto ha su Wiki la data delle riconferme? Sarebbe cambiato qualcosa se quando sono state istituite le riconferme avessimo scelto questo metodo o un altro?--Equoreo (msg) 17:30, 25 apr 2019 (CEST)[rispondi]
[↓↑ fuori crono] Semplicemente si poteva automatizzare il tutto senza "transizioni" e "turbolenze" ma, visto che alla maggior parte degli utenti fin qui intervenuti va bene così, procedete pure. --Antonio1952 (msg) 19:11, 25 apr 2019 (CEST)[rispondi]
Comunque "la richiesta" della comunità è in genere che il bot funzioni con meno possibilità di bug possibili, l'approccio di Daimona è corretto, non si stratta di adeguarsi al bot, si tratta di non mischiare l'automazione che una volta fatta bene per lungo tempo non da problemi con la necessità di un intervento umano continuo, il che implica semplificare di meno e quindi complicarci la vita; non sarebbe quindi far adeguare il bot alle nostre necessità, perchè il bot non potrebbe risolvere il problema bisognerebbe invece dover aggiornare manualmente una lista con lavoro in più e rischio di errori. E comunque se non ho capito male si risolverà anticipando e non postecipando nessuna procedura. Se sbaglio user:Daimona Eaytoy correggimi. Spero non sia un problema per nessuno perdere qualche mese di flag.--Pierpao.lo(listening)10:56, 25 apr 2019 (CEST)[rispondi]
se ho ben capito: per evitare che le oltre 100 riconferme vengano gestite, come adesso, dall'uomo, c'è la possibilità di far gestire il tutto da un bot alleviando quindi di molto il lavoro. E tuttavia il bot deve lavorare su una data certa come quella del flag, questo comporta una serie di allineamenti che, una tantum, in taluni casi porteranno a una doppia riconferma in breve tempo, in altri una dilatazione delle riconferma. Non vedo quale siano le controindicazioni per cui sono Favorevole (e cmq contrario alla proposta di fare tutte le riconferme in un solo periodo come proposto da altri nella sezione in basso) --ignisscrivimi qui11:47, 30 apr 2019 (CEST)[rispondi]
Sì, è così. Per il momento sto facendo partire le riconferme a mano nelle date riportate in WP:Amministratori/Lista, in settimana cerco di apportare i vari cambiamenti: eliminare gli slittamenti di una settimana e forzare tutti gli allineamenti come discusso sopra. --Daimona Eaytoy(Scrivimi!)14:36, 30 apr 2019 (CEST)[rispondi]
[@ Sakretsu] Ci avevo pensato. Visto che le modifiche del bot sono in realtà importanti da vedere, non le contrassegna come bot edit. L'impostazione è modificabile on-wiki dal config.json. In teoria questo dovrebbe bastare. --Daimona Eaytoy(Scrivimi!)22:37, 30 apr 2019 (CEST)[rispondi]
Ok, grazie. Il dubbio nasceva dal fatto che i messaggi di benvenuto sono contrassegnati come bot edit e non ricordo più se lasciano la notifica. A questo punto immagino di no, a meno che non ci sia un altro metodo--Sakretsu (炸裂) 01:57, 1 mag 2019 (CEST)[rispondi]
[@ Daimona Eaytoy], visto che correttamente si è deciso di considerare la data di inizio quella di assegnazione del flag e non quella della fine della votazione, bisognerebbe aggiornare anche la colonna "Amministratore dal" in Wikipedia:Amministratori/Lista; ad esempio la mia data dovrebbe essere il 18 maggio 2017 e non il 17 maggio com'è adesso. IMHO questo vale per 10 dei 13 sysop che hai elencato sopra; invece per Tirinto, Tooby e Torsolo che, al momento dell'elezione avevano temporaneamente il flag di sysop, la data corretta è quella di fine votazione. --Antonio1952 (msg) 22:54, 2 mag 2019 (CEST)[rispondi]
[@ Antonio1952] Giusto, grazie. Adesso aggiorno la tabella. Invece, per quanto riguarda i 3T: quello è un caso molto particolare... Ricordo che lo avevo notato tempo fa ma ho poi dimenticato di sistemare. Nel loro caso, se si vogliono mantenere le riconferme allineate alla data di elezione (e non di flag) si può impostare un anticipo permanente nella configurazione del bot. Visto che si tratta di pochi giorni, non so se ne valga la pena (sentiamo qualche altro parere), ma senz'altro avrebbe senso. In ogni caso lo si può fare senza problemi. --Daimona Eaytoy(Scrivimi!)10:36, 3 mag 2019 (CEST)[rispondi]
Allineamenti
Scusate se entro a gamba tesa. Non stiamo parlando di abbonamenti a una rivista, ma di un momento in cui si controlla se effettivamente la fiducia ai vari amministratori c'è oppure no. Non facciamo prima a definire una Election Week uguale per tutti e smazzarci queste verifiche una sola volta l'anno? In alternativa, se non si vuole esagerare, non le si può fare la prima settimana di ogni mese (tranne magari gennaio e agosto per evidenti motivi) per gli admin eletti in quel mese? -- .mau. ✉12:39, 24 apr 2019 (CEST)[rispondi]
Contrario per lo stesso motivo, su cui discutemmo, a proposito delle domande in sede di riconferma o elezione, che sembra non servino, perchè non si usano mai, salvo poi scoprire che in casi controversi sono fondamentali. L'idea sarebbe ottima se vivessimo in un mondo ideale in cui si va sempre d'accordo. Noi dobbiamo essere però preparati al peggio? Ipotizziamo che due o peggio più amminnistratori finisconano per assumere atteggiamenti discutibili, si dovrebbe discutere di questioni estremamente delicate contemporaneamente con tutte le conseguenze del caso: discussioni incrociate, off topic, paragoni, impossibilità di linkare procedure che sono magari collegate negli argomenti, per evtare chiamate alle armi, ripicche incrociate. Per non citare il caso in cui magari due amministratori litighino. Dove si discute? separatamente senza poter citare il comportamento dell'altro visto che c'è una contemporanea riconferma? Si uniscono le procedure? Si decide di pubblicizzare ciascuna nell'altra? Mi rendo conto che la mia è una visione apocallittica e che con questa comunità appare impossibile una simile ipotesi, ma alcune di queste cose in passato, anche se in minor misura e con i dovuti distinguo sono successe. Perchè dobbiamo lasciare ai posteri una procedura che proprio in caso di problemi seri, improbabilissimi ma non impossibili mostrerebbe di essere disastrosa. --Pierpao.lo(listening)13:00, 24 apr 2019 (CEST)[rispondi]
Idem, mi sembra che il sistema attuale funzioni bene. Controllare l'operato di 100 admin in una settimana mi sembra poco fattibile. --Ripe (msg) 13:33, 24 apr 2019 (CEST)[rispondi]
la mia proposta non cambia la struttura delle riconferme, quindi non capisco il problema di avere due o più amministratori "problematici" in un colpo. Semplicemente si farebbero discussioni separate ma nello stesso periodo. Per il "controllare l'operato di un sysop", immagino che ad oggi se qualcuno ritiene che X non dovrebbe essere riconfermato aspetta la riconferma e segnala i suoi dubbi, a meno che non ci siano casi eclatanti: non è che quando arriva la procedura uno va a spulciare tutto. -- .mau. ✉14:06, 24 apr 2019 (CEST)[rispondi]
Contrario anche io alla data unificata per le motivazioni espresse da Pierpao, mi permetto di osservare che abbiamo discussioni già estremamente animate quando discutiamo di voci, non oso pensare se dovessimo discutere di più di un admin, magari in un contesto di contrasto fra admin, al tempo stesso. No, le votazioni sono nocive, IMHO meglio restino diluite--Lemure Saltante olim DaoLR 19:15, 24 apr 2019 (CEST)[rispondi]
Io invece sono assolutamente favorevole alla proposta di .mau.; mi sembra che i discorsi sulle discussioni plurime non abbiano alcun riscontro nell'analisi dei dati storici e che se veramente si temono voti contrari incrociati da sysop in riconferma si preclude contemporaneamente la buona fede degli stessi. Prendendo comunque per buono il parere contrario, non vedo quindi se ci sarebbero contrarietà a procedere a scaglioni come proponeva BlackCat più sopra, trimestrali o mensili a seconda delle obiezioni che sarebbero sollevate. --Aplasia11:57, 26 apr 2019 (CEST)[rispondi]
Una tornata unica mi pare effettivamente problematica, però l'idea dello scaglionamento trimestrale (cioè quattro tornate) non è male. --Epìdosis16:39, 26 apr 2019 (CEST)[rispondi]
L'unica obiezione forte che ricordo dei tempi in cui si discusse il sistema attuale è che raggruppando le riconferme si riduce l'attenzione che gli utenti possono dedicare a ciascuna e quindi, potenzialmente, si riduce il livello di scrutinio dell'attività degli amministratori. Dipende anche quali "attenzioni" ci si aspetta per le riconferme. Per gli steward si fa già, vedi per esempio m:Stewards/Confirm/2019; sono solo una trentina, ma le loro azioni sono molte e complicate. Nemo08:52, 28 apr 2019 (CEST)[rispondi]
Se ne è già discusso più di sette anni fa, ma di acqua sotto i ponti ne è passata.
La proposta è semplice e diretta. Abolire la riconferma annuale degli amministratori. I tastini verrebbero tolti dalla comunità se:
1) Comportamento problematico. Se ne discuterebbe in ambito di problematicità e nella stessa sede si deciderebbe di revocare o meno i tastini.
2) inattività, cosa che viene già automaticamente senza aprire alcuna discussione
3) nei rarissimi casi in cui il comportamento dell'amministratore non rientrasse nelle ipotesi precedenti, si apre una semplice discussione al bar generalista e in quella sede si verifica se vi sia un consenso o meno alla rimozione. Per mantenere una memoria storica, la relativa discussione potrebbe essere linkata nella pagina dedicata, di fianco al nominativo utente.
Questa proposta nasce da alcune considerazioni che riporto in ordine di importanza:
A) numeri alla mano, i casi di revoca dei tastini per i punti 1) e 3) sono molto rari. Non penso che abbia senso tenere in piedi una procedura per numeri così esigui.
B) un'ottica di sburocratizzazione
C) le riconferme annuali possono essere un momento molto stressante per la comunità, penso che tra i peggiori casi di flame si siano fatti in questi ambiti. Se venissero abolite non penso ne sentiremmo la mancanza.
Resta immutato ovviamente il caso delle dimissioni.
--155.185.101.47 (msg) 10:43, 24 ott 2019 (CEST)[rispondi]
Contrario, abolire le riconferme annuali porterebbe ogni utente con un minimo contrasto con gli amministratori ad aprire una procedura UP sugli stessi facendo degenerare la situazione. Piuttosto si potrebbe considerare di abbassare la soglia della riconferma tacita - da 15 utenze contrarie a 5 - considerando il calo degli utenti attivi su it.wiki, attualmente si tratterebbe già di un numero considerevole di utenze che avrebbero perplessità sull'operato dell'admin in riconferma--Lemure Saltante sentiamo un po' 16:53, 24 ott 2019 (CEST)[rispondi]
In questo senso, anche io trovo che 15 siano forse un po' troppi (anche se non esagerati), specie per via del numero di utenti che partecipano a discussioni di questo tipo, che è sempre più in calo; tuttavia trovo che 5 siano pochi e, a presumere la mala fede, cinque utenti si potrebbero facilmente mettere d'accordo anche off-wiki e votare contro, e allora si otterrebbe una situazione tipo l'apocalisse UP da te designata se le riconferme venissero abolite. Quindi direi, se proprio c'è da fare una modifica in questo senso, di abbassare il numero a 10, né troppi né troppi pochi, e già comunque un buon numero. --C. crispus(e quindi?)19:44, 24 ott 2019 (CEST)[rispondi]
Dieci può essere un buon compromesso, anche se paradossalmente non sono così "ottimista" (indicherebbe una partecipazione decisamente ampia e sentita) sull'avere cinque utenze attive e distinguibili che si accordano per fare cascare un admin (è uno scenario che poteva essere concreto anni fa IMHO, oggi è utopico - i nomi attivi nelle discussioni sono più o meno sempre gli stessi). Tuttavia visto che non si può rivalutare questo valore ogni giorno, può essere una buona soluzione intermedia--Lemure Saltante sentiamo un po' 20:28, 24 ott 2019 (CEST)[rispondi]
Contrario Va bene così, c'è anche poco da leggere visto che molti admin non scrivono nulla e non ricevono alcun commento. Trovo anch'io che 15 è comunque un numero troppo alto vista anche la diminuzione del numero di contributori di Wikipedia. 10 potrebbe anche andare bene. --НУРшЯGIO(attenti all'alce P.U.B.)04:42, 25 ott 2019 (CEST)[rispondi]
Contrario e sono d'accordo anch'io per il 10, tanto più che in moltissimi casi non c'è neanche discussione nelle riconferme, le pagine a volte finiscono quasi deserte, altro che stress.. --188.15.239.111 (msg) 08:58, 25 ott 2019 (CEST)[rispondi]
Contrario non mi sembra una procedura molto costosa, e può essere utile sia all'admin che alla comunità per tirare le somme su quello che è stato l'anno passato e su quello che potrebbe essere il prossimo, o anche solo uno spazio comunitario per fare due battute e spargere un po' di wholesomeness. Per i numeri: indifferente tra 10 e 15, di sicuro non 5. Poi io son sempre stato per alzare il quorum in riconferma, se non ai 4/5 almeno a 3/4, però mi sembra che si fosse già discusso pure di questo e ci fosse consenso per lasciare 2/3 quindi non riaprirei la discussione. --Ripe (msg) 20:28, 25 ott 2019 (CEST)[rispondi]
Contrario Dopo tutto il popò di lavoro fatto da Daimona per il bot che se ne occupa ormai le riconferme non sono neanche più un peso per gli utenti, quindi perché preoccuparsi di abolirle? Mal che vada rimangono deserte. E poi servono a ricordare a certi admin quanto si stia avvicinando l'età della pensione :) --gothnespresso20:51, 25 ott 2019 (CEST)[rispondi]
Contrario all'abolizione - IMHO rimangono un momento importante per la comunità - ma favorevole a ridurne a 10 giorni la durata.Favorevole ad abbassare da 15 a 10 contrari l'avvio della votazione: inutile nascondersi dietro al dito, gli utenti attivi di it.wiki nel 2019 sono (ben) meno numerosi di quanti erano in passato --Ombra12:45, 27 ott 2019 (CET)[rispondi]
Contrario all'abolizione, e Favorevole a ridurre sia a 10 giorni la durata sia a 10 il numero dei voti contrari. --GC85 (msg) 14:07, 27 ott 2019 (CET)[rispondi]
@[↓↑ fuori crono]Vero. Ma il primo che ha introdotto il numero 10 è stato Hypergiò, qualche post sopra. Al che si è andati avanti per sottinteso sino ad un (forse) fraintendimento tra utenti o giorni. Tu hai chiesto sul ridurre la durata ma si parlava di ridurre gli utenti (necessari ad aprire la sfiducia) e GC85 ha seguito il tuo dubbio. Almeno così parrebbe. Un [@ Hypergio] chiarirebbe tutto. PS: anche perché non avrebbe coerenza che da una parte si sollevi il problema di procedure deserte e dall'altra si suggerisca di abbreviare il tempo di decorrenza, desertificando ulteriormente--94.36.138.186 (msg) 22:54, 27 ott 2019 (CET)[rispondi]
Io francamente non ho mai capito perché in caso di problemi da parte di un amministratore non adatto si dovrebbe aspettare la scadenza dell'anno e valutare durante la riconferma. Per un compito così delicato e che che richiede fiducia, bisognerebbe intervenire appena possibile per valutare se permane tale fiducia.
Tra l'altro mi ricordo di aver letto riferimenti a casi in cui la la riconferma era stata utilizzata come "alibi" / "scusante" per non procedere a rimozione delle stato di amministratore "Comportamento problematico, ma non così grave da aprire una votazione (o se si era già in votazione: non così grave da rimuovere). Si valuterà durante la riconferma". Magari anche aggiungendo tipo "che tra l'altro è tra soli 3 mesi". Peccato che poi la segnalazione in problematici, terminata senza provvedimenti anche grazie a tali interventi, fosse stata considerata come una riconferma (ma è corretto?!) e quindi la successiva verifica di riconferma sebbene tanto auspicata fosse poi slittata a 12 mesi dopo. Come dire: "cornuti e maziati". --95.239.2.134 (msg) 14:31, 27 ott 2019 (CET)[rispondi]
se un admin si comporta male, si può richiedere una rdp o una up, se non sa fare il suo lavoro può sempre imparare piano piano, la riconferma in teoria serve appunto per dire se fa danni o no: se però in riconferma nessuno parla che si deve fare, prendere a schiaffi un po' di gente a caso per farla discutere? Eddai.. --2.226.12.134 (msg) 18:50, 27 ott 2019 (CET)[rispondi]
[@ 95.239.2.134], mi sembra strano che una UP sia stata equiparata ad una procedura di riconferma ma siccome tutto può essere dovresti cortesemente linkare il caso concreto a cui ti riferisci. --Antonio1952 (msg) 21:22, 27 ott 2019 (CET)[rispondi]
Innanzitutto singolare che la mia risposta sia stata separata come "ot", visto che è un tentativo di ragionare se la riconferma serva o meno, e quindi è decisamente funzionale a decidere se abolirla o meno.
2.226.12.134 appunto, allora perché aspettare la riconferma (magari 11 mesi e mezzo)? Tanto più che in riconferma c'è il rischio che "nessuno parli se non... presi a schiaffi" (anche perché ad esempio io non ho una memoria di ferro. Bisognerebbe che ogni utente si tenenga pronti dei "dossier" su ogni amministratore e li vada a consultare quando deve esprimersi per la riconferma. Ma è di questo che abbiamo bisogno? on qualcosa di più "wiki" in tutti i sensi?)
Antonio1952 dovrei provare a cercarla, era tempo fa, e se non ricordo male avevo letto un messaggio che riferiva di tale vicenda, non so neppure se fosse lì linkata. In ogni caso visto che dici che sarebbe strano equipararla a una riconferma, potremmo esplicitarlo nelle linee guida in modo che non ricapiti.--95.239.2.134 (msg) 00:23, 28 ott 2019 (CET)[rispondi]
@Ip 95.. bisognerebbe intervenire appena possibile per valutare se permane tale fiducia; prego, accomodati.. Ma essere più chiari no, non si capisce nulla di quel che hai scritto nei primi due messaggi della sezione "ot" o:O
Comunque Contrario, volevo dire, ma già lo ha già ammesso lui, che [@ Ombra] ha confuso i giorni coi contrari alla riconferma. Va bene così, sinceramente non vedo problemi, poi aspetto come Antonio i casi degli admin problematici da deflaggare al volo, così potremmo parlarne, hai capito ip?? Se non ne ricordi mica è problema degli altri :-PPP--KirkDimmi!00:27, 28 ott 2019 (CET)[rispondi]
95, se l'admin Pincopalla comincia a bloccare gli innocenti e ringraziare i vandali si può fare benissimo una up in cui si dice "l'admin Pincopalla ha bisogno di occhiali nuovi, guardate qui, qui, qui, qui, qui, qui e poi qui", nessuno ti mangia se hai prove inconfutabili.. --2.226.12.134 (msg) 01:03, 28 ott 2019 (CET)[rispondi]
Spiego la mia contrarietà sulla riduzione a 10 del numero di utenti necessari a deflaggare un admin: se è vero che apparentemente gli utenti attivi sono in diminuzione, è ben vero che il numero di "manipolatori" di contenuti in rete è sempre più attivo e non vedo motivo di facilitate una loro eventuale azione coordinata per colpire amministratori particolarmente attivi nel contrastare azioni di disinformazione o manipolazione in wikipedia. Anche se fossero evidenti, ed il deflag non passasse, sarebbe sempre causa di un forte disturbo.--BramfabDiscorriamo16:06, 31 ott 2019 (CET)[rispondi]
Contrario alla proposta di abolizione. Non molto d'accordo con Bramfab qui sopra, meglio subire un disturbo contrastabile che ritrovarsi, per esempio, un papello su un admin come accadde tanti anni fa --Actormusicus (msg) 18:49, 1 nov 2019 (CET)[rispondi]
Anche noi siamo diventati adulti, e intendo la comunità, non i soli amministratori. Tanto vale aggiustare al ribasso la maggioranza necessaria alla riconferma in votazione, a coprire quei cinque utenti in meno basta poco e risulta in un numero più veritiero, ma che partisse una riflessione con dieci utenti contrari lo troverei salutare (nulla ci vieterebbe di regolare il quorum proprio sul numero iniziale dei contrari, ma qui si entra nel campo minato dei calcolini che nessuno vuol fare) --Actormusicus (msg) 19:20, 2 nov 2019 (CET)[rispondi]
Le reflessioni partono anche con 3-4 commenti negativi, se ragionati e motivati. Non siamo diventati adulti, per il semplice emotivo che c'è sempre un forte ricambio, apri le pagine del bar di 5 - 10 anni fa e vedrai tanti nomi scomparsi,e ovviamente molti ancora assenti.--BramfabDiscorriamo10:10, 4 nov 2019 (CET)[rispondi]
Wikilink nel titolo
Utente:Daimona Eaytoy per favore puoi modificare il bot per non mettere più i titoli delle sezioni con in wikilink alla pagina utente: è stato stabilito che i link nei titoli sono deprecati vedi Discussioni_aiuto:Sezioni#Concretizziamo?_Note,_wikilink,_grassetti_e_altro_nei_titoli_delle_sezioni e la relativa modifica in aiuto:Sezioni che cito "Va evitato l'inserimento di wikilink, note, immagini e altre formattazioni che vadano oltre il semplice testo.". Il motivo è serio, i link nei titoli impediscono l'apertura delle sezioni da mobile fatta cliccando sul titolo--Pierpao.lo(listening) 14:49, 10 nov 2019 (CET)
Dimenticavo con l'occasione toglierei lo small dal rigo successivo. Perchè dobbiamo complicare le cose a chi si vuole informare. Ricordo che c'è stata un inversione di tendenza gli schermi si stanno di nuovo rimpicciolendo a fronte di un aumento delle risoluzioni--Pierpao.lo(listening)14:51, 10 nov 2019 (CET)[rispondi]
Il numero di contrarî per aprire le votazioni è una barriera che rende le riconferme una mera formalità. La pratica mostra che le riconferme votate sono meno di una all'anno in media. Eventuali pareri contrarî alle riconferme sono IMHO scoraggiati, perché i primi nove utenti si debbono esporre (e la quasi totalità degli admin può contare - giustamente - sul sostegno della comunità che li ha eletti), senza che queste obiezioni sortiscano alcun effetto pratico. Propongo di abbassare a tre il numero di contrarî per dare avvio alla votazione, in modo da fare emergere eventuali problematiche e anche per fare sì che gli admin abbiano davvero il consenso della comunità, anche dopo che si sono visti all'opera. --AVEMVNDI✉18:42, 9 feb 2023 (CET)[rispondi]
Se ne parlava anche qui sopra e Utente:Ombra aveva proposto 10. Credevo che il limite fosse quello. La discussione che mi hai segnalato (grazie!) mi era ignota. In ogni caso l'attuale limite (che non ho capito bene, perché 1/4 del quorum è 13 da molti mesi, 15>13) la proposta mi pare ancora più opportuna. --AVEMVNDI✉19:31, 9 feb 2023 (CET)[rispondi]
Sono sempre stato a favore di una riduzione del quorum per aprire la votazione di riconferma ma tre voti mi sembrano decisamente troppo pochi. Sarebbe tutta una votazione e potrebbe diventarlo anche a capriccio di pochi utenti. No direi che quel quorum già ridotto con un buon compromesso sta bene così. È tra l'altro una maggior garanzia di indipendenza e di efficacia delle azioni degli amministratori. Se “scoraggia” fenomeni di ripicca occulta è anche giusto --Actormusicus (msg) 19:56, 9 feb 2023 (CET)[rispondi]
in realtà gli admin non contano «sul sostegno della comunità che li ha eletti», la comunità li ha eletti perché ne ha fiducia e in genere - a parte che con me - ci azzecca: i casi rivelatisi errore in tutti gli anni di vita del Progetto sono davvero molto pochi (talora gravi, ma pochi). I consensi non vengono da bassi istinti corporativi, insomma. Ciò detto, negli anni siamo passati da una burocrazia iniziale necessaria per contestare azioni e condotte dei sysop (WP:Amministratori problematici), effettivamente un po' ostica all'utente di buona fede, a "ordinarie" segnalazioni in WP:UP, che possono essere aperte in qualsiasi giorno dell'anno (ricorrendone i presupposti, ci auguriamo); le riconferme quindi hanno un grado minore di criticità per il sistema, perché per le urgenze c'è sempre WP:UP, e diventa una questione diciamo "di sicurezza", di cautela, avere un momento dell'anno in cui osserviamo cosa quel tal sysop fa o non fa. Beninteso può perdere la fiducia comunitaria, ed è un buon momento per registrarlo, ma per le "eventuali problematiche", come detto, è più pratico WP:UP. Ora, in un'ottica quindi più serena rispetto a quanto descritto, il dato con cui fare i conti è probabilmente quello (puramente empirico) che un admin che fa bene il suo mestiere, già solo così, en passant, di "nemici" se ne fa ogni anno almeno 20 nuovi. Ma facciamo pure la metà, 10. Di quei 10, 3 contati che aprano la votazione non si fa davvero fatica a trovarli normalmente, abbassare la soglia a quel livello diventa quasi perversamente invitante. Anzi, se passa questa proposta e viene pubblicata in pagine leggibili, è WP:CAMPAGNA :-PPP -- g · ℵ → Gianfranco (msg) 20:27, 9 feb 2023 (CET)[rispondi]
Le ordinarie segnalazioni WP:UP avrebbero un unico effetto: fondate o no, spunterebbe un sostenitore del segnalato che blocca il segnalante per abuso di pagina di servizio e chiude immediatamente la segnalazione. Inoltre avere admin che non godono di fiducia della comunità (se non una blanda fiducia preventiva, basata sul nulla, perché espressa prima di vedere l'admin all'opera) è secondo me un problema. Se un admin in un anno si fa 10 nemici, in genere ne lascia campare meno di 2, gli altri nemici vengono bloccati. E in ogni caso nessuno torna mai nelle pagine di riconferma (per fare un esempio oggi abbiamo in riconferma Gac e Marcok, nessun nemico loro ha lasciato traccia in riconferma: ed è quasi sempre così). Tre voti sarebbe una soglia a mio avviso corretta per poter votare la riconferma in qualche caso, quando c'è qualche utente che ha qualche rimostranza (di cui magari fare tesoro per migliorare). Anche se l'admin verrebbe probabilmente riconfermato, sarebbe un'occasione di verifica comunitaria. Se si vuole migliorare, bisogna partire dall'ascolto della comunità, anziché costruire i fortilizi dove difendere gli admin, che peraltro non hanno niente da temere. Rendetevi conto che attualmente l'adminship è a vita e la riconferma una sfilata su un tappeto rosso. --AVEMVNDI✉14:03, 21 feb 2023 (CET)[rispondi]
(cit.:) "spunterebbe un sostenitore del segnalato che blocca il segnalante per abuso di pagina di servizio e chiude immediatamente la segnalazione". Maaaaa, WP:BF dov'è finita? A me sta bene una frase del genere se accompagnata da un po' di wlink che dimostrano l'asserto, buttata lì ad effetto non ne capisco l'utilità (e non voglio pensare male, perché la buona fede vale anche per me). --Er Cicero16:20, 21 feb 2023 (CET)[rispondi]
Guarda @Avemundi, ti faccio notare solo una piccola coserellina (che pure avrebbe dovuto constarti, tanto per parlare diretto, vista l'espertitudine infiltrata nel tuo dire): la maggior parte dei deflag coattivi (o coattivi in borghese, cioè comunque ottenuti con opportune diplomazie ma ottenuti), li hanno richiesti altri admin. Non utenti indipendenti, non osservatori esterni: altri admin. Pensa un po' che cricca scombinata che è questa, che invece di farsi deflaggare dagli utenti si fa fermare dai colleghi... Tra l'altro, questo è effetto di un piccolo aspetto: per molte cose è un admin quello che può vedere davvero bene cosa fa il collega. Un utente ancorché esperto può controllare qualcosa di meno. Quindi, certi deflag sono "giunti" anche dove gli utenti più attenti non potevano arrivare, eppure ci sono stati lo stesso. Perché tutti ci controlliamo l'un l'altro. Così come controlliamo qualsiasi utente. Giusto per farti notare quanto il tuo pregiudizio ti abbia portato distante dal vero. La carriera da amministratore di Gac è fatta di una mole così impressionante di insulti e altri disturbi subìti, che se tu ne ricevessi oggi solo il 5 per mille già staresti dai carabinieri a querelare :-) Io ti auguro sinceramente di non riceverne, di quelle negatività, tu però gentilmente non mancare di rispetto a chi per questo Progetto si è dovuto mettere in tasca ciò che tu non accetteresti mai di ricevere, quindi cortesemente non implicarlo gratuitamente in discorsi così "originali"; riserva a me questo privilegio, che io le riconferme sono abituato a vederle animate e me lo merito sicuramente di più. Anche se questo comporta purtroppo che a me non possa non constare ciò di cui ho parlato, e questa sfortunatamente ha tutta l'aria di essere una differenza. Il resto, se dovessi scriverlo in una voce neutralmente e oggettivamente, sono confuse approssimazioni un po' da social, per cui va benissimo che la categoria sia descritta come una cosca di satanisti o una camarilla di cospiratori, purché succeda su un social, al massimo un blog, a esagerare in una trasmissione giornalistica di quelle che "sanno"; qui critica pure quanto ti pare, ma le attribuzioni di malafede farai bene a provarle, prima che il discorso prenda una piega spiacevole. Ciò che proverai sarà di estremo interesse, abbiamo carrette di policy pertinenti. Attendo di sapere, se c'è da deflaggare si procederà. Proponi semmai, visto che questa è, pur inespressa, la parte salvabile del tuo intervento, modifiche costruttive alle modalità con le quali si verifica la sussistenza della fiducia comunitaria al momento dell'elezione. Se su questo contribuirai seriamente, cioè seriamente, senza assolutamente alcuna remora avrai garanzia di attenzione e di risposte serie; diversamente... faremo di te un martire della lotta e della resistenza contro i poteri forti, ma questo solo per voler garantire un minimo di concretezza alle tue insinuazioni :-))) Ripartiamo da cose serie, dunque: la tua proposta è chiara, avvisa quando riscuote consenso, grazie -- g · ℵ → Gianfranco (msg) 19:17, 21 feb 2023 (CET)[rispondi]
[a capo] wp:BF non è tanto o non solo una coccoloneria, quanto un principio ergonomico delle discussioni. Se prendiamo invece la piega di wp:CF, allora ogni discussione diventa impossibile e si può rinviare al mittente ogni rilievo. Se vogliamo cavalcare CF, allora possiamo ben proporre di alzare l'asticella a 1000 voti, in modo da mettere al riparo l'admin di turno dai suoi nemici...
A proposito di "nemici", io personalmente ho avuto scontri con diversi utenti, ma li percepisco come nemici solo se ne sospetto l'incompatibilità, quale che sia la ragione. Non nemici miei, dunque. Diversamente, si tratta di utenti con cui vado meno d'accordo o le cui opinioni in genere collimano meno con le mie... ma con cui la Ragion di Jimbo prevale sempre. Ave, tu sei uno di questi, tanto per intenderci, e non parlo di una cosa unilaterale.
Di tutto questo non ho capito una cosa: gli admin non hanno nulla da temere. E gli utenti che votano contro? Esattamente, possiamo citare un caso in cui gli admin si sono dati cura di mobbizzare un utente colpevole di aver votato contro uno degli affiliati? Se si propone una misura, è ovvio che il problema che intende risolvere deve essere ben visibile. Dove sono queste ritorsioni per aver osato votare contro ad un admin? E, se presenti, che pensare di tutti gli altri admin, che hanno visto e non hanno fatto nulla? Secondo me la proposta giusta era "dimettetevi tutti e rifacciamo le votazioni". Questa è una proposta chiara, che possiamo capire tutti. E penso che forse gli admin dovrebbero anche organizzarsi e venire incontro ad una richiesta del genere, dimettendosi tutti chessò l'uno marzo.
Seriamente pensiamo che un utente attragga antipatie perché vota contro ad una riconferma? Ma non basterebbe e avanzerebbe tutto il resto? Una volta che ci si è dati la pena di fare tutto il resto, il voto è una pura formalità. Tu stesso, Ave, ci spieghi che "i nemici di Gac e Marcok" non si sono fatti vivi, dunque sai che esistono e quindi più o meno anche chi sono. E Gac non lo sa? E Gac non ha messo in piedi le sue ritorsioni, nonostante sappia chi ha commesso il peccato mortale di pensare di votargli contro? E poi, diciamocelo, in questo contesto, Gac non avrebbe bisogno nemmeno dei tastini per mettere in piedi la ritorsione: basterebbe chiedere ad uno dei suoi sodali...
Tappeto rosso: le riconferme sono spesso momenti di affetto e hanno un sapore formale semplicemente perché nella gran parte dei casi c'è solo da ringraziare, come ci si ringrazia quotidianamente con l'apposito tool. Ipotesi del perché "i nemici" degli admin in riconferma tacciono. La più probabile è qualcosa di simile a wp:GIUDIZIO: il silenzio è augusto, somiglia a qualcosa di profondo e solenne, ma talvolta semplicemente nasconde il nulla da dire più siderale, che se espresso si manifesterebbe per quello che è. Idiosincrasie senza fondamento. I tappeti rossi non sono oggetti inerti, sono persone in carne ed ossa che ringraziano e sono soddisfatte dell'operato. Le critiche si possono sempre fare: ci sarà un admin buono (uno!) che difenderà i pilastri, no? pequod76talk20:06, 21 feb 2023 (CET)[rispondi]
Da sempre sono favorevole al fatto che nella wiki italofona si faccia ogni anni la riconferma, in molte altre, a partire da quella anglofona ciò non avviene.
Essere admin tuttavia implica, volenti o nolenti, inimicarsi molti utenti che o di per se non intendono (volontariamente o inconsciamente) rispettare le norme di comportamento di wikipedia oppure sono arrivati qui per qualche finalità che non è quella di contribuire alla scrittura dell'enciclopedia per la diffusione del libero sapere.
Per casi gravi è sempre possibile aprire una UP verso un admin, che se corretta come conclusione non può che portare ad un deflag.
Abbasssare il quorum tanto per avere più votazioni non mi sembra un gran genialità, e neppure mi pare che siano molti i tentativi di far partire una votazione abortiti per la mancanza del numero minimo di firme, nonostante l'esistenza di ragionevoli dubbi sulla fiducia da riconfermare.
