Discussioni Wikipedia:Mover/Archivio2

Suppressredirect: si può assegnare come fatto per i file mover?

cb La discussione proviene dalla pagina Wikipedia:Bar/Discussioni/Suppressredirect: si può assegnare come fatto per i file mover?#Suppressredirect: si può assegnare come fatto per i file mover?.
– Il cambusiere Fullerene (msg) 21:40, 30 giu 2015 (CEST)

In passato la comunità si è espressa a favore dell'assegnazione del privilegio di spostare i file locali ad utenti autoverificati che ne facessero esplicita richiesta e che rispettassero determinati criteri, non si potrebbe fare la stessa cosa per il privilegio suppressredirect? Ciò porterebbe alla diminuzione di richieste di cancellazione immediata che gli amministratori dovrebbero controllare, permettendo loro di potersi concentrare maggiormente su altre tipologie di lavoro sporco di loro competenza invece di dover stare dietro ad un utente fidato che sta spostando decine di voci perché ha acquisito il consenso necessario in un progetto tematico o che pubblica nel namespace principale un portale preparato nelle proprie sottopagine utente. --Gce ★★ 16:45, 15 mag 2015 (CEST)

Estremamente Favorevole. --Epìdosis 19:33, 15 mag 2015 (CEST)

Favorevole rifacendosi a quanto detto sul forum di meta (la proposta originale in qual caso era sugli autoconfirmed e chiaramente era troppo sbilanciata).--Alexmar983 (msg) 21:17, 15 mag 2015 (CEST)

bisogna stabilire se lo si vuole per tutti i namespace, o lo si vuole limitare p.e. a ns0/ns1 e anche a ns6/ns7 (le voci e i file, e loro pagine di discussione)--Alexmar983 (msg) 21:19, 15 mag 2015 (CEST)

Favorevole. --2.226.12.134 (msg) 21:20, 15 mag 2015 (CEST)

Favorevole. A me, in diversi frangenti, sarebbe stato molto utile. O meglio, sarebbe stato utile al povero amministatore di turno.--НУРшЯGIO^{(attenti all'alce)} 21:35, 15 mag 2015 (CEST)

Piuttosto che un gruppo a sé direi di attribuirlo a un gruppo già esistente: gli autopatrollati. Però che sia chiaro che chi ne abusa ci lascia qualche penna. --Vito (msg) 22:09, 15 mag 2015 (CEST)

il che mi sembra un'ottima idea.. --2.226.12.134 (msg) 22:13, 15 mag 2015 (CEST)

io scoraggerei di darlo a tutti gli AP. Cancellare un redirect è un'operazione che nella sua apperente semplicità si presta a improprie generalizzazioni e relativi attriti. Persino la cancellazione giusta con la motivazione sbagliata può indurre dibattiti estenuanti. Già mi immagino chi cancella redirect perché non "è usato in nessuna pagina" con relativi dibattiti filosofici se sia giusto o meno, accuse di "sfera di cristallo" e "le altre wiki non contano" e via a andare. Io fossi in voi eviterei...--Alexmar983 (msg) 22:32, 15 mag 2015 (CEST)

Scusate, non ho capito bene la parte iniziale: per il privilegio di spostare i file, non ci fu consenso nel consentire anche il suppressredirect. A chi lo si vorrebbe dare ora? in aggiunta a chi è già file mover, oppure per cancellare qualsiasi redirect originato da spostamento (file e voce)? E in tal caso, si limiterebbe l'uso del tastino "cancella" a quel solo tipo di azione, collegandola in qualche modo allo spostamento stesso? ma è fattibile tecnicamente?--Euphydryas (msg) 22:46, 15 mag 2015 (CEST)

I redirect già esistenti non sarebbero cancellabili, il diritto suppressredirect dà la spunta che permette di non creare il redirect durante uno spostamento. --Vito (msg) 22:56, 15 mag 2015 (CEST)

[× Conflitto di modifiche] [@ Euphydryas] suppressredirect è il flag che permette di spostare una pagina senza lasciare un redirect (non c'entra il tasto "Cancella"), ed è dunque possibile assegnare tale funzione ad un certo gruppo di utenti senza implicare altri permessi. L'accenno ai file mover è stato fatto in quanto si propone di creare un nuovo gruppo di utenti, come quando si propose di creare quello degli "spostatori di file".

[@ Vituzzu] Ricordando che qui si contestò l'uso della funzione persino ai bot (che hanno il permesso di default!), darlo ora a tutti gli autoverificati non mi sembra verosimile. --Horcrux_九十二 23:05, 15 mag 2015 (CEST)

Ma perché intanto non fu dato già ai file mover? --Euphydryas (msg) 23:14, 15 mag 2015 (CEST)

No, di che io sappia i file mover hanno solo la funzione aggiuntiva di spostare i file ma il rinvio è creato in automatico e, se non serve, devono chiedere la cancellazione immediata.

Anch'io penso che dare il privilegio a tutti gli autoverificati sia troppo estensivo, anche perché non è detto che a tutti serva o abbiano interesse ad avere questa possibilità, per questo ho proposto di creare un gruppo apposito. --Gce ★★ 23:59, 15 mag 2015 (CEST)

Ho sempre trovato troppo macchinosa la moltiplicazione dei gruppi. --Vito (msg) 00:12, 16 mag 2015 (CEST)

[← Rientro] Favorevole ma non a tutti gli autoverificati: un utente affidabile non necessariamente ha competenze in materia di redirect, esattamente come potrebbe non averle per spostare i file. Basti pensare ad esempio ai redirect doppi che, se non sistemati, in seguito ad uno spostamento senza lasciare redirect diventerebbero tutti redirect errati (non so però se possono essere corretti tramite bot); il tempo che gli amministratori guadagnerebbero con meno richieste di C9 si perderebbe poi per correggere i redirect rimasti errati.

La questione della moltiplicazione dei gruppi si lega a questa discussione in cui si valutava la possibilità di escludere la funzione di autopatrol dagli altri flag (anche in vista di ulteriori flag appunto), semplificando il tutto imponendo l'essere un utente autoverificato come condizione necessaria preventiva per poter chiedere i flag supplementari, che mi sembra essere più logico.

Inoltre credo che si possa valutare anche la possibilità di distinguere il suppressredirect in base ai namespace: dover lasciare un redirect a seguito dello spostamento di una categoria o di una pagina utente e i redirect che si creano tra le pagine di discussione di qualsiasi pagina spostata non hanno molto senso, quindi sarei favorevole in tutti questi namespace a lasciarlo anche agli autoverificati, così come aggiungerei direttamente la funzione ai filemover per poter spostare i file senza lasciare redirect. --Fullerene (msg) 04:11, 16 mag 2015 (CEST)

Non sono così sicuro. Mentre per i file mover ero favorevole (ma non c'era consenso; lo sono tutt'ora, ad ogni modo), darlo in generale a tutti gli autoverificati è IMHO troppo estensivo--Formica rufa 15:25, 16 mag 2015 (CEST)

Infatti, Formica rufa, quella non è la mia idea di origine, io vorrei la creazione di un gruppo a parte in cui bisogna chiedere l'abilitazione, come accade oggi per i file mover. --Gce ★★ 19:15, 16 mag 2015 (CEST)

Favorevole: questo flag può essere molto utile a chi si occupa di spostamenti di redirect errati. Non sono d'accordo sul darlo a tutti gli autoverificati, si può fare invece che l'autoverifica sia un requisito, che l'iter di assegnazione sia lo stesso dei FM, degli AV e dei rollbacker e che il flag venga automaticamente dato ai file mover. Bisognerebbe anche trovare un nome più adatto a questo flag. --Fabyrav parlami 13:19, 17 mag 2015 (CEST)

Non mi pare che questo flag sia stato proposto per tutti gli autoverificati ma, ribadisco quanto scritto nella proposta fatta all'apertura di questa discussione, ovvero di assegnare il flag ad utenti autoverificati che ne facessero esplicita richiesta e che rispettassero determinati criteri. Mi pare chiaro... O no? --НУРшЯGIO^{(attenti all'alce)} 13:47, 17 mag 2015 (CEST)

Infatti la proposta del flag a tutti gli autoverificati è arrivata dopo l'apertura della discussione. --Fabyrav parlami 14:50, 17 mag 2015 (CEST)

Credo sia necessario fare un attimo il punto delle cose tecnicamente possibili:

1. Creare un gruppo ad hoc col suppressredirect
2. Dare il suppress agli autopatrolled
3. Dare il suppress ai filemover e/o rollbacker
4. Dare il suppress ai filemover e/o rollbacker e creare pure un gruppo ad hoc

--Vito (msg) 17:39, 17 mag 2015 (CEST)

La mia proposta è la prima dell'elenco, cioè creare un gruppo ad hoc, chi vuole fa richiesta per aderirvi e, se rispetta i requisiti che la comunità deciderà, vi sarà ammesso; se non erro, comunque, non vi sono contrari nell'estendere il suppressredirect ad utenti non amministratori, ma solo divergenze su chi può avere questo privilegio, giusto? --Gce ★★ 17:45, 17 mag 2015 (CEST)

Ci saranno divergenze ma mi sembra che allo stato una certa convergenza nell'estenderlo a una parte degli AV che lo richiedono ci sia.

E poi in fin dei conti è una cosa abbastanza semplice: ci sono gli AV, ci sono gli amministratori e ci sono alcune funzioni, riguardanti le voci (e presumo mai le utenze, essendo più delicate), che possono essere "concesse" dal secondo gruppo al primo. Queste funzioni più avanzate dell'AV includono ad esempio il rollbacker, il file mover e, in questo caso, il suppressredirect. Se persino io riesco a inquadrarlo in poche righe... andrebbe scritto meglio nella pagina di aiuto che descrive l'ordine dei permessi

mi scuso per aver detto cancellare, l'ho scritto tardi e mi sono espresso male.--Alexmar983 (msg) 20:40, 17 mag 2015 (CEST)

Secondo me è inutile creare millemila gruppi utente con un solo micragnoso permesso, meglio accorpare i permessi utenti in un solo gruppo fino a che ciò è possibile. Ritenete che gli autoverificati non siano abbastanza scrutinati per avere il permesso di scegliere se spostare una pagina senza lasciare redirect? Datelo ai patroller o anche a nessuno, se deve essere una selezione come nei Marines per avere un privilegio effimero, tanto vale non concederlo. PS: i redirect doppi non dovrebbero esistere, tanto per fugare un dubbio sollevato poco sopra. --Wim b 01:54, 18 mag 2015 (CEST)

Sono contrario alle soluzioni 2 (essere affidabile non significa saper gestire i redirect) e 3 (può essere utile anche a chi non si occupa nè di patrolling nè di file), mentre per i rollbacker non vedo un collegamento diretto con questa funzione quindi li escluderei.

Inoltre, è tecnicamente possibile, oltre che probabilmente troppo complesso, scindere il suppressredirect in base ai namespace in modo da assegnarlo selettivamente come proponevo più su? Nel caso sarei per concederlo anche ai filemover nel namespace dei file e agli autoverificati nei namespace che accennavo, diversamente sono ovviamente per la soluzione 1.

[@ Wim b] i redirect doppi vengono creati a seguito di uno spostamento: se si esegue uno spostamento senza lasciare redirect diventano errati e vanno corretti. Questa è una delle accortezze da prestare se si ha questa funzione. Altre che mi vengono in mente sono quella di valutare la possibile utilità nella ricerca del redirect che si intende non lasciare e quella di renderlo orfano. Sinceramente non mi sembra poco. --Fullerene (msg) 04:00, 18 mag 2015 (CEST)

Fra le 4 possibilità schematizzate da Vito, la più opportuna IMHO è senz'altro la 3, ovvero Dare il suppress ai filemover e/o rollbacker, al limite solo ai primi, per i quali il fatto che tale funzione non sia implicita limita l'utilità dell'esistenza del loro gruppo. Neanche a me sembra positivo creare tanti piccoli gruppi, ma, dopo un periodo di sperimentazione di tale "possibilità 3", si potrebbe valutare il passaggio alla 4, cioè creare anche un gruppo ad hoc, mentre non mi sembra proprio il caso di estendere il suppress alle centinaia di utenze autopatrolled, che hanno assunto il flag solo perché si è ritenuto che i loro contributi fossero "non palesemente vandalici", e da questo a consentirgli la cancellazione di un titolo che potrebbe essere utile se non chiaramente errato ne corre. Sanremofilo (msg) 08:00, 18 mag 2015 (CEST)

se ci si preoccupa tanto di cosa potrebbe essere complicato, francamente sperimentare prima di creare un gruppo ad hoc mi sembra ancora più complicato. I permessi in gioco non sono millemila e non sono micragnosi... abbiamo necesità di lavoro stratificate e articolate, i nostri flag lo rispecchiano. Fintanto che rispecchiano una vera esigenza, inquadrati in una cornice generale abbastanza chiara, quella di autoverificati con alcune funzioni avanzate, essi funzioneranno perché avranno l'unico senso che devono avere: servire le esigenze della comunità. Del resto noi siamo una comunità più selettiva della media nella scelta dei sysop, è normale che sentiamo in maggioranza l'esigenza di esserlo nel concedere alcuni privilegi dei syosp a altre utenze. I contributi di un AV sono più che sufficienti a stabilire l'opportunità di un flag. se hai patrollato con successo ti serve il RB, e analogamente se hai chiesto tanti C9 dopo spostamenti, ti serve il supressredirect. è una cosa semplice, alla fine.--Alexmar983 (msg) 09:41, 18 mag 2015 (CEST)

Anche io appoggio l'opzione 3 di Vito (con la "e" al posto di "e/o"). Inutile IMHO creare un nuovo gruppo solo per questo. --Retaggio (msg) 12:21, 18 mag 2015 (CEST)

a mio avviso è più inutile creare un bizzarro flag-mappazzone mischiando funzionalità diverse o solo in parte coincidenti. Trovo più semplice il concetto di dare una funzionalità avanzata a chi è fidato (=AV), gli serve (=contributi) e la richiede. è quello che abbiamo fatto con gli altri flag finora, con un discreto successo. Del resto se questa strategia di accorpamento rappresentarse la semplicità allora perché non abolire i due flag AV avanzati che abbiamo e farne uno solo? Com'è questa proposta? semplice o semplicistica?--Alexmar983 (msg) 13:49, 18 mag 2015 (CEST)

[← Rientro] L'idea di un unico flag avanzato non è poi così male dato che siamo parlando di gruppi di pochissimi utenti, alcuni dei quali interessati ad avere più di uno dei tre (i due attuali più il suppressredirect). Anche se le funzioni sono estremamente diverse, il tipo di fiducia che l'utente deve ottenere dalla comunità per ottenere i diversi flag è pressoché la stessa.--НУРшЯGIO^{(attenti all'alce)} 15:50, 18 mag 2015 (CEST)

il flag di RB è decisamente diverso dagli altri. Il file mover e il suppressredirect hanno delle affinità, ma se a me serve il supressredirect come si fa a sapere che userò bene il filemover, se non ho mai spostato un file pur avendo chiesto decine di C9 in ns0 e ns1? E non è detto che per questo non mi trovi a spostare un file dopo averlo avuto [a scanso di equivoci, a me non interessa avere il flag, è esemplificativo]. Il RB è un file abbastanza "pratico", il patrolling è un problema abbastanza noto anche a un utente medio, mentre gli altri due sono soprattutto finezze tecniche. Il problema delle cose un po' tecniche è che una buona onesta e solida contibuzione generale non indica che ci si orienti correttamente comunque. D'altro canto visto che noi diamo a un admin il pacchetto completo anche se ne saprà fare bene solo alcune i primi tempi, si potrebbe pure fare con il flag-mappazzone... Solo che sappiamo tutti che livello di tensione/scrupolo ci può essere con la scelta gli admin, secondo me rischiamo di trovarcela pure con un flag che ne accopri insieme ben tre delle loro funzionalità. Invece una funzionalità chiara, su richiesta, dà molti meno problemi a stabilire l'idoneità. Insomma cosa è più comodo per chi ci deve lavorare? Averne uno e magari un altro dopo 12 mesi oppure vedersi rigettato un flag più corposo per avere tutte le funzioni direttamente dopo 12 mesi?--Alexmar983 (msg) 16:07, 18 mag 2015 (CEST)

Oltretutto il ruolo di rollbacker è revocato d'ufficio dopo 6 mesi di inutilizzo delle funzioni aggiunte, mentre quello di file mover è revocato solo dopo un'esplicita richiesta, quindi unire i ruoli in un unico macrogruppo dovrà comportare la creazione di una linea guida unificata e lì si dovrà decidere se usare la revoca automatica o meno per tutti i ruoli (con discussione annessa).

Come ho scritto su, preferisco il gruppo separato, che comporta anche minori discussioni e maggiore diversificazione della platea (un conto è per un utente chiedere solo il suppressredirect, un altro dover chiedere contemporaneamente tutte le funzioni aggiunte non riservate agli amministratori, fra cui funzioni che non sa usare o verso cui non ha alcun interesse). --Gce ★★ 16:25, 18 mag 2015 (CEST)

Hai ragione il diverso decorso dei flag è un altro aspetto che rende comunque sconsigliabile spalmare la stessa funzionalità su entrambi.anche se comunque io non avrei problemi a semplificare ponendo gli stesso vincoli di accettazione/decadenza per tutte le funzionalità AV avanzate, ma questo si può discutere dopo aver introdotto un nuovo gruppo comunque.--Alexmar983 (msg) 16:36, 18 mag 2015 (CEST)

(conflittato) Anche secondo me il "flag avanzato" o "mappazzone" (ma che brutto nome che gli avete trovato... :-P) potrebbe essere una buona idea, se contemporaneamente facciamo un riordino/accorpamento dei numerosi diversi livelli che abbiamo al momento. --Retaggio (msg) 16:38, 18 mag 2015 (CEST)

non è bruttissimo, il mappazzone nelle parole di Barbieri indica un piatto che manca di stile e abbonda di sapori ma in sè non è uno schifo. Diciamo che ha del rustico, è una roba da camionisti.--Alexmar983 (msg) 17:10, 18 mag 2015 (CEST)

Ah... LOL, beh a Sud è un po' diverso... è più un piatto che ti rimane sullo stomaco, che non si riesce a digerire (nemmeno i camionisti), tanto che si sta lì lì per vomitare... la mappazza, insomma :-D --Retaggio (msg) 17:34, 18 mag 2015 (CEST)

[← Rientro] "Un unico flag avanzato" potremmo chiamarlo "Semi-sysop", o "Quasi-sysop"... Scherzi a parte, IMO ciò darebbe ancora più l'impressione che per diventare amministratore sia necessaria una sorta di cursus honorum (come se le idee a riguardo non fossero già abbastanza confuse). --Horcrux_九十二 20:02, 18 mag 2015 (CEST)

Sì in effetti il mappazzone pare un pre-sysop. Qui si accavallano due esigenze, quella di alcuni utenti di avere un tastino solo (personalmente non ho chiesto né il filemover né il rollbacker perché non mi sarebbero quasi mai serviti mentre il suppressredirect mi farebbe comodissimo) o magari 2, o magari tutti e tre e l'altra di non creare più e più categorie di utenti. Io credo per contro che un utente se è affidabile per una funzione è affidabile anche per le altre due. Credo anche che se passa la linea mappazzone (ma che bel nome...) basta che sia chiaro che questo flag non è condizione sine qua non un utente possa poi diventare amministratore. Infine queste funzioni dovrebbero essere legate solo ed esclusivamente all'attività dell'utente e pertanto, secondo il mio modestissimo parere, tutte (separate o insieme che siano o che saranno) dovrebbero sottostare alla regola dei sei mesi di inattività. --НУРшЯGIO^{(attenti all'alce)} 22:58, 18 mag 2015 (CEST)

Sinceramente l'idea di fondere i flag (con tutte le varie conseguenze tra cui l'incongruenza sulla decadenza) non mi piace affatto: agli amministratori vengono assegnate anche alcune funzioni per le quali non hanno dimostrato di essere competenti perchè per diventare tali godono di una fiducia tale da parte della comunità da essere sicura che non faranno mai uso di funzioni per le quali non sono estremamente certi delle conseguenze; parallelamente non me la sento di assegnare un flag "mappazzone" a utenti che lo richiedono perchè gli serve per spostare i file ma non sanno nulla sui redirect e sui rollback, se si ritengono competenti in tutti i settori o se si ritengono così affidabili tanto vale candidarli come amministratori. Per me saper operare sui redirect, sui file o nel patrolling sono competenze completamente distinte, e tra queste l'unica connessione che vedo è quella eventualmente di assegnare il suppressredirect ai filemover nel namespace dei file. Tra l'altro tra i 3 flag il più "rischioso" di tutti mi sembra proprio il suppressredirect, il quale se gestito malamente provoca una gran quantità di wikilink errati, redirect errati, eccetera, i quali sono più complessi da correggere a differenza di un rollback o di un semplice spostamento di un file.

[@ Retaggio] quando dici "inutile creare un nuovo gruppo solo per questo", sinceramente non sottovaluterei la potenziale dannosità del suppressredirect.

[@ Hypergio] non mi sembra che ci siano utenti interessati ad avere più flag: attualmente ce n'è solo uno con l'abilitazione sia da rollbacker che da filemover, il che conferma la diversità delle competenze nelle varie funzioni. --Fullerene (msg) 04:02, 19 mag 2015 (CEST)

Guarda che non sottovaluto assolutamente, anzi! Evidentemente sono stato frainteso. Ho solo detto che abbiamo già una miriade di livelli diversi e di crearne di ulteriori mi sembra sbagliato. Anche per questo sarei favorevole ad una riorganizzazione (che non significa necessariamente il "pre-sysop", ma semplicemente individuare diversi livelli - 3, 4, non di più - di coinvolgimento e di "fiducia"). Anche per questo inizialmente avevo individuato due classi di utenti (rollbacker e file mover) ai quali IMHO potrebbe essere dato senza troppi patemi. L'alternativa ovviamente sarebbe darlo solo ai file-mover (che secondo me dovrebbe essere naturale) oppure, di non fare proprio nulla: si sta come ora (cioè "bene") e punto. --Retaggio (msg) 09:25, 19 mag 2015 (CEST)

[@ Retaggio] perdonami, mi era sembrato quello il senso della frase :)

Comunque complessivamente mi sembra che ci sia un certo consenso nel concedere la funzione suppressredirect ad una parte di utenti non amministratori, resta solo da trovare l'accordo sul come. --Fullerene (msg) 01:27, 20 mag 2015 (CEST)

Secondo me, ammesso che non sia necessariamente vero anche il contrario, chi viene ritenuto idoneo al suppressredirect (dunque sa scegliere opportunamente il titolo e controllare che quello errato sia orfano) può ben spostare i file. IMHO si potrebbe dunque avere un unico gruppo (si veda quale nome assegnargli) con entrambe le funzioni, valutando attentamente in sede di assegnazione. Sanremofilo (msg) 10:18, 20 mag 2015 (CEST)

Francamente, mi sembra tanto rumore per nulla... abbiamo veramente così tanti C9 da non sapere più dove metterli? È la solita vecchia storia delle idee che vengono sotto la doccia (non me ne vogliate, lo dico con il sorriso perché ne ho avute tantissime anch'io :) ). Se, tuttavia, sentissimo l'impellente necessità di dotare altri utenti di uno strumento così fondamentale, penso si debba tenere presente che:

• AV è AV, non ci si dovrebbe aggiungere altro perché il senso dello strumento è proprio che non sia uno strumento (non per il titolare). Favorevole comunque a scorporarlo dal rollbacker e implementare un minimo di modularità (con l'ovvia controindicazione di dare l'impressione che esista un cursus honorum).
• per il resto io mi figuro tre modi di vedere la cosa:
  • può aver senso assegnare un unico maxi-flag di "lavoro sporco", basando l'assegnazione su criteri più stringenti rispetto a quelli per il rollbacker, ma anche più generali di affidabilità e di conoscenza delle regole di Wiki, ammiccando così al concetto di fiducia che chiediamo agli admin, ovviamente su una scala diversa. Questo ci permetterebbe di assegnare senza patemi d'animo permessi abbastanza eterogenei anche a utenti che magari ne userebbero solo uno, ma sapendo che (per le loro conoscenze e qualità) sarebbero perfettamente in grado di gestire anche gli altri. Evidentemente ci esponiamo al rischio di disegnare un cursus honorum, ma sicuramente assegnando questo tipo di permessi a utenti che hanno qualità "poliedriche" (così finalmente facciamo entrare legittimamente nelle procedure sull'assegnazione dei flag "minori" tutta una serie di considerazioni sacrosante che per ora erano solo un convitato di pietra che non poteva essere ostativo all'assegnazione) potremo in futuro espandere il flag a piacimento, se sarà necessario.
  • Ma può anche aver senso creare un flag per permesso, o accorpare i permessi in flag molto piccoli e diretti a funzioni specifiche. Questo permetterebbe a chi fosse interessato al lavoro sporco di accedervi facilmente e per gradi, senza grossi rischi per gli ambiti in cui non ha ancora fatto la gavetta. Evidentemente avremmo delle procedure di valutazione molto più tecniche (ha spostato x file? ha richiesto y C9?) e ci perderemmo la possibilità di correggere in tempo utenti con approcci troppo tecnocratici all'enciclopedia. Altro problemino che vedrei è l'effetto "raccolta di figurine" (che è sicuramente un approccio sbagliato, ma può celare una volontà di sperimentare e di essere utili in aree nuove), parzialmente diverso dall'effetto "cursus honorum".
  • Ma, ancora, vedrei bene anche una via di mezzo (che nell'immediato coinciderebbe con la proposta iniziale): lasciare i rollbacker dove sono (ché stan bene dove stan! e trasformare il file mover nel suddetto flag di lavoro sporco "flessibile" e quindi soggetto a valutazioni anche di ambito generale (ma non solo: approfittiamone per relegare all'oblio quei pendagli da forca che mettono in C9 voci con un centinaio di PuntanoQui!), sull'affidabilità dell'utente e (per esempio) sulle sue capacità di relazionarsi con gli utenti. Quindi i rollbacker restano a parte come flag più impegnativo e soprattutto più specifico, e gli altri permessi (per ora file mover e suppressredirect) vengono accorpati e assegnati da un burocrate dopo una fase obbligatoria di commenti (ma niente candidature e menate varie: resteremmo nell'ambito dei flag minori, quindi anche - o solo - autosegnalazione e decisione "monocratica", ma suffragata da consenso) sui vari requisiti cui accennavo.

Ma insisto, per me (e sì, mi sono guardato i registri: a parte un picco stasera per l'attività di un qualche bot non c'è gran che da segnalare) il problema non sussiste. Per quanto di proporzioni risibili e del tutto atipica, è comunque una cancellazione! Scusate lo sproloquio, ma dovevo festeggiare il ritorno dopo una pausa durata mesi :) --Dry Martini confidati col barista 23:17, 20 mag 2015 (CEST)

non esiste il problema di cambiare nome a tanti file, a occhio, eppure abbiamo il flag. Esistono infrastrutture che servono a risolvere problemi nel presente e misure che servono a evitarli e a adattarsi con flessibilità a ciò che può succedere in futuro. basta anche solo un momento in cui questo è stato critico (e certe elezioni di admin in cui si piangeva per la categoria delle C immediate intasata rientrano in quell'ambito) per assumere con ragionevolezza che potrà essere critico di nuovo lasciando le cose come sono. Inoltre distribuire le funzioni serve a smussare la rigidità operativa, a garantire una crescita di competenze graduale e a interagire meglio con le altre piattaforme in un ambiente crosswiki. Senza contare che anche se abbiamo abbastanza sysop per fare un C9 o un filemover per i prossimi cinque anni questo non significa che sarebbe meglio impiegarli a fare altro nei cinque anni che seguono. Anche quando in Italia vivevano venti milioni di persone non c'era bisogno dei trattori, secondo voi se alla richiesta di introdurre il trattore il contadino ha fatto spallucce e detto che non gli serviva (che è vero, non gli serviva in quel momento), il suo discorso non faceva una piega? Però è chiaramente errato a livello operativo.

il miglior modo per disincentivare cursus honorum è e rimane per me quello di creare flag focalizzati su specifiche funzioni. La suddivisione fra "tecnico" e "flag sulla fiducia" inoltre è abbastanza erronea. Questo si capisce guardando i rollbacker. Avevamo una procedura "estemporanea" di rollbacker basata su un miscuglio alchemico di "fiducia" e "mi serve" e funzionava così-così. L'abbiamo trasformata in una procedura più "tecnica" suggerendo di prendere il flag a chi aveva una forte attività di annullamento e non solo abbiamo avuto più candidati (e tutti se la cavano bene, come livello di attività anche meglio di quelli prima) ma abbiamo aperto de facto il rollbacker al retro-patroling. Come mostra questo esempio il lato tecnico della valutazione non porta a ridurre quello di fiducia, porta solo i candidati a esprimere meglio i motivi per cui fidarsi di loro quando l'aspetto tenico specifico è meno forte, quindi li rafforza entrambi, facendoli passare a un livello superiore di profondità. Inoltre è sbagliato pensare che il rollbacker sia un flag più "impegnativo". Perché il flag che non è il RB si vorrebbe creare al momento assume dei connotati di flag da connettivista abbastana marcati e la connettività è impegnativa. nel senso che richiede un'analisi dei meccanismi e degli equilibri fra le voci abbastanza complessa. Si nota solo di meno in superficie, ma questo non la rende meno faticosa e spesso bisogna tanto con gli utenti per spiegare nel dettaglio ogni equilibrio di fattori.

infine vi ricordo che noi dobbiamo comunicare a livello SUL con altre wiki. Quando si valuta un candidato su meta o si fanno analisi statistiche per gli strumenti che servono in futuro (i soldi delle vostre quote a wikimedia, per capirsi) un punto di partenza comune è necessario. Quindi qualunque flag si voglia dare converrebbe non crearselo in modo troppo creativo salvo emergenze di grandissimo livello. Semplicemente si può come in altre wiki creare una pagina unica di attrbuzione dei flag, dove i candidati possono chiedere due flag alla volta. per intendersi en:Wikipedia:Requests for permissions andrebbe creata anche da noi come approfondimento operativo di Wikipedia:Livelli di accesso degli utenti. In questa pagina si elencano tutti i modi di ottenere flag e poi al limite si scorporano le procedure più impegantive o con più storia o più richieste (p.e. i rollbacker, come già succede su enwiki). In fondo alla pagina rimane un ambiente di candidatura unico per i flag meno frequenti. Semplice e flessibile, e può durare anni quale che sia l'evoluzione dei flag. Se il flag diventa una cosa seria, ce lo scoproriamo in una procedura a parte. Altrimenti ambiente unico. Così facendo ci si può candidare comunque per più flag nello stesso momento senza però dover fare miscugli di flag.

in sintesi: ci sarà sempre in futuro un terzo flag proposto oltre a RB e file mover, quale che esso sia. Non corriamo a fonderlo con uno esistente per "semplificare", impariamo a ragionare in uno schema flessibile, perché se non lo facciamo adesso, comunque lo dovremo fare fra tre o quattro anni.--Alexmar983 (msg) 12:48, 21 mag 2015 (CEST)

Veramente i trattori sarebbero serviti pure con venti milioni d'abitanti in quanto hanno un ricavo marginale (in senso lato) positivo sempre.

L'idea di unire le pagine è sensata, la moltiplicazione dei flag in ragione (?) della flessibilità (?) no.

Fare il paragone con en.wiki non tiene conto di una banale realtà: su it.wiki in media ci sono sempre due o tre occhi su special:recentchanges. I problemi macroscopici (quali spostamenti a caso) non passano, su en.wiki è impossibile. Ragion per cui en.wiki ha *progressivamente* sviluppato una struttura elefantiaca che si regge sui grandi numeri.

Sono stato testimone di catastrofici tentativi di impiantare una maxi-struttura su progetti con 50 edit al giorno o di creare cinque o sei flag da para-admin da millesimare nel corso di un complesso cursus honorum: roba che vista dall'esterno raggiunge vette di autereferenzialità pericolosissime.

Ciò a cui si deve puntare è la reciproca responsabilizzazione e fiducia, nel mio modello ideale i diritti sarebbero raggruppati in diritti connessi all'editing e in diritti amministrativi, da entrambi derivano responsabilità che devono essere chiare e accettate: un autopatrolled ha mano "quasi" libera sui contenuti e se abusa di quel che può fare perde il suo status, come avviene con admin e compagnia cantante.

Tornando alla situazione attuale il suppress serve a chi sposta immagini perché il redirect del file va comunque eliminato, a mio giudizio ha poca attinenza col rollback mentre la avrebbe con l'autopatrol, se come vedo la mia posizione è minoriataria a 'sto punto aggiungiamolo al filemover e creiamo un gruppo ad hoc.

--Vito (msg) 13:08, 21 mag 2015 (CEST)

il fatto che servissero non significa che lo capissero. Dal loro punto di vista non serviva, perché avevano già chi lavorava, e gli sarebbero servite nuove competenze tecniche etc e si sarebbe trovati con tempo libero da reinventare in altre attività che non volevano fare etc ti avrebbero detto che era più utile una pianta a maggiore resa o un concime più efficace, non un trattore. Solo chi era grande abbastanza o piccolo con una visione lungimirante lo capì, e fissò il cambiamento, chi era piccolo ma con una visione limitata lo ritardò per se e non ottenne altro risultato.

il punto di fondo è che NON siamo un'isola e quindi se vogliamo isolarci lo dobbiamo fare analizzando bene i costi e i benefici. Altrimenti poi non avremo le energie per tutelare la nostra indipendenza dove serve davvero.--Alexmar983 (msg) 13:17, 21 mag 2015 (CEST)

Eh ma prima bisogna ampliare la ristretta visione dei wikipediani italici, chissà se magari arriverà un Prometeo a portarci il fuoco.

(A margine la concimazione fu più utile della lavorazione meccanica fin quando lo sviluppo dell'industria chimica non aumentò a dismisura la quantità di "scarti concimanti")

Motti e slogan a parte mi pare che in ogni discussione di questo genere ci si riferisca ad altre wiki, dov'è l'isola quindi? --Vito (msg) 13:26, 21 mag 2015 (CEST)

certo che fu più utile il concime, ma non è un motivo per non prendersi un trattore, no? Infatti il bisnonno che se lo prese subito giovò della migliore concimazione come quello che se lo prese dopo, l'unica differenza è che si trovò con un figlio meccanico, mentre l'altra famiglia non era cresciuta di reddito.

la nostra visione non è tanto limitata, noi abbiamo un know-how in termini di gestione flag superiore oramai a moltre altre, semplicemente non lo valorizziamo. Questa è la nostra isola. Ci convinciamo a voler creare soluzioni "originali" che non si filerà nessuno invece di allinearsi a un sistema che funziona comunque portandoci la nostra novità. Gli altri comunque spinti dalle loro necessità di flusso svilupperanno soluzioni alternative che poi per ovvia pressione saremo costretti comunque a adottare. Se si vuole essere originali, ci vuole stile, non i mappazoni.

mischiare filemover e suppressredirect, quando le altre wiki hanno solo il filemover è solo confusionario, così come lo è concedere quel flag agi AV direttamente. Non è un caso che la discussione su meta non abbia fatto menzione di queste possibilità.--Alexmar983 (msg) 13:43, 21 mag 2015 (CEST)

Se è vero che altrove ci sono le soluzioni out of the box che vanno bene per i flussi maggiori non c'è nemmeno bisogno di prepararsi da ora perché tanto basterà importare il tutto in futuro.

Non funziona così e lo sappiamo: ogni comunità linguistica produce il suo apporto originale, non è nemmeno detto che la soluzione ottima sia una sola inoltre. Nella fattispecie quali sono le obiezioni *reali* a dare il suppress anche ai filemover di default?

--Vito (msg) 14:50, 21 mag 2015 (CEST)

appunto, ma se una wiki locale imposta un sistema non-flessibile che non si interfaccia con le altre e le sue novità quegli apporti NON li dà. Evitiamo di fare la Francia della situazione.

che il flag dato ANCHE a un altro flag non significa unire il flag. Se vuoi dare il flag di default ai file mover (specificando in canddiatura che è automatico, come per il rinnovo admin-burocrate) non ho nulla in contrario. Ma un flag unico, o dire che implciitamente il filemover ha il suppressredirect, e nell'elenco dei flag del SUL compare solo il primo, rimango contrario. Una cosa è il concetto, una cosa la gestione oeprativa. Se vuoi interagire proficuamente con le altre wiki devi usare concetti semplici, modulari. Poi te li gestisci come ti pare.--Alexmar983 (msg) 15:02, 21 mag 2015 (CEST)

(La povera e debole Francia)

Definisci "non-flessibile", "non interfacciarsi" e "interagire" in maniera concreta per cortesia. Perché sono tutte cose belle come enunciato ma sono ad alto rischio di fuffa.

Nel caso concreto io ho proposto di unirlo all'autopatrolled (gruppo più grosso) in prima istanza.

--Vito (msg) 15:19, 21 mag 2015 (CEST)

(Non è povera o debole in sè, è solo sempre meno rilevante, perché non ha difeso le sue specificità dove le serviva prioritariamente ma per principio, in modo rigido, e adesso non ha le migliori risorse per difenderle dove le servirebbe davvero)

flessibile significa che ogni nuovo flag che arriva può ragionevolmente essere collocato in un'architettura già impostata. Se tu definisci per tutti i flag AV avanzati vincoli simili di decadenza, di ottenimento e di area di azione (=voci e non utenze) ogni funzionalità proposta che scorpora una funzionalità di admin può inserirsi in quello schema. Quindi non devi perdere ore a scervellarti a appicicarla da una parte o dall'altra, e a chiarire tutti i possibili micragnosi dettagli e incogruenze possibili, perché ha un suo ruolo ben specifico di default. Questo lo imposti bene in Wikipedia:Livelli di accesso degli utenti dove chiarisci che possono essere di base (automatici), Autopatrolled (più o meno automatici), Autopatrolled avanzati, sysop, sysop avanzati (burocrati, check user), meta ... Invece se hai una pagina di raccordo per l'attribuzione dei flag (quella che a noi manca) puoi scegliere in ogni momento per un nuovo flag minore se gestire lì la candidatura o creare un'ambiente specifico (e collegarlo via wikidata alle lingue che hanno anch'esse candidature più avanzate). In questo modo puoi anche adottare caratterirstiche di un modello o dell'altro, da cui l'interfaccia. Se decidi di attribuire il flag AV in automatico come dewiki ad esempio, cancelli il modello di candidatura per gli AV ma magari lasci una possibilità di candidatura straordinaria nella pagina generale di concessione flag per casi eccezionali. Se concordi p.e. con quanto fatto da eswiki di unire burocrate e admin, metti un template storico alla parte delle procedure specifiche dei burocrati e lo scrivi nella pagina di raccordo. Puoi accorpare e scorporare, approfondire e gestire come più ti aggrada ma applicando soluzioni che hai già inquadrato, che non ti devi inventare ogni volta di nuovo. Quando presenti un nuovo concetto alle altre piattaforme presenti sia il concetto del flag (=la funzionalità) che la sua collocazione rispetto agli altri esistenti, che la sua gestione operativa, e loro possono prendere l'aspetto che preferiscono. Quindi puoi interagire perché di ogni modello vedi più facilmente se vuoi adattarlo e come adattarlo nel modo più semplice possibile senza cambiare l'architettura di fondo.

il tuo caso concreto di unire dorettamente all'AV è stato scartato mi pare dalla maggioranza degli intervenuti, con le motivazione che puoi leggere.--Alexmar983 (msg) 15:48, 21 mag 2015 (CEST)

Aggiungo due osservazioni di ordine generale:

1) essere piccoli o medi non significa "pensare in piccolo o mediocremente (perché è nell'ordine naturale delle cose)", significa "scegliere su cosa pensare in grande", altrimenti è certo che si rimane piccoli per sempre e non si cresce mai, invece è giusto concedersi una probabilità ogni tanto. Adesso che le utenze formano a livello operativo sempre più un unicum integrato se c'è un'area in cui è miope pensare "in piccolo" e chiudersi in una specificità "chiusa" è proprio quella della gestione delle utenze. In ogni caso sempre lieto di valutare ogni esempio di disastri a cui si accennava. Probabilmente si tratta di piataforme che non avevano una visione analitica come la nostra.

2) Faccio notare che noi non stiamo importando nulla. Qua, alemno mi pare, la sfida non è essere originali, questa discussione è molto più originale di quelle che si leggono da altre parti, ma di essere capaci di coinciliarlo con un sistema più ampio di cui bene o male facciamo parte, ovvero i flag delle altre wiki. I flag hanno, nella mia esperienza, tre aspetti: 1) la funzionalità 2) il rapporto con le altre funzionalità 3) le modalità di assegnazione. Quando si gestisce un flag si deve avere una visione insieme di come questi aspetti si integrano. In teoria il rapporto con le altre funzionalità ha aspetti che ormai sono stabili a livello cross e metawiki (p.e. la "scala" AV/rollbacker/admin su cui mi pare ci sono state persino analisi statistiche pubblicate) ma c'è un margine interessante, ed è proprio per questo servirebbe scrivere bene Wikipedia:Livelli di accesso degli utenti, curando anche l'aspetto dei flag che noi non abbiamo ma altri hanno. Invece l'adattamento di en:Wikipedia:Requests for permissions (qua c'entra nulla che enwiki "è grande", ce l'hanno altre wiki piccole) è per fare un ordine nelle modalità di assegnazione. In questo modo tutte le volte che si definisce o importa una nuova funzionalità si sarebbe guidati naturalmente a occuparsi in primis di queste due pagine di raccordo e quindi di vedere se la nostra impostazione sugli aspetti (2) e (3) funziona. Con una impostazione fatta bene, in cui si seprano i concetti di base da come noi abbiamo deciso di assemblarli, i nostri utenti avranno una marcia in più nell'orientarsi su tutte le altre piattaforme, a capire subito cosa è simile e cosa diverso.--Alexmar983 (msg) 17:42, 21 mag 2015 (CEST)

In maniera retorica ti potrei dire che la mia proposta era troppo avanti per 'sti rottamandi ^^

Se non ho un deficit dell'attenzione me lo stai causando tu, riassumi cribbio e stracribbio!

Il pensare in grande o in piccolo è solo un slogan, nel concreto quello che serve è una struttura adatta ai requisiti, la scalabilità è un problema secondario qui a maggior ragione se le strutture si mantengono essenziali.

Per la verità le pagine di richiesta separate ci sono non per ragioni numeriche (anzi ci si dovrebbe aspettare il contrario) ma semplicemente perché è un uso consolidato a partire dalle scelte iniziali, se si vogliono ridurre a due è un'idea che mi trova d'accordo.

Per il resto la decadenza per 'sti flag è un'esagerazione non da poco.

--Vito (msg) 00:04, 22 mag 2015 (CEST)

se la tua proposta è avanti stai tranquillo che definendo bene i flag non farai che facilitare la sua naturale evoluzione.

la scalabilità e la modulabilità sono problemi secondari rispetto a cosa? Rispetto ai flag principali come l'AV o il sysop si. rispetto ai possibili flag nuovi non sono un problema secondario, sono solo un problema che non è mai stato affrontato, che è una cosa diversa.

in genere è chi parla breve che usa slogan, non chi parla in modo articolato. Niente di quello che dico è mai uno slogan, viene dalla mia esperienza e ricordo che a me viene SEMPRE chiesto di dimostrare quello che dico. Io ho articolato su richiesta, vediamo se tu sei capace di fare in modo breve un esempio dei disastri/problemi che citavi di strutture troppo complesse di flag adottate su altre wiki. pensiamo che lo troveremo tutti interessante.

non ho mai detto che le pagine di richiesta separate ci sono per ragioni numeriche, mi pare che il punto fosse che ci possono non essere per ragioni numeriche, in futuro.--Alexmar983 (msg) 00:15, 22 mag 2015 (CEST)

In realtà cazzeggiavo, non ho 'ste pretese e ho trovato stucchevole la retorica della rottamazione prima ancora che andasse di moda.

Sono problemi secondarsi in senso assoluto visto che questo tipo di strutture è facilmente rimpiazzabile in un progetto per sua natura liquido, a che tali strutture si mantengano semplici.

Politica e commercio a parte non so dove non venga chiesto di dimostrare quel che si dice, quindi non è che fai un'eroica eccezione. Esageri come prolissità, senza per questo essere più informativo o chiaro, anzi il contrario. Ti dico slogan perché onestamente mi sembra tu sia caduto in una trappola retorica nella quale la ripetizione di concetti astratti, a vario titolo poco attinenti, ha precedenza rispetto alle necessità pratiche.

I casi che ho gestito personalmente li avevo citati prima senza specificarli: hi.wiki per i flag frullati e it.voy per il casotto di ammenicoli in stile en.wiki.

Sul discorso delle pagine di richiesta non ho letto una simile obiezione, ma magari sono io a non averla notata eh.

--Vito (msg) 00:40, 22 mag 2015 (CEST)

mi dispiace ho poco il senso del cazzeggio non so immedesimarmi in te, anche perché pure io trovo stucchevole la retorica della rottamazione, ma non capisco che c'entri.

Non direi che wiki è liquido, è un fluido ed è a viscosità alta come bassa, che va omogeneizzandosi. Si è iniziato dalle voci (la connettività), si è proceduto con l'aumento di raccordo e verifica delle pagine di aiuto, e adesso con il SUL tocca alle utenze e ai progetti. Cinque anni fa si univano e scoproravano voci senza guardarsi intorno (categorie? altre lingue? non sia mai!), oggi sostanzialmente no. I flag non si comporteranno diversamente. Difendere l'autonomia operativa in queste condizioni richiede sempre più di aver ben chiaro la situazione generale, mai di ignorarla.

per dimostrare intendevo definire (ciò che mi hai chiesto, di definire). Non mi sento in una trappola quando passo a livelli di astrazione, mi sento anzi abbastanza libero: quello che ho proposto è pratico, perché permette in modo pratico di adattare ogni nuovo flag. Semplicemente ho astratto la richiesta (dove/come mettere il flag X >> dove/come mettere ogni nuovo flag), non la risposta, che è concreta: ci vogliono due pagine di raccordo impostate bene: una sull'ordine dei flag e una sulla loro attribuzione. Questo tipo risposte per te non sono mai state chiare, se mi ricordo bene, ma con altri ci intendiamo, e tanto mi basta per lavorare. Un giorno io sarò perso nei meandri degli archivi e non esisterò più, in quest'ottica preferisco essere stato preso in giro per aver detto qualcosa in modo lungo, ma possibilmente corretta, che essere stato lodato per aver detto qualcosa di sbagliato in modo breve. Anche perché quando parlo breve mi viene più facile da giudicare gli altri a volte, e preferisco evitarlo e perdermi nei problemi.

non capisco cosa siano i "flag frullati", e per quanto riguarda it.voy non ho capito cosa avrebbe preso da enwiki. Personalmente con i progetti nuovi io userei uno schema di base AV poi sysop poi burocrati e solo a quel punto, completate la piattaforma-base, lo allargherei con gli altri flag. Dal mio punto di vista importare in blocco flag che non ti servono o cercare di semplificare accorpando flag diversi che ti servono sono azioni ugualmente superficiali. Per uno come me che vede i flag come un'insieme di moduli definiti in modo universale ma combinati/selezionati diversamente in funzione delle comunità, importare un ammenicolo o copiare in toto un sistema di flag da un'altra wiki non ha semplicemente senso.

si scorporano le procedure più impegnative o con più storia o più richieste non mi sembra affatto dire che si ritiene che le procedure scorporate siano tali per via dei flussi di richieste, e non capisco quindi Per la verità le pagine di richiesta separate ci sono non per ragioni numeriche. Non capisco nemmeno come avrei potuto obiettare che procedure separte esistano per ragioni numeriche... ho assistito p.e. alla nascita del filemover, e so per certo che non ha mai avuto molte richieste.--Alexmar983 (msg) 01:45, 22 mag 2015 (CEST)

ah dimenticavo, la decadenza di questi flag non mi sembra un'esagerazione. In teoria è curioso che l'AV non decada, visto com cambiano le linee guida e lo stile nel corso degli anni. Alla luce di questo e del fatto che i sysop e i rollbacker decadono per inattività, credo che finire per valutare la decadenza dei flag "AV avanzati" sia una cosa abbastanza normale.--Alexmar983 (msg) 01:45, 22 mag 2015 (CEST)

Cinque anni fa si univano e scorporavano voci senza guardarsi intorno (categorie? altre lingue? non sia mai!) Madonna mia! Ma ti rendi conto di cosa scrivi? --Retaggio (msg) 09:49, 22 mag 2015 (CEST)

[↓↑ fuori crono]Sì.--Alexmar983 (msg) 11:22, 22 mag 2015 (CEST)

Ovviamente ti rendi anche conto che si tratta di cosa palesemente errata, vero? E 2015 meno 5 fa 2010, vero? --Retaggio (msg) 12:06, 22 mag 2015 (CEST)

2015 meno 5 fa 2010, sì. Se vuoi ti rifomulo la frase (lo vedi cosa succede a essere sintetici?), ma quel concetto nel suo senso è corretto. un tempo faticavo sette camice a risistemare ingarbugliamenti e incorenze, oggi molto meno. --Alexmar983 (msg) 13:09, 22 mag 2015 (CEST)

OK, visto che persisti, ti offro una via d'uscita amichevole al fosso in cui sei finito ;-) Diciamo che 5 anni fa (2010) eri niubbo e faticavi sette camicie e ora che sei bravo non più. Ma non è che cinque anni fa si univano e scorporavano voci senza guardarsi intorno: le procedure relative erano le stesse di oggi, l'albero delle categorie era in larga parte già formato, persino Hotcat già esisteva [1], e gli interlink non li metteva Wikidata ma c'era un continuo andirivieni di bot che venivano dalle wiki più disparate per aggiungere, modificare e togliere. E noi utenti (quelli già allora non più niubbi) stavamo ben attenti a controllare che tutto il meccanismo girasse nel verso giusto e senza intoppi. :-) Bye, buona Wikipedia. --Retaggio (msg) 13:24, 22 mag 2015 (CEST)

non c'entra essere niubbio. Quando ho inziato c'erano tanti ingarbugliamenti ovunque, oggi non ci sono. Non c'entra cosa faccio io, li facevano altri. L'andirvieni di bot non aveva avuto alcun effetto sul ridurre gli ingarnugliamenti, anzi l'aveva peggiorato perché spesso ci si limitava a mettere una lingua mentre con wikidata si è costretti a guardarle tutte. Nelle PdC non si guardava mai il "puntano qui" (una cosa semplicissima)... ricordo la sorpesa quando dopo un anno di miei commenti vidi qualcuno analizzare questo aspetto senza che lo facessi io. Non si poteva suggerire di cercare voci in cancellazione fra le O pena di essere definiti problematici, ora una cosa del genere la propongono gli ex admin. Le cose sono cambiate e molto nel profondo. Liberi di pensare che sia una cosa più leggera di come è stata, ma secondo me è un errore di valutazione. Queste forme di convergenza operativa sono processi trasversali che provengono sia dall'alto che dal basso, quindi destinati a durare e evolversi. In base a questo assunto ho deciso e decido di cosa occuparmi. Assumendo che ogni opposizione sarebbe risultata temporanea e costosa in temrini di energie, ho iniziato a immaginare il progetto connettività prima ancora che esitesse, c'è un mio post in cui dicevo che arebbe arrivato qualcosa di simile a wikidata prima ancora che arrivasse, stesso con la fine del principio di analogia che poi è stato ridimensionato, idem col SUL etc. Non so come comunicarti il fatto che io non mi sento né in una fossa, né in una gabbia. Anzi in genere è quando trovo una reazione scettica da utenti esperti che so che per esprienza le cosa stanno per cambiare nell'arco di 12-18 mesi.--Alexmar983 (msg) 13:45, 22 mag 2015 (CEST)

Lieto di verificare che hai aggiustato il tiro. Comunque, non è vero che non si guardavano gli interlink, semplicemente si andava "a mano" sylle altre wiki. Ricordo bene che tutti i miei contributi pre-wikidata sulle altre wiki erano praticamente solo aggiustamenti di interlink. Non è vero poi che non si guardavano i "puntano qui", semplicemente lo si è sempre fatto. Riguardo le Orfane, credo che siano ormai da dieci anni che se ne parla. Le cose sono cambiate, è vero, è inevitabile dato che un wiki è un continuo work in progress e in continua evoluzione, ma ti posso assicurare che le cose si facevano con rigore, coscienziosità e responsabilità anche cinque anni fa. Certamente non "senza guardarsi intorno" o trascurando categorie e interlink. Saluti. --Retaggio (msg) 14:41, 22 mag 2015 (CEST)

Ah, a proposito, guarda che la mia reazione non è "scettica". E' invece "offesa" e "incredula". Ri-saluti. --Retaggio (msg) 14:47, 22 mag 2015 (CEST)

(f.c.) Ho solo specificato. Comunque io non ho detto che non si guardavano i "puntano qui", ho detto che non lo si faceva in PdC, ti ci posso mettere un "quasi" ma mi sto solo sforzando di usare meno perole. Che un lavoro fatto anni fa mancasse visto oggi di visione d'insieme in certi punti guarda che si applica a ogni cosa. Potevo citare i fdQ ad esempio. Ogni attività è frutto del suo tempo, quello che facciamo oggi sarà inadeguato domani. Me lo dico ogni giorno su quello che faccio io, a scanso di equivoci, visto che ancora non ho capito cosa verrà dopo questo ciclo di wikipedia. E non penso che il mio bisnonno poco lungimirante su quell'aspetto non valesse di meno dell'altro, ho usato apposta qualcuno che era sangue del mio sangue per fare un esempio. A me è stato detto da quando sono qua che mi viene detto che sono inadegauto, troll, "mischio mele e pere" e "non ho capito nulla". Se ci riesco a stare sereno, guarda puoi riuscirci tranquillamente a offenderti di meno per qualcosa che non ti critica in nessun modo come persona.--Alexmar983 (msg) 15:22, 22 mag 2015 (CEST)

(fuoricrono)Essere meno prolissi non significa levare le parole utili, altrimenti diventa austerità anticiclica ^^

Guarda personalmente credo che tu abbia il vizio di schiacciare le noci col maglio, cioè applicare qui metodi che sono fuoriposto per numeri e soprattutto natura di 'pedia (basata sul volontariato). Poi su 'sto fatto ci carichi una retorica un po' goffa come sopra (non ti rendi conto che parlare del bisnonno fa tanto tanto superbia trifolata) e una sistematica violazione della settima proposizione di Wittgenstein (i puntano qui si guardavano dai tempi del cucco, una repository centralizzata per i redirect l'avevamo pensata in tanti a memoria mia verso il 2009) e succede il patatrac.

--Vito (msg) 15:29, 22 mag 2015 (CEST)

io uso ciò che alla lunga mi funziona, se mi funziona perché sarebbe fuori posto? Essere goffo mi ha aiutato a immedesimarmi in chi era un novizio, e mi aiuta tutt'ora, e lo considero più uile per quello che faccio che convincere chi è scafato. Per la cronaca ricordo che la frase sui puntano qui continuava con una seconda parte, e ti faccio notare che non ho mai detto di aver pensato qualcosa per primo, solo di averle pensate in modo indipendente. Siete voi che ci volete caricare dei significati che per non ci sono. L'uso di Wittgenstein credo sia un uso comune ma errato usato da chi vuole un modo colto di dire "stai zitto" o qualcosa del genere. Non capirò mai perché uno come te che usa retorica e artifici a badilate si debba sempre incaponire su sta cosa... seriamente, se ti da tanto fastidio inizia da te stesso, su quello almeno tu hai controllo. Credo che darmi del superbo sia sbagliato: i superbi hanno un orgoglio e una soddisfazione che io non ho (io cerco sempre di essere insoddisfatto per fare cose nuove), e non ho una stima esagerata di me altrimenti non sopravvivevo anni con la roba che mi viene detta. Poi ci puoi anche mettere un "trifolato" davanti ma non vuol dire nulla ed è a occhio un modo "furbo" di dire tutto e il contrario di tutto. Ars retorica, molto buona, per carità, ho sempre detto che dovevi fare il politico. Per il resto lo so di essere un disastro a essere sintetico, l'ho sempre detto.--Alexmar983 (msg) 15:57, 22 mag 2015 (CEST)

Ti funziona, hai detto bene, non è detto che vada bene per il sistema che intendi plasmare.

La modestia è un peccato, mi pare lo dicesse Tommaso.

Occhio a non confondere la dialettica con la retorica, la prima veicola significati, la seconda no. Non confondere nemmeno l'inesperienza con la goffaggine, la prima viene meno da sola, la seconda richiede uno sforzo continuo.

Leggo un voi ma non capisco a chi ti riferisca, noi non usiamo mai le nostre prerogative in questo luogo virtuale, a noi piace non prenderci troppo sul serio ma senza per questo far venire meno ciò che vogliamo comunicare. Crediamo che la politica non sia un male, ma sia anzi uno dei massimi servizi, quindi chi ti dice che non ci siamo già?

--Vito (msg) 16:26, 22 mag 2015 (CEST)

plasmando? Se volevo plasmare le cose sarei stato molto più sottile, se le dico apertamente è proprio perché non mi interessa plasmare alcunché. probabilmente cadrebbe tutto come un castello di carte una volta che me ne vado, sarebbe una roba da frustati all'ennesima potenza. Se vuoi dare a quel "mi" un significato profondo, fai pure, ma vorrei dire che è soltanto un qualcosa che funziona nella mia esperienza personale (mi + funziona). Non funziona PER me ma funziona A me.

la modestia in un luogo dove la propietà intellettuale non esiste non è un peccato, è una scelta logica. Il modo fuori è vasto, ed è un'altra storia.

non mi sembra di essere poco dialettico, se avessi passato anni a fare solo retorica come sembri implicare, la mia attività qua non avrebbe nulla di concreto. in genere è sul lungo periodo che vedi chi ha contenuti e chi no. L'inesperienza per chi non è "superbo" non viene mai meno. Chi sa di poter migliorare o fare qualcosa di nuovo sa sempre di essere inesperto. Quindi fa ridere che "vada via" perché in senso assoluto non va MAI via, per me è superficiale pensarlo. Ti assicuro che la goffaggine non richiede uno sforzo. semplicemente se ti dedichi a fare sempre cose nuove, è naturale. Dove smetto di fare cose nuove, se noti io divento molto meno goffo e più diretto. nessuno sforzo artificioso eh :D.

intendo voi che mi punzecchiate da stamani, che sembra che sono chissà quale superbo promoteo salvatore. In ogni caso in questi luoghi virtuali a me non sembra che non vi pendiate sul serio, le volte che ho fatto leggere certe discussioni a terzi vi assicuro che si comunicava abbastanza il contrario. Soprattutto quelle ironiche.

non credo che la politica sia un male. A volte l'ho fatta in ambito civico non elettorale, e con buoni risultati. ho sempre evitato di usare lo stile da politico "politicante", tanto è che facevo schifo in pubblico, curiosamente non ho mai giudicato un problema che un politico sia un manipolatore se produce un risultato.--Alexmar983 (msg) 16:57, 22 mag 2015 (CEST)

Eh, caro Ret, non te la prendere... Anche se a leggere certe cose, pare che qualcuno pensi di essere il "salvatore" di Wikipedia, lo sappiamo bene che non è così. --Euphydryas (msg) 15:02, 22 mag 2015 (CEST)

e chi sarebbe questo salvatore? Se me lo presenti non vedo l'ora di ricordargli che wikipedia "si salva" benissimo da sola (qualunque cosa poi voglia dire usare il verbo salvare, non vedo particolari pericoli all'orizzonte)--Alexmar983 (msg) 15:12, 22 mag 2015 (CEST)

Mah... forse se rileggo con calma per tre volte il tutto, ci capisco qualcosa. Problema mio, evidentemente: ultimamente mi sarò un po' intontita. :P --Euphydryas (msg) 10:24, 22 mag 2015 (CEST)

A me succede lo stesso con tanti commenti lunghi e brevi di altri, che sono molto lodati. Mai sottovalutare la dimensione personale.--Alexmar983 (msg) 11:27, 22 mag 2015 (CEST)

Ma onestamente se continui così quando uno ti trova negli archivi passa a leggere un'altra pagina (questa discussione l'hai ammazzata eh, ne ho dovuto aprire una nuova). Il livello d'astrazione non lo alzi in senso "informatico" ma lo alzi nel senso di allontanarti dalla realtà. --Vito (msg) 12:21, 22 mag 2015 (CEST)

l'abbiamo ammazzata insieme Vituzzu, senza di te sarebbe andata molto diversamente. Io non ho problemi a assumermi la responsabilità di quello che dico. In fin dei conti se io sbaglio così tanto, perché ottengo dei risultati? Qualsiasi altra cosa otterrei in più facendo diversamente, credimi, non darebbe alcun vantaggio a wikipedia. Sarebbe solo vantaggioso per me, ma a me non interessa.--Alexmar983 (msg) 13:09, 22 mag 2015 (CEST)

Se ti fa piacere puoi credere quel che vuoi ma davvero torna coi piedi per terra, questa retorica dell'eroico Prometeo de' noantri non rende affatto giustizia a tutto ciò che puoi essere. --Vito (msg) 15:18, 22 mag 2015 (CEST)

Per essere Prometeo bisogna essere vittime e io NON sono una vittima. Sono coi piedi per terra, quando qualcuno mi loda cambio argomento alla velocità della luce. Cerco esplicitamente di lavorare con persone che criticano quello che dico (criticare non è offendere) e poi Prometeo non lavora da solo?. Se qualcuno mi dedicasse una poesia io ad esempio mi turberei. Smetto di votare a dare una maglietta agli altri nel momento che qualcuno mi candida e vota. Chiedo di non avere la stessa stella l'anno successivo. Do soldi senza volerne uno indietro. Vai tranquillo che non m'aspetto nulla. Non penso che abbia senso ragionare in termini di ciò che puoi essere in un ambiente in cui c'ho che fai non sarà mai nemmeno tuo. ma ti prego dimmi cosa potrei essere, probabilmente ti dirò perché non mi interessa.--Alexmar983 (msg) 15:39, 22 mag 2015 (CEST)

Se la terra è la cima di una montagna incantata il discorso rimane uguale. A leggere i continui riferimenti ai posteri che ti daranno ragione un po' di vittimismo c'è ma in realtà liquidare Prometeo come una vittima è un profondo frainteso del mito.

Vedi che continui col vizio dei tentativi di cogliere in castagna che ti si ritorcono contro? Con [@ Gregorovius] ci canzoniamo da un cinque o sei anni, nelle poesie è palesissimo. Comunque sono sicuro si possa fare un elenco generato offline sulle canzonature amichevoli che ti dimostri che chiunque se ne sarebbe reso conto. --Vito (msg) 16:26, 22 mag 2015 (CEST)

Mobbasta, questa pagina serve ad altro. Personalmente mi dispiace si sia dovuti passare subito al voto, perché c'erano ancora spunti interessanti da esplorare (tipo le implicazioni di ciascuna proposta e i meccanismi, anche indesiderati, che si possono sviluppare). Ma tant'è. --Dry Martini confidati col barista 16:40, 22 mag 2015 (CEST)

Estensione del suppressredirect

cb La discussione proviene dalla pagina Wikipedia:Bar/Discussioni/Estensione del suppressredirect#Estensione del suppressredirect.
– Il cambusiere Fullerene (msg) 23:05, 30 giu 2015 (CEST)

Nella precedente discussione si è proposto di estendere la platea di utenti col suppressredirect (cioè la possibilità di non creare un redirect quando si sposta una pagina).
Per mantenere la discussione ordinata vi chiedo la cortesia di limitarvi a esprimere uno stringatissimo parere.
Quesiti:

1. Creiamo un gruppo ad hoc?
2. Lo assegnamo di default a qualche altro gruppo attuale?
3. Chi lo assegna?
4. Chi lo rimuove?

--Vito (msg) 00:50, 22 mag 2015 (CEST)

---

• Sì, filemover, admin, burocrati. --Vito (msg) 00:50, 22 mag 2015 (CEST)
• Si, indeciso, admin, admin Jalo 08:34, 22 mag 2015 (CEST)
• Sì; filemover (e formalizzare l'utilizzo da parte dei bot); admin; admin (come fanno per sé stessi). --Horcrux_九十二 10:11, 22 mag 2015 (CEST)
• Sì, filemover, admin, burocrati.--Euphydryas (msg) 10:19, 22 mag 2015 (CEST)
• Sì, filemover, admin, burocrati. --NewDataB (msg) 10:34, 22 mag 2015 (CEST)
• No, filemover (rinominato in mover?), burocrati o admin (IMO basta ci siano a monte un paio di altri pareri), burocrati. --Dry Martini confidati col barista 11:04, 22 mag 2015 (CEST)
• Sì No, filemover, admin, burocrati.--L736E^{l'adminalcolico} 11:19, 22 mag 2015 (CEST)
• No, filemover che diventa mover (come Dry M.), admin, admin. --Retaggio (msg) 11:25, 22 mag 2015 (CEST)
• Sì, no, amministratori, burocrati. --Gce ★★ 14:35, 22 mag 2015 (CEST)
• No, filemover, admin, burocrati. --Roberto Segnali all'Indiano 14:48, 22 mag 2015 (CEST)
• Sì, filemover, admin, burocrati. --Epìdosis 15:16, 22 mag 2015 (CEST)
• No (se si aggiungesse ai filemover imho non avrebbe senso anche un sottogruppo), filemover (trasformandolo in "mover" come dicevo in talk a Dry Martini), burocrati (secondo me diventerebbe il flag più delicato), burocrati. PS: eventualmente credo che siano completamente da rivedere anche le modalità di assegnazione e di revoca. --Fullerene (msg) 16:05, 22 mag 2015 (CEST)
• No, filemover, admin, burocrati. --Buggia 16:31, 22 mag 2015 (CEST)
• No, filemover, admin, burocrati. --Er Cicero 20:29, 22 mag 2015 (CEST)
• No, filemover, admin, burocrati. (No problem per ribattezzare filemover in qualcos'altro. anche se non essenziale) --Lepido (msg) 11:18, 23 mag 2015 (CEST)
• Sì, filemover, admin, burocrati. --Fabyrav parlami 11:20, 23 mag 2015 (CEST)
• Sì, no, admin, burocrati (in automatico per sei mesi di inattività nella funzione). --НУРшЯGIO^{(attenti all'alce)} 13:50, 23 mag 2015 (CEST)
• No, filemover, admin, burocrati (non sarei contrario a ribattezzare poi il gruppo in "mover" ma, giacché ci troviamo, non potremo dargli un nome in italiano, tipo "spostatori" o altro?).--Tenebroso discutiamone... 15:11, 23 mag 2015 (CEST)
• Indeciso, filemover, sysop, burocrate. --Umberto NURS (msg) 17:34, 23 mag 2015 (CEST)
• No, filemover (rinominato in mover o qualcosa di più italiano), admin, admin credo basti (anche se per ora il default è diverso senza molte ragioni imho). --Lucas ✉ 18:50, 23 mag 2015 (CEST)

  La ratio che potrei trovare io è che tendenzialmente i flag vengono rimossi da un gruppo utente più "alto", per motivi di garanzia, salvo per i rollbacker: sarebbe ottuso pretendere che un flag del genere dovesse essere rimosso da uno steward (l'unico altro che assegna i permessi), e si ha comunque l'aspetto garantista. Sarei per non perdere questo meccanismo: l'AV viene rimosso in situazioni "brutte" in cui un occhio terzo ed esperto è raccomandabile. Quanto al nome italiano, per me nessun problema: ci avevo pensato, ma mi erano venuti solo "spostatore" e "sposta-tutto" e sono bruttarelli. Potremmo scegliere un nome brutto apposta per scoraggiare i collezionisti di medagliette :D --Dry Martini confidati col barista 23:16, 23 mag 2015 (CEST)

• No, filemover (in italiano abbiamo il moviere ;) ), admin, burocrate (un flag del genere non credo abbia necessità di una garantita rapidità di rimozione: credo si possa ben attendere un burocrate). Al pari del file mover, lo lascerei "eterno".--DoppioM 14:42, 24 mag 2015 (CEST)

* No, No, Nessuno, Nessuno: penso che non sia nello spirito giusto estendere la platea di utenti che non possono fare una cosa e ha quel sapore di quelle espressioni che sembrano una cosa, ma sono un'altra (es. la mobilità).--Ettorre (msg) 16:52, 24 mag 2015 (CEST) Chiedo venia, invecchio :-) --Ettorre (msg) 17:41, 24 mag 2015 (CEST)

[@ Ettorre] mi sa che ti sei confuso: il suppressredirect è un diritto in più perché permette di scegliere se creare o meno il redirect quando di sposta una pagina. Attualmente invece quando sposti una pagina mediawiki te lo crea per forza. --Vito (msg) 16:55, 24 mag 2015 (CEST)

[@ Vituzzu] Grazie, come sopra, a volte mi capita ! ;-) son umano, chiedo venia --Ettorre (msg) 17:41, 24 mag 2015 (CEST)

No, No, admin, burocrati --Ettorre (msg) 17:41, 24 mag 2015 (CEST)

[@ Ettorre] scusa se ti pingo di nuovo ma se le prime due sono no le altre due perdono di significato perché non c'è niente da assegnare o rimuovere. --Vito (msg) 18:19, 24 mag 2015 (CEST)

[@ Vituzzu] scusa Te, si vede che oggi come di dice da me con altro termine, sono "fuso" :-) richiedo venia

• No, filemover, admin, burocrati --Ettorre (msg) 18:35, 24 mag 2015 (CEST)
• No, filemover, admin, admin. --Adalingio (dimmi tutto) 18:40, 25 mag 2015 (CEST)

---

Provando a fare una sintesi va bene bene se creiamo un gruppo "mover" (o "spostatori"? naaaaaa), assegnabile dagli admin e rimuovibile dai burocrati, che comprenda suppressredirect e spostamento immagini? --Vito (msg) 12:46, 25 mag 2015 (CEST)

sì, va pure bene bene, ma la differenza rispetto all'aggiungere il suppressredirect ai filemover in concreto quale sarebbe? La mera rinomina del gruppo (no, vi prego spostatori no, eh:-) o una duplicazione con filemover che non hanno suppress? -- g · ℵ (msg) 13:19, 25 mag 2015 (CEST)

Sì, aggiunta e rinomina, a scanso d'equivoci. --Vito (msg) 13:42, 25 mag 2015 (CEST)

ok, allora manca solo un nome (io voto per "mover" :-) -- g · ℵ (msg) 15:08, 25 mag 2015 (CEST)

Era stato proposto anche moviere (dal dizionario Hoepli: Militare che ha il compito di dirigere il traffico degli automezzi in zona di operazioni militari) e, onestamente, a me piace! :-P --НУРшЯGIO^{(attenti all'alce)} 16:24, 25 mag 2015 (CEST)

Per il codice della strada, durante i lavori sono movieri gli operai che alternano il traffico con le palette o li segnalano con le bandiere ;)--DoppioM 23:15, 25 mag 2015 (CEST)

Ma pure il celebre mobiliere. --Vito (msg) 16:27, 25 mag 2015 (CEST)

Dal citato Hoepli: Mobiliere - Chi fabbrica o vende mobili. Che c'entra??? :-)) --НУРшЯGIO^{(attenti all'alce)} 16:33, 25 mag 2015 (CEST) PS Ovvio che sto rispettosamente dileggiando... ma moviere ha un non so che.

q:Signori si nasce! --Vito (msg) 16:37, 25 mag 2015 (CEST)

Perché non chiamarli rinominatori (oppure reintitolatori)? In fondo, quando si sposta una voce le si cambia nome: mi sembra più attinente come termine rispetto ad un generico "spostatore" (o peggio ancora "manovratore", che già attribuiamo ai proprietari di un bot). -- Mess (what else?) 16:47, 25 mag 2015 (CEST)

Forse si farebbe confusione con le rinomine utente. Ma anche spostatore/mover è ambiguo, una pagina la può spostare anche un normale utente. Azzardo una proposta: suppressredirect (sì, nome uguale alla funzione che ricevono), o equivalente in italiano. --Roberto Segnali all'Indiano 17:19, 25 mag 2015 (CEST)

"titolisti"? non è che sia più di questo, eh -- g · ℵ (msg) 17:21, 25 mag 2015 (CEST)

Ho trovato questo logo che potrebbe essere adatto al nuovo gruppo

[← Rientro] Per il nome non saprei ma, visto che siamo la prima wiki a creare un gruppo simile (credo), preferirei un nome italiano, se non altro per essere originali fino in fondo :) Comunque, prima di provvedere a rivedere le modalità di assegnazione e di revoca, guardando le varie funzioni che riguardano gli spostamenti, mi è venuto in mente che potremmo aggiungere al "pacchetto per spostatori" anche il move-subpages visto che ci siamo; la butto là, nessuna esigenza, ma penso che se agli utenti si chieda di essere pratici degli spostamenti ovviamente saprebbero gestire anche quest'altra funzione strettamente legata. Che ne dite? --Fullerene (msg) 18:28, 25 mag 2015 (CEST)

Buona idea. Per quanto riguarda il nome, se dobbiamo tenerne uno impronunciabile solo per questioni anglofobiche, preferisco quello in inglese. --Horcrux_九十二 18:36, 25 mag 2015 (CEST)

Va be', allora se c'è la gara, dico anch'io la mia :-) "Rinominatore", perché non mi è mai andato giù che su Wikipedia si usi il concetto di "spostare" quando in realtà si fa un semplice "rename"... --Lepido (msg) 20:47, 25 mag 2015 (CEST)

Appoggio Fullerene e Lepido :-) --Retaggio (msg) 09:27, 26 mag 2015 (CEST)

Movimentatore (o anche il più elegante mossiere, che sono sicuro piacerà a [@ Delfort]). --5.175.48.17 (msg) 14:38, 26 mag 2015 (CEST)

(FC) Ehi, ogni cosa al suo posto, il mossiere solo in Piazza :P --DelforT (msg) 20:19, 26 mag 2015 (CEST)

"Spostatori" mi sembra la scelta più ovvia. Sono favorevole ad aggiungere anche move-subpage. --Buggia 18:36, 26 mag 2015 (CEST)

se c'è spostamento c'è moto, e se c'è un moto ci sarà un motore, ma siccome il motore muove ma non si muove, e siccome bisogna anche dare un po' di importanza al ruolo a titolo di incoraggiamento, la scelta più ovvia imho è motore immobile :-)
Seriamente, facciamo così: partiamo con mover e poi se c'è consenso aggiungiamo, modifichiamo, decoriamo... ;-) -- g · ℵ (msg) 19:05, 26 mag 2015 (CEST)
Oppure "motore immobile", dai, almeno è originale :-)

Se c'è consenso anche sull'aggiunta del move-subpages, oltre che sui punti scritti da [@ Vituzzu], probabilmente al momento credo che sia meglio fare come suggerito da [@ Gianfranco], in modo da concludere passando alla revisione delle modalità di assegnazione e di revoca, che mi sembra che siano gli ultimi dettagli da decidere per partire col nuovo gruppo. --Fullerene (msg) 15:21, 27 mag 2015 (CEST)

Ok per aggiungere move-subpages. Modalità di assegnazione: come dicevo in altre discussioni, data la parziale eterogeneità dei permessi assegnati (si può dire che filemover porti familiarità con la casistica di suppressredirect, ma meno il converso, e sicuramente move-subpages è un terzo incomodo, che uno sa usare solo perché ci si è specificamente trovato, non ha particolari legami con altri ambiti), credo abbia senso non imporre solo criteri tecnici e quantitativi (anche perché, seguendo l'approccio usato finora per i file mover e - mutatis mutandis - per gli autoverificati, dovremmo pretendere la preesistenza di x contributi per ogni permesso assegnato, e se mai volessimo espandere questo flag le cose non potrebbero che complicarsi), ma valutare anche la generale conoscenza delle regole di wiki e tenere conto di altri aspetti "caratteriali" dell'utente (che nel lavoro sporco sono tipicamente considerati superflui e quindi lasciati fuori dalle attuali procedure di assegnazione dei flag "minori", IMO a torto); dopo tutto, se uno è un "buon utente" ci si può aspettare che sappia anche dove andare a cercare le linee guida che gli servono, e che sia in grado di capire quando fermarsi e chiedere un consiglio prima di fare disastri. Non un flag "al più simpatico", ma una responsabilizzazione degli utenti, un incentivo a chi fa lavoro sporco con cognizione di causa, passione e spirito critico e non perché è un modo per accumulare edit. Troppo idealista per un semplice flag? Mah. --Dry Martini confidati col barista 18:06, 27 mag 2015 (CEST)

complessivamente d'accordo, ma se ti stai basando sul move-subpages non credo che sarà mai di frequente utilizzo: non serve in ns:0 e in ns:file, per ns:utente e talk nelle rinomine (altrimenti è difficile che un terzo ci metta mano) in teoria c'è già sopra un burocrate, non penso che progetti e portali siano temerariamente spostati senza preventiva attenzione almeno di qualche sysop, restano le cat con le sottocat e i template (che hanno il /man) e pure queste son manovre non di tutti i giorni. Più facile che si parli di (alcune, e manco tante) pagine di servizio in ns:wp e aiuto, ma anche qui è più raro che infrequente. I casi concreti penso saranno pochissimi e limitati per lo più ai ns di discussione quando si sposta una voce o una pagina che ha archivi della talk. Diteci, ad esempio, voi sysop quante volte vi serve in un mese. Quindi sostanzialmente imho questo flag non è così cruciale. Diamolo, perché no, ma... quest'è, non di più; se la "moralità" dell'utente è riscontrata è sempre un'ottima notizia, ma non l'attesterei solo in funzione di questo flag, semmai è proprio sullo "spicciolo", sul più consueto (e frequente) spostare che non si fa notare allo stesso modo, che serve tutto quello che richiami :-) -- g · ℵ (msg) 19:39, 27 mag 2015 (CEST)

[← Rientro] Il move-subpages, oltre a servire raramente come dice [@ Gianfranco], mi sembra che alle competenze necessarie per poter usufruire del "pacchetto" aggiunga solo sapere che cosa sia una sottopagina, quindi per me niente di particolare. Per le modalità di assegnazione sono d'accordo anch'io con [@ Dry Martini], ma aggiungerei anche qualcos'altro di tecnico al "è necessario aver richiesto 5 spostamenti di file andati a buon fine" attualmente richiesto ai file mover. Per le modalità di revoca, visto anche che si propende per mantenerlo riservato ai burocrati, mi pare che quelle attuali per i filemover possano andare bene; in aggiunta credo che ci sia solo da valutare l'eventuale scadenza per inattività come fatto per i rollbacker e altri.

PS: per una mia comodità ad avere il quadro completo del nuovo gruppo sto facendo un abbozzo della futura pagina Wikipedia:Mover nella mia sandbox, dove per ora mi sono limitato a copiare quella dei filemover e ad apportare solo gli aggiornamenti ovvi. Se pensate che come base possa andare bene modificate pure liberamente. --Fullerene (msg) 20:35, 27 mag 2015 (CEST)

[@ Gianfranco]: hai perfettamente ragione, il move-subpages non si usa spesso (più che di volte al mese parlerei di volte nella carriera: io ricordo di averlo usato solo una volta quando si è riformata la Aiuto:Guida essenziale, e basta :) ), e infatti non era il centro del mio argomento, colpa mia se lo sembrava :) [@ Fullerene]: sì, chiaramente dei criteri tecnici ci vogliono e bisogna trovare una formula che non obblighi a saper usare ognuna delle funzioni previste, ma che assicuri comunque che questi verranno usati nel rispetto delle policy. Unico appunto: visto che siamo in tema di spostamenti, occhio a non perdere la crono di WP:File mover per strada quando creeremo la nuova policy (mettere un {{WIP open}} in WP:File mover e lavorare direttamente lì quando avremo delineato un altro paio di aspetti? Per un paio di giorni lavoriamo assieme alla bozza, poi togliamo il template e quella, salvo gli ultimi aggiustamenti da concordare in talk anche alla luce delle prime procedure di assegnazione, diventa la policy) :) Altra cosa che mi sono perso e che avevo già accennato: sarei favorevole a una procedura un po' rinforzata per l'assegnazione, cioè almeno un paio di commenti obbligatori prima di poter assegnare il flag, con un termine buonsensuale di 2-3-4 giorni per esprimerli, dopo i quali l'admin procede comunque. Il senso della cosa è ovviamente differenziare dall'informalissima assegnazione di AV, e implementare più efficacemente il discorso dei criteri anche "soggettivi". --Dry Martini confidati col barista 23:24, 27 mag 2015 (CEST)

Scusate, non voglio rompere le uova nel panino, ma vorrei capire perché si sta andando decisamente verso la creazione di un gruppo ad hoc se i No sono più dei Sì (12 contro 9)? Quelli contrari hanno cambiato idea? Per me è indifferente la scelta, basta che si quagli qualcosa, però non vorrei che poi qualcuno cascasse dal pero. --Umberto NURS (msg) 16:23, 3 giu 2015 (CEST)

[@ Umberto NURS] In realtà sarebbe solo una rinomina di filemover, io per "gruppo ad hoc" ho inteso un gruppo che facesse solo ed esclusivamente questo. L'idea più gettonata e frutto di sintesi direi che sia quello di creare un solo gruppo che non lasci redirect, sposti le immagini e le sottopagine. --Vito (msg) 16:27, 3 giu 2015 (CEST)

Va bene, chiarissimo. --Umberto NURS (msg) 16:39, 3 giu 2015 (CEST)

Concretizziamo

cb La discussione proviene dalla pagina Wikipedia:Bar/Discussioni/Estensione del suppressredirect#Concretizziamo.
– Il cambusiere Fullerene (msg) 23:05, 30 giu 2015 (CEST)

Dopo una pacata settimana di riflessione, il consenso mi parrebbe essersi sviluppato in direzione di:

• dare al gruppo il nome di mover, provvisorio, da usare sino a che non troviamo di meglio
• lavorare sulla bozza di Fullerene in preparazione qui, da sostituire al contenuto di WP:File mover (con salvataggio della precedente crono)

Dry Martini ha proposto (poco sopra) di rivedere i criteri di assegnazione. La sua proposta prevede: «almeno un paio di commenti obbligatori prima di poter assegnare il flag, con un termine buonsensuale di 2-3-4 giorni per esprimerli, dopo i quali l'admin procede comunque».
Dovremmo dunque esprimerci sui requisiti, e a meno di obiezioni al momento non prevedibili, si potrebbe a breve passare alla fase esecutiva -- g · ℵ (msg) 02:36, 3 giu 2015 (CEST)

Ho letto la bozza e mi è venuto un piccolo dubbio: siamo certi di voler lasciare il diritto all'infinito senza invece farlo decadere dopo 6 mesi di inattività/inutilizzo delle funzioni? --НУРшЯGIO^{(attenti all'alce)} 07:51, 3 giu 2015 (CEST)

Io non sarei così certo: preferirei una decadenza automatica, visto che ci sono di mezzo poteri di spostare immagini e far casotto. --Umberto NURS (msg) 16:39, 3 giu 2015 (CEST)

• +1 su Dry -- g · ℵ (msg) 02:36, 3 giu 2015 (CEST)
• +1 anche per me. E per rispondere a Hypergio, sì, secondo me i flag (che non sono un benefit) possono rimanere. Se si reputa che un utente ha le caratteristiche di serietà e competenza per averli, non vedo perché poi dovremmo toglierglieli. La serietà non la si perde con il disudo :-) --Lepido (msg) 08:15, 3 giu 2015 (CEST)

  (fc) Concordo. Capisco la preoccupazione di Hypergio, ma nel caso degli admin la decadenza è legata a questioni tecniche di sicurezza (presenza di utenze amministrative incustodite). Poi forse è stata un po' troppo mitizzata e caricata di altre interpretazioni nella storia wikipediana... --Tino [...] 12:02, 3 giu 2015 (CEST)

• +1 su Dry, anche per me il flag può rimanere in caso di inattività. --Epìdosis 08:35, 3 giu 2015 (CEST)
• +1 su G. Segnalo questa mia modifica, che è più o meno la traduzione operativa di quanto proposto più in alto. Il senso complessivo è che IMO è un po' draconiano pretendere che l'assegnando conosca e abbia avuto occasione di usare tutti e tre gli strumenti (anche perché sarebbe un disincentivo alla richiesta del flag, e questo non aiuterebbe nessuno). Due su tre, specialmente se si aggiunge una conoscenza delle policy (valutata dai commenti "obbligatori" in sede di assegnazione) abbastanza "rassicurante", mi sembra un buon compromesso. [@ Lepido] faccio l'avvocato del diavolo: ricordiamoci che i presupposti in base ai quali si assegna questo nuovo flag sono ben diversi, prima era un flag assegnato sulla base di sola competenza tecnica, adesso stiamo aggiungendo altri requisiti, non è proprio la stessa cosa. Per evitare WP:AVVITAMENTI direi comunque di soprassedere e lasciare il flag a chi ce l'ha già. --Dry Martini confidati col barista 08:54, 3 giu 2015 (CEST)

[× Conflitto di modifiche]Premesso che sono MOLTO interessato a queste funzionalità e che non mi sono mai occupato di spostamento di file (ma di spostamento di pagine sì), le condizioni 2 e 3 mi sembrano siano strettamente legate (se si chiede il suppressredirect è perché si è spostata una pagina, a meno che si faccia il lavoro a metà o si sistemi il lavoro fatto a metà da qualcun altro), troppo per essere separate. Inoltre, per chi non ha mai spostato file, visto che come è stato evidenziato nella discussione, il movesubpages è una funzionalità usata pochissimo (qualcuno ha detto once in a lifetime, una volta nella vita), il volerla introdurre come condizione per ottenere il flag, mi pare un po' una condizione capestro. Io la vedo nell'ottica di un potenziale richiedente di questo flag, e mi sembra una forzatura il fatto di richiedere comunque o lo spostamento dei file (non sono cose di cui mi occupo) o lo spostamento delle sottopagine (non ne ho mai avuto l'occasione a parte quando ho creato un portale). Se si da un'occhiata al mio LOG, questo è pieno di spostamenti con link rossi alla pagina originale, il che vuol dire che è una cosa che so fare (spostando le pagine secondo criteri accettabili, rendendo orfani i redirect e chiedendo la cancellazione in immediata del redirect, a volte non subito dato che non sempre rendere orfane le pagine è un lavoro semplice) ma per la quale non sono titolato a fare in autonomia. Certo, il mio è un caso specifico, ma sono convinto che non è isolato. Chiedo allora, se i criteri così come scritti da Dry Martini fossero approvati, devo dimostrare le mie capacità anche spostando 5 file o andandomi a cercare una pagina con le sottopagine da spostare o un LOG come il mio può, invece, dimostrare che sono capace di poter gestire questo flag? --НУРшЯGIO^{(attenti all'alce)} 09:46, 3 giu 2015 (CEST)

• Bozza buona. Segnalo solo che la frase Tuttavia, se [...] un consenso chiaro IMHO è poco chiara. --Retaggio (msg) 09:34, 3 giu 2015 (CEST)

  @Retaggio per come me lo sono immaginato io sarebbe una clausola di chiusura: se anche l'utente X non ricevesse commenti alla propria richiesta ma ci fossero evidenze robuste a favore dell'assegnazione si potrebbe procedere comunque; "prendere in considerazione" l'assenza di commenti è un modo per rafforzare il ruolo dei commenti e indicare che questi non sono di per sé indispensabili al punto da inficiare l'assegnazione nel caso siano assenti, ma che d'altra parte quest'assenza potrebbe essere un indizio di criticità, e quindi la valutazione dovrebbe essere più attenta e magari esigente (ma ho lasciato una formula - troppo? - vaga per dare spazio al buon senso). Per rispondere ad Hypergio: ho buttato lì dei criteri numerici basati sul fatto che più in alto era stata espressa preoccupazione per non abbandonarli del tutto. Un'alternativa potrebbe essere che il minimo sindacale sia soddisfare uno dei 3 requisiti numerici, con l'intesa che soddisfarne più d'uno possa essere un punto di particolare favore. In fondo c'è sempre l'altro requisito, di conoscere le regole e saperle applicare: a buon senso, se uno rispetta uno solo dei criteri quantitativi posso immaginare che in sede di assegnazione si guardi con particolare attenzione alla sua conoscenza generale delle linee guida, mentre un utente con esperienza sul campo più poliedrica sarà soggetto a uno scrutinio meno puntiglioso sull'altro fronte. Il punto è che, per un flag un po' articolato come questo, diventa importante capire se l'utente "saprebbe" usarlo perché è difficile, farraginoso e troppo restrittivo valutare sterilmente se "sa" usarlo. Qualunque formulazione della regola che tenga conto sia di questo sia di qualche requisito quantitativo minimo (e IMO comunque indispensabile) mi va benissimo, mica arrivo con la verità in tasca :). --Dry Martini confidati col barista 10:36, 3 giu 2015 (CEST)

  Altro "pensierino" mentre penso ad una versione più chiara di quella frase (ho capito il "senso", è solo che IMHO deve essere più chiara): al momento vedo nella bozza che per i mover viene chiesto come requisito minimo di essere autoverificati e ai rollbacker di avere i requisiti per la votazione sugli utenti (500 edit e 60 giorni). Siccome entrambi i flag sono basati conoscenza dei meccanismi wiki e una certa "affidabilità", non sarebbe il caso di unificare questi due requisiti minimi? Io li immaginerei entrambi per entrambe le figure (scusate il gioco di parole...) --Retaggio (msg) 10:46, 3 giu 2015 (CEST)

  Unificare in che senso? --Dry Martini confidati col barista 10:50, 3 giu 2015 (CEST)

  Scusa, ho detto una stupidaggine... non avevo considerato che gli AV devono già avere come requisito minimo il diritto di voto sugli utenti... :-P --Retaggio (msg) 10:55, 3 giu 2015 (CEST)

• La bozza mi sembra in generale buona. Per sburocratizzare dove possibile, valuterei poi la possibilità di avere l'assegnazione su richiesta dell'utente senza ulteriori requisiti per chi, stanti le prime due condizioni, fosse già amministratore/mover su Commons. --Tino [...] 12:02, 3 giu 2015 (CEST)
• Per punti:
  1. Sulla decadenza automatica mi trovo d'accordo con Hypergio seguendo la stessa linea di quanto già fatto per i rollbacker, ma con un tempo più lungo (6 mesi?) visto che i spostamenti sono meno frequenti dei rollback che si trova a fare un patroller.
  2. +1 sull'assegnazione rinforzata da 3 giorni di attesa per dare spazio ai commenti.
  3. Sui criteri tecnici per l'assegnazione credo che la soluzione migliore sia l'ultima proposta da Dry Martini: chiedere l'obbligo di soddisfare almeno uno dei punti, e se ne è soddisfatto solo uno imporre un'approfondita valutazione sulla conoscenza delle linee guida. Inoltre lascerei stare la richiesta di competenze per il move-subpages (mi sembra che il punto 3 sia fin troppo legato al punto 2) mantenendo solo i primi 2 punti.

Fullerene (msg) 03:51, 4 giu 2015 (CEST)

• La voce è stata aggiornata con questa mia modifica ho cercato di recepire i suggerimenti sui requisiti quantitativi. Inoltre, ho riformulato l'incipit perché imo così suona meglio e ho esplicitato un punto importante tra i requisiti, cioè che le richieste di spostamento file o di immediata non devono essere state fatte "coi piedi" in modo da aggravare l'operato di chi si sia trovato a evaderle: il punto, secondo me, è che il mover, una volta flaggato, deve essere indipendente, non ha senso che ci debba essere qualcuno che debba pulire dove è passato qualcun altro. In parte questo principio è già espresso nei motivi di revoca, ditemi voi se è ridondante, se possiamo cercare un'unica locuzione per esprimerlo ed evitare ripetizioni o sei si possono lasciare entrambe le frasi per mettere l'accento sulla cosa :) --Dry Martini confidati col barista 15:11, 5 giu 2015 (CEST)

  +1 sull'aggiornamento. Credo che ora siamo pronti per partire: resta solo da sistemare la questione sulla revoca per inattività per la quale, mi pare di capire, ci sono 3 a favore e 4 contrari all'introduzione. --Fullerene (msg) 16:58, 5 giu 2015 (CEST)

  Mi sembra interessante anche il suggerimento di Tino: dare agli admin di Commons una via agevolata per ottenere il flag può avere un senso. Per me possiamo soprassedere, in quel caso, sui requisiti numerici e concentrarci sulla conoscenza delle linee guida (nel loro caso è importante che conoscano le regole nostrane sul titolo della voce se diverse da quelle di Commons e quelle sulle cancellazioni immediate dei redirect). Non credo sia indispensabile avere già il flag locale di autoverificato... ma in caso di assegnazione credete sia opportuno assegnarglielo d'ufficio? --Dry Martini confidati col barista 08:20, 6 giu 2015 (CEST)

Realisticamente, se un sysop di commons non è nemmeno autoverificato su it:wiki può significare solo una cosa: che non è quasi mai venuto da queste parti, magari semplicemente perché non conosce la lingua. Vogliamo dare il suppressredirect a uno così, che non è in grado di capire se un titolo (scritto in una lingua a lui sconosciuta) è giusto o sbagliato? --Retaggio (msg) 19:15, 6 giu 2015 (CEST)

Concordo con l'osservazione di Retaggio, per questo suggerivo di lasciare i primi due requisiti, l'agevolazione sarebbe rivolta ad admin/mover di Commons che siano già autoverified qui, proprio per evitare simili problemi. --Tino [...] 19:18, 6 giu 2015 (CEST)

sì, soprattutto se in questo momento abbiamo in mente "qualcuno" in particolare, ecco, a quel certo "qualcuno" certo che non gli dobbiamo fare le lastre :-) In ogni caso i tempi del tutto sono complessivamente molto brevi, quindi la scorciatoia in fondo non è un grande sconto, tutto sommato; se invece c'è un buon consenso fra i sysop, credo che questo basti e avanzi, sono tutte cose tecnicissime e le competenze in genere sono comunque già note anche senza... l'esame della patente :-) -- g · ℵ (msg) 02:15, 7 giu 2015 (CEST)

Credo anch'io che, essendo i tempi e i requisiti per l'assegnazione molto ristretti, non ci sia la necessità di introdurre casi specifici di agevolazioni. --Fullerene (msg) 03:30, 8 giu 2015 (CEST)

Finalizzazione

cb La discussione proviene dalla pagina Wikipedia:Bar/Discussioni/Estensione del suppressredirect#Finalizzazione.
– Il cambusiere Fullerene (msg) 23:05, 30 giu 2015 (CEST)

Salvo cause di forza maggiore domani creo due task su phab:

• uno per creare un gruppo "mover" coi permessi suppressredirect, movefile e movesubpages
• uno per rimuovere il gruppo filemover

il secondo dovrà essere eseguito dopo che avrò travasato gli utenti da un gruppo all'altro. Se ho frainteso il consenso segnalatemelo, si può sempre correggere ma... @@.

--Vito (msg) 19:13, 16 giu 2015 (CEST)

in un unico ticket non si può aprire "rinominare il gruppo filemover in mover e aggiornare i permessi" in modo da mantenere gli utenti già flaggati? --valepert 21:56, 16 giu 2015 (CEST)

Conosco i miei polli. O meglio una quota di essi. --Vito (msg) 22:11, 16 giu 2015 (CEST)

L'unico punto nella bozza che resta ancora da sistemare è quello riguardante la revoca del flag per inattività, sul quale mi sembra che non ci sia un chiaro consenso. --Fullerene (msg) 01:34, 17 giu 2015 (CEST)

A questo punto una votazione sulle due ipotesi di decadimento emerse (non decadimento vs decadimento dopo sei mesi di inattività nella funzione) mi pare ci possa stare anche bene. Così che la bozza, sulla quale sembra esserci un accordo di massima, possa essere finalizzata. --НУРшЯGIO^{(attenti all'alce)} 05:12, 18 giu 2015 (CEST)

Appoggio la proposta di Hypergio, magari la votazione farla all'interno di questa discussione in maniera informale. Poi in futuro si deciderà sul nome della funzione (mover non è che sia l'ideale, ma per il momento va bene così). --Fabyrav parlami 22:47, 18 giu 2015 (CEST)

Favorevole alla proposta: a questo punto mi sembra la soluzione migliore. --Fullerene (msg) 16:00, 19 giu 2015 (CEST)

Ho convertito tutti i file mover in mover, insomma Fatto --Vito (msg) 01:20, 26 giu 2015 (CEST)

[← Rientro] Visto che il gruppo file mover non esiste più da 4 giorni, ho sostituito la bozza stilata in Wikipedia:Mover (lasciando WP:File mover come redirect) e ho provveduto a citare il nuovo gruppo in tutte le pagine di servizio che puntavano a Wikipedia:File mover. Tra i vari aggiornamenti (tra cui il Template:Mover e Wikipedia:Mover/Revoche/ModelloRichiesta), ho sistemato tutte le sottopagine riguardanti le richieste di abilitazione e gli archivi per dare modo agli utenti di poter candidarsi, soprattutto perchè gli utenti ex filemover hanno già la possibilità di usufruire delle due funzioni aggiuntive, e non mi sembra corretto che gli altri non possano richiedere di accedervi. Del resto l'unico punto ancora in discussione è la decadenza per inattività, la quale non compromette l'avvio del nuovo gruppo, e in ogni caso ho provveduto a segnalare nella pagina che la questione è ancora da definire nella sezione qui sotto. --Fullerene (msg) 21:11, 30 giu 2015 (CEST)

Segnalo inoltre che ho provveduto a segnalare l'attivazione del nuovo gruppo al resto della comunità[2][3][4]. --Fullerene (msg) 21:26, 30 giu 2015 (CEST)

Ultimo punto

cb La discussione proviene dalla pagina Wikipedia:Bar/Discussioni/Estensione del suppressredirect#Ultimo punto.
– Il cambusiere Fullerene (msg) 00:24, 7 lug 2015 (CEST)

Per completare la bozza sulla quale è stato raccolto il consenso, manca solo da decidere se l'abilitazione deve essere soggetta a decadenza automatica per inattività oppure no. Il possibile termine che è stato ipotizzato durante la discussione è di 6 mesi. --Fullerene (msg) 01:57, 25 giu 2015 (CEST)

• Favorevole alla decadenza dopo 6 mesi di inattività. --Fullerene (msg) 01:57, 25 giu 2015 (CEST)
• Favorevole alla decadenza automatica dopo 6 mesi (al massimo direi 12). --Umberto NURS (msg) 08:38, 25 giu 2015 (CEST)
• Contrario alla decadenza automatica (ma non è una tragedia se facciamo altrimenti). Queste le mie motivazioni: (1) se confrontiamo con i rollbacker notiamo che chiunque faccia patrolling, anche solo mettendosi per un'ora al giorno a guardare le recentchanges, facilmente può fare anche una decina di rollback; verosimilmente dunque, se non usa più lo strumento da sei mesi vuol dire che l'utente o ha abbandonato oppure sta facendo tutt'altro: in pratica la funzione non è più utile. Nel nostro caso invece, realisticamente la frequenza di utilizzo sarebbe molto più bassa: mi aspetto, più o meno, non più di uno o due utilizzi al giorno (considerando anche l'attività dei sysop), quindi il limite dei sei mesi diventa molto più "stretto" e meno giustificabile. (2) Se confrontiamo invece con i sysop, notiamo che in questo caso è richiesta la familiarità con una pluralità di policy, consuetudini e strumenti tecnici, conoscenze che in 6 mesi possono facilmente diventare obsolete oppure essere diciamo "dimenticate". Esistono inoltre delle questioni di sicurezza che consigliano di non lasciare tali che tali funzionalità siano lasciate a "dormire" in un'utenza inattiva. Nel nostro caso invece la conoscenza tecnica richiesta è in pratica una sola e IMHO fa parte di quelle conoscenze "basiche" dello strumento che non mi fa immaginare grandi possibilità di "dimenticanze" o aggiornamenti tecnici. --Retaggio (msg) 10:05, 25 giu 2015 (CEST)

  [↓↑ fuori crono] [@ Retaggio] Preciso che per i rollbacker la decadenza avviene dopo due mesi, e non sei, e quindi i sei mesi per questo flag sarebbero giustificati secondo l'utilizzo delle funzioni più sporadico. --Fullerene (msg) 15:02, 25 giu 2015 (CEST)

  Hai ragione, mio lapsus. Comunque IMHO cambia poco, dato che mi aspetto una frequenza di utilizzo radicalmente diversa. --Retaggio (msg) 15:06, 25 giu 2015 (CEST)

• Contrario come Retaggio. --Buggia 10:25, 25 giu 2015 (CEST)
• Contrario Non sussistono ragioni di sicurezza, e per il resto degli aspetti ha spiegato abbastanza bene Retaggio. --Tino [...] 11:09, 25 giu 2015 (CEST)
• Contrario, concordo con Retaggio. --Epìdosis 14:37, 25 giu 2015 (CEST)
• Contrario pure io, la ratio della decadenza è legata a ragioni di sicurezza, con un po' di buonsenso si potrà rimuovere chi eventualmente non editasse più da un anno o due. --Vito (msg) 14:40, 25 giu 2015 (CEST)
• Favorevole alla decadenza automatica dopo 6 mesi (ma non è una tragedia se facciamo altrimenti) solo perché col tempo si ridurrebbe il numero di utenti da tenere (eventualmente) d'occhio. Non vedo per contro grandi problemi di sicurezza. --НУРшЯGIO^{(attenti all'alce)} 17:12, 25 giu 2015 (CEST)
• Contrario come Retaggio. --Harlock81 (msg) 21:21, 25 giu 2015 (CEST)
• Favorevole alla decadenza automatica ma basta che scatti dopo un'assenza che sia prolungata ed eventualmente "totale" (cioè che non si limiti al mancato utilizzo della funzione). Mi convincono le osservazioni di Retaggio e Vituzzu, ma riguardo al richiamo di quest'ultimo al "buon senso" preferisco che venga stabilito un limite temporale ben definito, dal momento che francamente, da quanto vedo non di rado in un ambito a me caro (le PdC), sembra che il "buon senso" stia diventando vieppiù un illustre sconosciuto. Sanremofilo (msg) 22:31, 25 giu 2015 (CEST)
• Come detto da altri, al massimo la rimozione dopo inattività totale per 12 mesi, giusto per tenere ordinata e pulita la lista degli abilitati. PS: a quelli che si dovrebbero "tener eventualmente d'occhio" manco lo si dà il flag, eh ;)--DoppioM 00:12, 26 giu 2015 (CEST)
• Contrario come Vito e Retaggio --Ask21 (msg) 10:05, 26 giu 2015 (CEST)
• Favorevole alla decadenza automatica dopo 12 mesi di mancato utilizzo delle funzioni aggiuntive, indipendentemente dal fatto che l'utente sia attivo su it.wikipedia o meno. --Gce ★★ 14:46, 26 giu 2015 (CEST)
• Contrario La verifica dei 12 mesi costa più della risoluzione degli eventuali errori. --Nicolabel 14:59, 26 giu 2015 (CEST)

  [@ Nicolabel] basterebbe aprire il registro del mover: generalmente i non amministratori hanno solo gli spostamenti e i caricamenti dei file, quindi è immediato sapere quando è stato effettuato l'ultimo spostamento. Dovrebbe essere un controllo ancora più rapido di quello che viene fatto per i rollbacker, per i quali si deve cercare l'ultimo rollback tra i vari contributi. --Fullerene (msg) 15:51, 26 giu 2015 (CEST)

• Commento: comunque concordo anche per i 12 mesi di totale inattività, che mi sembra che sia una soluzione che vada incontro alle varie opinioni. I contrari lo sono per qualsiasi tipo di decadenza oppure solo per quella dovuta all'inutilizzo della funzione? --Fullerene (msg) 15:51, 26 giu 2015 (CEST)
• Commento: Io sarei tra i contrari perché la penso sostanzialmente come Vito, ma i 12 mesi di totale inattività rientrerebbero nel buonsenso per la rimozione, quindi potrei essere d'accordo anche sulla proposta dei 12 mesi. --Lepido (msg) 17:01, 26 giu 2015 (CEST)
• Commento: Ok anche per i 12 mesi di totale inattività. Un minimo sindacale di pulizia automatica non fa male. --НУРшЯGIO^{(attenti all'alce)} 06:37, 27 giu 2015 (CEST)
• Domanda: Nicolabel mi ha fatto venire un dubbio che riguarda l'automatismo della decadenza. In generale, quando si decade "automaticamente" i flag vengono rimossi automaticamente nel vero senso della parola o c'è qualcuno che deve intervenire "manualmente"? --Umberto NURS (msg) 11:04, 27 giu 2015 (CEST)

  Deve sempre intervenire un utente con le funzioni adatte allo scopo (ad esempio per gli amministratori bisogna chiamare uno steward attraverso l'apposita pagina di Meta), quindi in questo caso andrebbe avvisato un burocrate affinché provveda a rimuovere le funzioni aggiuntive all'utente o agli utenti indicati. --Gce ★★ 11:22, 27 giu 2015 (CEST)

• Favorevole alla decadenza. Spostare cancellando una redirect se errato poi richiede di nuovo linversione, e il guadagno non è molto, e la connettività e la sensibilità relativa cambiano abbastanza velocemente anche se a volte non ci se ne rende conto. Eviterei inoltre l'aleatorietà del "buonsenso della rimozione eventuale"... già mi immaginavo, quando ho letto giorni fa i primi commenti, i "sofismi" su a chi eventualmente va tolto e a chi no dopo 6 mesi o 12 o che altro. Ri-chiedere un flag se serve non è ambiguo, non stabilire quando decade sì. Risparmiamoci almeno questa "sofferenza". Manteniamo almeno il principio che i flag avanzati, sopra l'AV, decadono se non usati, è una cosa abbastanza chiara e peraltro sensata. Ogni funzione tecnica ha un'inevitabile obsolescenza se non viene esercitata. Ci vogliono dieci parole per chiarirlo anche a un neofita, ogni spiegazione del contrario ne richiederebbe molte di più, e secondo me non reggerebbe la prova del tempo.--Alexmar983 (msg) 13:24, 28 giu 2015 (CEST)
• Favorevole alla decadenza. --Gregorovius (Dite pure) 15:57, 29 giu 2015 (CEST)

Lodo decadenza

Facciamo un anno senza edit? --Vito (msg) 21:27, 30 giu 2015 (CEST)

• Favorevole, come già avevo scritto. --Fullerene (msg) 21:29, 30 giu 2015 (CEST)
• Favorevole, ci ho pensato e mi sembra ragionevole. --Epìdosis 21:35, 30 giu 2015 (CEST)
• Favorevole inteso come completa assenza di edit, ovvero abbandono dell'utenza.--mapi 21:38, 30 giu 2015 (CEST)

Ah chiarisco una cosa, comprendiamo pure i log, giusto? [@ Fullerene] [@ Epìdosis] [@ MapiVanPelt] --Vito (msg) 21:38, 30 giu 2015 (CEST)

OK. --Epìdosis 21:40, 30 giu 2015 (CEST)

Sì, ovvio.--mapi 21:40, 30 giu 2015 (CEST)

Certo, anzi a maggior ragione visto che i registri contengono quasi esclusivamente i caricamenti dei file e proprio gli spostamenti :) --Fullerene (msg) 22:12, 30 giu 2015 (CEST)

• Favorevole, soluzione ragionevolissima. --НУРшЯGIO^{(attenti all'alce)} 07:09, 1 lug 2015 (CEST)
• Favorevole, dai, ok...! Ragionevole e di buon senso. --Lepido (msg) 08:26, 1 lug 2015 (CEST)
• Favorevole né edit né log. --Buggia 08:31, 1 lug 2015 (CEST)
• Favorevole mi sembra un buon compromesso. --Horcrux_九十二 15:23, 1 lug 2015 (CEST)
• Favorevole, mi sembra una buona soluzione di compromesso. --Gce ★★ 15:47, 1 lug 2015 (CEST)

Fatto: decadenza per totale inattività aggiunta nella pagina. --Fullerene (msg) 00:29, 7 lug 2015 (CEST)

Lista dei mover

Hello. C'è un motivo particolare per cui non possiamo limitarci a linkare la lista automatica (che permette di vedere quali altri flag ha l'utente) e la pagina dei registri (che permette di vedere quando e da chi sono stati assegnati i flag, oltre che sapere chi è stato mover)? Capisco le informazioni aggregate, ma non è un po' un lavoro extra? Per admin, burocrati e CU la cosa ha un senso perché le rimozioni (e anche le assegnazioni per i CU) avvengono su meta e sono riportate solo nei registri globali (e di conseguenza è molto difficile per l'utente medio tenere traccia delle rimozioni), ma per i mover? --Dry Martini confidati col barista 18:08, 3 ago 2015 (CEST)

Per me si può togliere. --Buggia 18:21, 3 ago 2015 (CEST)

concordo. Io metterei anche in commento (<!-- -->), per ora, la lista degli ex, finché non ce ne sarà qualcuno. -- g · ℵ (msg) 03:58, 4 ago 2015 (CEST)

Fatto --Dry Martini confidati col barista 00:52, 7 ago 2015 (CEST)

Vedo solo ora la discussione: la lista l'avevo scritta io, ma effettivamente è solo un lavoro in più per gli admin. --Fullerene (msg) 02:11, 7 ago 2015 (CEST)

Inversioni?

L'argomento non è stato affrontato (o io me lo sono proprio perso, in tal caso scusate), ma con il suppress-redirect il mover tecnicamente potrebbe fare anche le inversioni di redirect; non vedo alcuna modifica né qui né sui redirect, perciò domando direttamente, sareste per consentirlo o pensate che sia meglio di no? -- g · ℵ (msg) 23:22, 6 ago 2015 (CEST)

L'inversione di redirect è riservata agli admin solo perché è "difficile": le cancellazioni che implica non sono cancellazioni per le quali bisogna rilevare un consenso o conoscere le linee guida, sono solo un espediente tecnico dovuto al fatto che non esiste un modo diretto per "scambiare" due pagine (peraltro si cancella una "pagina fantoccio"...). Favorevole --Dry Martini confidati col barista 00:30, 7 ago 2015 (CEST)

beh, con il suppress non lasci niente da cancellare: sposti B a Temp e B diventa vuota, A a B e A diventa vuota, Temp a A e Temp resta vuota. O mi perdo qualcosa? :-) -- g · ℵ (msg) 00:47, 7 ago 2015 (CEST)

Non ti perdi proprio niente, anzi credo che abbiamo detto la stessa cosa, sotto sotto :) --Dry Martini confidati col barista 00:52, 7 ago 2015 (CEST)

:-D -- g · ℵ (msg) 00:57, 7 ago 2015 (CEST)

Temo che nessuno c'aveva pensato, ma non penso che ci siano problemi, almeno anche secondo me, visto che l'inversione non è riservata agli amministratori per motivi di pericolosità dell'azione.

Direi invece che si possa segnalare questa possibilità sia su Aiuto:Inversione di redirect che su WP:Mover, in particolare per fare in modo che i mover sappiano che possono aiutare gli amministratori a sbrigare le richieste di inversione,. --Fullerene (msg) 03:56, 7 ago 2015 (CEST)

C'era stata una discussione a proposito dell'uso del flag da parte delle utenze bot (che hanno il suppressredirect) per altri scopi come questo. Vedere anche le discussioni richiamate da questa. In sostanza non c'è consenso pregresso per questo tipo di utilizzo. --IndyJr (Tracce nella foresta) 11:18, 7 ago 2015 (CEST)

Nel caso che vi sia consenso allora si potrebbe inserire una citazione anche su WP:Bot.

PS: segnalo al bar generale. --Fullerene (msg) 16:10, 7 ago 2015 (CEST)

[← Rientro] In realtà ci avevo pensato a questa cosa, ma aspettavo passasse un po' di tempo prima di discuterne; sarebbe, comunque, utile creare Wikipedia:Richieste ai mover per permettere ai mover di poter gestire richieste fatte da IP ed utenti non mover (anche eventualmente vagliandole) ed alleggerire, ove possibile, il carico di lavoro degli amministratori. --Gce ★★★ 00:25, 8 ago 2015 (CEST)

[@ Gce] sarebbe un utilizzo un po' inefficiente delle risorse, temo. Così ci sarebbero meno utenze a svolgere lo stesso carico di lavoro, e creeremmo l'ennesima pagina di servizio da gestire (e archiviare), al posto di agevoli categorie autosvuotanti. Per questo tipo di lavoro meglio tenere il sistema dei template, IMO. --Dry Martini confidati col barista 00:43, 8 ago 2015 (CEST)

concordo, lato mover basta la categoria:spostare, lato utente si può evidenziare anche in WP:RA che per gli spostamenti (e le inversioni, se così si deciderà), basta mettere il template (la nota già c'è, ma magari la si rende... fosforescente :-) -- g · ℵ (msg) 02:49, 8 ago 2015 (CEST)

D'accordo quasi su tutto. Inutile però una pagina apposita di richieste ai mover, gli strumenti per evidenziare le richieste di inversione ci sono già.--НУРшЯGIO^{(attenti all'alce)} 22:27, 10 ago 2015 (CEST)

Contrario anch'io ad una pagina per le richieste ai mover, per quanto già scritto. --Fullerene (msg) 18:16, 11 ago 2015 (CEST)

Ho segnalato questa possibilità[5][6][7][8][9][10][11][12][13]. --Fullerene (msg) 04:10, 18 ago 2015 (CEST)

Grazie Fullerene :-) Quindi i mover possono iniziare a fare casino inversioni, giusto? -- g · ℵ (msg) 09:16, 18 ago 2015 (CEST)

Si si :) --Fullerene (msg) 14:46, 18 ago 2015 (CEST)