Discussioni Wikipedia:Mover

cb La discussione proviene dalla pagina Wikipedia:Bar/Discussioni/Spostare i file: e se importassimo il flag "file mover"?.
– Il cambusiere Formica rufa

Inauguriamo 'sta discussione. Partiamo da un punto: imho, se dovessimo fare una gerarchia della dannosità potenziale dei flag, quella del file mover sarebbe superiore a quella dell'autoverificato. Per questo, IMHO, è opportuno introdurre un ulteriore paletto - che poi siano 6 mesi, come ho proposto al bar, o 3 poco importa - perché così abbiamo il tempo di verificare l'uso che l'utente fa del flag da autoverificato.

Sulla candidatura, invece, non vedo motivi per vietare le autocandidature (né per vietare le eterocandidature, come invece facciamo per i rollbacker): IMHO se un utente ha voglia di mettersi a disposizione spostando file e se si ritiene che sia affidabile, va bene sia che si autocandidi sia che venga candidato.

Infine, sul nome mi sono permesso di aggiungere "rinominatore", che (IMHO) non fa effetto Vulvia e rigetta l'anglicismo; bisogna dire che anche chi sposta una pagina è un rinomatore, ma in fondo il rollbacker non è l'unico utente in grado di fare un rollback.

Sull'assegnazione del flag userei il modello autopatrolled: assegnazione da parte di un admin, revoca da parte di un burocrate.

Infine, sui diritti: non vedo altri diritti da concedere a questo gruppo. Piuttosto valuterei la possibilità di attribuire anche questo diritto ai rollbacker, una funzione che per la procedura (a partire dall'assegnazione del flag da parte di un burocrate) viene concessa con un gradino in più di fiducia da parte della comunità.--Formica rufa 18:38, 24 ago 2013 (CEST)

Ps Ho creato questa bozza di template. Ovviamente facciamolo nascere dopo aver dato vita a questa policy (ad esempio al momento ho scritto che lo spostamento dei file è una funzione riservata agli admin, alla fine vedremo cosa scrivere), ma intanto possiamo iniziare a lavorarci--Formica rufa 19:24, 24 ago 2013 (CEST)

Io non sono autoverificato e preferisco restare tale per via dei miei problemi di memoria eidetica e per la disorganicità dei miei salvataggi avendo principalmente molti piccoli momenti frazionati che mi possono incasinare... tuttavia sono un lavorosporchista con elementi di retropatrolling. Per me "muovere" i files sarebbe un tag utile, ed è un'opzione che richiederei con piacere. Quindi spero che sia indipendente dall'autoverifica, tutto qua.--Alexmar983 (msg) 15:28, 25 ago 2013 (CEST)

[× Conflitto di modifiche] Mmm, no, secondo me questo flag può restare un flag aggiuntivo: se un rollbacker vuole anche spostare i file (attività non necessariamente correlata al patrolling in prima linea per cui è pensato in flag di RB) chiede l'assegnazione del flag. Non è un sbagliato accumulare flag, finché non si sovrappongono.

L'autocandidatura mi sembra più che sensata, ma mi sembra un tipo di strumento abbastanza simile al rollback (come profilo): una cosa che serve a chi la chiede, non agli altri. Quindi niente eterocandidature, IMO (ma non faccio harakiri se si decide altrimenti, eh :D ).

E rinominatore di file? un po' lungo, ma è un po' più preciso.

Infine, mi sentirei di presumere un po' di buona fede: il controllo per l'assegnazione dell'autopatrolled è già abbastanza scrupoloso, non credo sia necessario tenere ulteriormente in quarantena l'utente. Sentiamo altri pareri, però. --Dry Martini confidati col barista 15:35, 25 ago 2013 (CEST)

Non reputo l'autoverifica al 100% scrupolosa. Io impiego 2-3 mesi a proprre un utente, lo studio con costanza, ma molte candidature sono un po' buttate là, manca di struttura, alcuni passano al limite ma ottengono il flag prematuramente. Io la vedrei sostituita con un meccanismo un po' più ragionato, non 24-72h ma anche una settimana con una riflessione esaustiva sul'utente, cosa va bene , cosa può migliorare, pareri da altri, coinvolgendolo. Da questa mia idea, ne deriva che non metterei i due flag in automatico uno dietro l'altro. Due controlli, soprattutto se entrambi poco burocraticizzati (passa l'admin e dice si o no), sono sempre meglio di uno. Del resto, si può sempre essere bravi nel 90% delle attività ma mediocri in quel 10% che riguarda il flag specifico. Io ne approfittterei per studiare meglio gli utenti. Per me i flag si possono sempre accumulare, ma non troppo in automatico.--Alexmar983 (msg) 15:49, 25 ago 2013 (CEST)

Chapeau. Io sarei comunque per ridurre al minimo la burocrazia (quindi preferirei la possibilità di richiesta immediata: se non è ancora idoneo o l'autoverificato è stato concesso con riserva si può sempre rifiutare), ma leggendoti mi son fatto possibilista su una quarantena di 1-2-3 mesi :) Ricordiamoci comunque che l'autoverificato è la constatazione che l'utente non compie vandalismi e che de facto arriva sempre molto dopo i limiti minimi (anche un anno buono dalla registrazione): l'unica valutazione che resta da fare, a questo punto, è quella tecnica sulla capacità dell'utente di spostare i file. Se mettiamo in discussione l'affidabilità degli altri flag non finiamo più :) Per inciso, la mia proposta non include di assegnare il file mover in automatico: tenendo separate le procedure e le relative valutazioni (vogliamo mettere un cavillo che impedisca a uno stesso admin di assegnare entrambi i flag allo stesso utente in questo caso? burocratico ma garantista), non mi sembra sbagliato poter fare richiesta subito dopo aver ottenuto il flag di autoverificato. --Dry Martini confidati col barista 16:24, 25 ago 2013 (CEST)

[← Rientro] Spostafile. :P

La parola file è comunque già di per sé un anglicismo, a questo punto non ci vedo nulla di strano a lasciare intatto il nome "file mover", così come non abbiamo chiamato "riportatore indietro" il rollbacker né tantomeno l'abbiamo chiamato "rollbackatore" o "abilitato al rollback".

I diritti assegnabili a questo eventuale gruppo sarebbero due, come per i rollbacker: "autopatrolled" e "movefile". Sul livello di accesso, lo vedo intermedio fra quello di autoverificato e quello di rollbacker, così come è. Ma sinceramente (anche se non penso che questo punto raccoglierebbe tanti consensi) non ci vedrei malissimo il suppressredirect: rinominare un file dovrebbe presupporre sempre automaticamente l'orfanizzazione del vecchio titolo, che se per una voce non sempre è necessario, per un file dovrebbe esserlo sempre. Dunque se uno si vuole divertire a smazzarsi i file da rinominare dovrebbe prima correggere i richiami in entrata (e di solito per un file non sono più di 2-3 richiami) e poi spostare il file, (o viceversa, non fa differenza), operazione che così potrebbe compiere in totale autonomia. Il problema che sorgerebbe è che il suppressredirect si applica anche alle voci, dunque un filemover avrebbe la possibilità di sopprimere anche i redirect durante uno spostamento di una voce (funzione che non è attiva di default durante lo spostamento, ma bisogna prima deselezionare una casella); si dovrebbe dunque rimarcare nella pagina della linea guida del flag che l'uso del suppressredirect in ns0 è assolutamente sconsigliabile (non penso che qui sorgerebbero problemi, così come viene richiesto a un rollbacker di non effettuare rollback se è egli stesso coinvolto nel problema).

Sull'attivazione e rimozione sono d'accordo sul fatto che la seconda debba essere fatta da un burocrate, mentre per la prima va bene l'assegnazione ad opera di tutti gli amministratori (se si dovesse però assegnare anche il suppressredirect vedrei più di buon grado anche l'assegnazione ad opera dei burocrati).

Sulla modalità di candidatura e decadenza, io farei come per i rollbacker: soltanto autocandidature. Verificare se un utente è abbastanza affidabile per l'incarico e ha un minimo di contribuzione recente nell'ambito file è molto facile; la decadenza la fisserei a un termine davvero molto lungo, tipo 6 mesi o anche di più: non è un'operazione delicata come il rollback, a meno che appunto non si assegni il suppressredirect, per cui in quel caso direi 2 mesi anche qui. I flag di movefile e rollbacker sono "cumulabili" e perfettamente compatibili. --Roberto Segnali all'Indiano 19:06, 25 ago 2013 (CEST)

Direi flag aggiuntivo ma senza "suppressredirect": può benissimo mettere un C9, non è una casistica così vasta da affaticare gli admin (che comunque avranno poco meno da fare). Come durata lo vedrei "eterno": è un'operazione di routine, non ci sono linee guida o contesti in evoluzione... come all'autoconvalidato non leviamo il "move" dopo 6 mesi che non sposta una pagina...--DoppioM 23:10, 25 ago 2013 (CEST)

Anche secondo me non sono molti i redirect, anzi sono quasi rari; quoto DoppioM su questo.

(semi-OT) Circa le linee guida, invece, visto che il tpl su cui sta lavorando Formica mi pare che richieda almeno una pagina di aiuto cui indirizzare gli utenti, ho buttato giù una bozza... di tradizione orale :-) -- g · ℵ (msg) 23:45, 25 ago 2013 (CEST)

Sul supress redirect, devo dire che spostare file come invertire redirect o immediate quali C9 e C6 e C8 sono funzioni tipiche da connettivista. Un connettivista attivo intasa gli admin di richieste come queste, oggettivamente molto burocratiche.--Alexmar983 (msg) 10:11, 26 ago 2013 (CEST)

@Roberto: I flag di movefile e rollbacker sono "cumulabili" e perfettamente compatibili Concordo, a patto che non ci siano permessi ripetuti. Il rollbacker include già autopatrolled, quindi se uno detiene entrambi i flag bisogna che il file mover non contenga il permesso autopatrolled. Sul suppressredirect non saprei: sicuramente è un permesso inerente al lavoro sporco per cui questo flag è pensato, ma ha un campo di applicazione molto più vasto, che coincide in tutto e per tutto con un usatissimo criterio di cancellazione immediata. Mi sembra che dovremmo imporre delle restrizioni troppo pesanti (sarebbero più simili a quelle per gli admin temporanei, che possono operare solo in un ambito determinato, come sarebbe per un file mover con il permesso di suppressredirect). IMO possiamo iniziare senza suppressredirect e poi farlo aggiungere in un secondo momento. Riguardo la scadenza del flag: l'operazione è meno pericolosa del rollback, quindi a rigore io ci vedrei bene una scadenza più lunga di quella prevista per i rollbacker. Però condivido le osservazioni di DoppioM, e penso che possiamo permetterci di concedere il flag senza scadenza (salvo abusi e ovviamente comportamenti problematici e blocchi che fanno decadere da autoverificato), soprattutto per ridurre il lavoro ai burocosi (oppure rimozione da parte degli admin, così snelliamo la procedura).

@Alexmar (un po' en passant perché mi hai conflittato :) ): quindi proporresti di avere piuttosto un flag di "lavorosporchista", che possa cancellare le pagine che sposta (siano esse voci, categorie, redirect da invertire, file)? Non male, ma nel caso ci vuole l'attivazione da parte di un burocrate e un consenso abbastanza ampio, perché si parla di cancellazioni. --Dry Martini confidati col barista 10:54, 26 ago 2013 (CEST)

In realtà siamo rimasti per anni con flag parzialmente ridondanti, dove per esempio al gruppo burocrate erano assegnate alcune funzioni già comprese anche nel flag amministratore. Da un punto di vista tecnico non ci sono ostacoli. Ma se si preferisce rinunciare all'autopatrolled incluso, per me va bene uguale, ma sono fermamente contrario ad assegnare questo flag a chi ancora non è autoverificato. Al massimo si possono assegnare entrambi lo stesso giorno, ma poiché non sono ammesse autocandidature al flag di autoverificato, l'autocandidatura al flag di file mover non deve poter diventare un modo per farsi assegnare anche l'altro flag; dunque la richiesta di abilitazione dovrebbe essere aperta soltanto agli autoverificati. --Roberto Segnali all'Indiano 11:03, 26 ago 2013 (CEST)

[← Rientro] Ma infatti la proposta più popolare al momento (o meglio, nessuno vi si è opposto, mi pare) è proprio che i flag restino separati (niente permessi in comune) e che siano cumulabili, ma che il flag di autoverificato sia un prerequisito senza il quale la richiesta viene respinta. Insomma si può essere autoverificato e file mover, si può essere rollbacker e file mover, ma non solo file mover. Probabilmente intendevamo la stessa cosa :) Sull'assegnabilità immediata si sta discutendo, e a me sta anche bene. --Dry Martini confidati col barista 11:43, 26 ago 2013 (CEST)

@Alexmar, sarei anche d'accordo ma non è questa la sede (non mettiamo troppa carne al fuoco): IMHO se lo si abilita deve essere utilizzabile su ogni redirect, non solo per i file o per le pagine di servizio. Tuttavia, in passato, mi pare che la comunità si sia detta contraria a estendere il suppressredirect ai non admin in quanto è una cancellazione a tutti gli effetti (IMHO no ma vabbè). Ne riparleremo tra un po' ;)--DoppioM 12:55, 26 ago 2013 (CEST)

In a nutshell

Dunque, nel guscio di noce c'è un certo accordo su questi punti.

• Il flag si chiamerà file mover
• Il flag contiene soltanto la funzione movefile.
• La modalità di assegnazione avviene dietro sola richiesta dell'interessato, come per i Rollbacker.
• L'utente che ne fa richiesta deve già essere in possesso del flag di Autoverificato.
• La sua attivazione avviene ad opera degli amministratori.
• La richiesta è aperta a eventuali commenti di qualsiasi utente, che possano fornire indicazioni utili alla scelta.
• La revoca avviene ad opera dei burocrati ed è legata solo all'uso scorretto della funzione, non ad altre violazioni di qualsiasi natura.

• Se l'utente perde il flag di Autoverificato, perde in automatico anche questo flag.

• Non è prevista decadenza, la funzione si mantiene fino a quando non è l'utente stesso a chiederne eventuale revoca, oppure per il punto sopra.

Le cose da definire sono invece le seguenti.

• La definizione dei requisiti minimi, oltre all'essere Autoverificato. Ci si sta orientado verso la tendenza dell'utente richiedente a operare nel ns6 (file) e nelle varie categorie del lavoro sporco. Requisiti dunque non quantificabili a peso, un po' come avviene anche per i Rollbacker.

--Roberto Segnali all'Indiano 17:01, 26 ago 2013 (CEST)

Secondo me file mover è la soluzione migliore, anche se sposta file andrebbe bene: è una "capacità" aggiuntiva dell'autoverificato e del rollbacker, che hanno già un nome... Escluderei gli altri requisiti, anche la contribuzione in ns6.

Per la cronaca: negli ultimi 16 giorni sono stati effettuati circa 2000 spostamenti, di cui solo 11 di file.--DoppioM 17:31, 26 ago 2013 (CEST)

Diciamo che la richiesta è aperta a chi abbia già le modifiche verificate in automatico (questa era la proposta iniziale e non mi pare ci siano opposizioni). Per i profani (e per la linea guida che potremmo iniziare a buttar giù): autoverificati e rollbacker. Sempre per la policy, direi di formulare un paio di casi in merito alla decadenza:

1. Abuso o utilizzo errato (anche in buona fede) dello strumento di spostamento dei file: è opportuno proporre la rimozione del flag, salvo che l'abuso non sia anche un vandalismo, un atteggiamento non collaborativo o altra condotta contraria alle linee guida.
2. Vandalismi, comportamento non collaborativo, altri abusi (di utenze multiple, per esempio), altre condotte contrarie alle linee guida: chiedere la rimozione del flag di autoverificato (o di rollbacker, a seconda dei casi), che comporta la rimozione anche di questo flag. Poi per carità in via cautelativa si può anche togliere subito quello più "pericoloso" e aspettare di vedere come evolve la situazione per valutare la rimozione anche dell'autopatrolled.

Questo perché IMO un utente può fare danni ai file senza essere un vandalo: se dimostra, per esempio, superficialità nello spostare, eccesso di zelo, poca perizia nel seguire le procedure, ecc, non ha i requisiti per essere file mover, ma non è un vandalo, quindi può restare autoverificato. Se invece ha un comportamento incompatibile con la verifica automatica delle modifiche perde quel permesso e conseguentemente anche i requisiti per essere file mover, quindi si rimuovono entrambi i flag. Insomma, la priorità qui è non avere casini coi nomi dei file, quindi se c'è anche solo un dubbio sulla competenza dell'utente è meglio rimuovere il flag e poi magari parlarne. E più facile riassegnarlo che sistemare pastrocchi di un utente inesperto. È troppo wiki-nazi o è condivisibile?

Per me file mover o sposta file.

I requisiti? Io resto sulla mia proposta: autoverificato o rollbacker da 0 mesi (ovvero con possibilità di fare richiesta subito dopo l'assegnazione del permesso in questione) e un pedigree di lavoro sui file (preferibilmente uso corretto del {{spostare}}, lavoro al laboratorio grafico, uso delle discussioni dei file). La butto lì: essere file mover o amministratore su altre wiki può agevolare la cosa? IMO sì, in fondo si tratta di uno strumento intuitivo, standard (non dipende dalle estensioni installate localmente), non troppo soggetto a policy locali. Ecco, magari dimostrare di conoscere le indicazioni della nascitura Aiuto:Nome dei file. --Dry Martini confidati col barista 20:57, 26 ago 2013 (CEST)

(fc) Il nascituro ha già qualche giorno di vita al singolare come Aiuto:Nome del file, col vostro aiuto lo svezziamo subito :-) -- g · ℵ (msg) 00:02, 27 ago 2013 (CEST)

Sui requisiti, oltre al fattore tempo sul quale mi sono già espresso (ma mi pare non ci sia consenso, me ne farò una ragione), eviterei di introdurre altro. Sì, giusto un po' di attività in ns6, ma nient'altro: né ns7 (siamo sinceri: quanto spesso viene usato quel ns e che probabilità ci sono di ottenere una risposta?) né laboratorio grafico (che riguarda competenze specifiche che travalicano la capacità di dare il nome giusto a un file). In realtà, io assimilerei questo flag più all'universo Lavoro sporco che all'universo File: se un patroller che vuole espandere i lavori nei quali dà una mano lo chiedesse, non vedo controindicazioni nel darglielo. Intendo dire che, semmai e per quanto possa sembrare strano, vedrei bene fra i requisiti l'attività nel patrolling o comunque nel lavoro sporco.

Sul nome, se le opzioni sono sposta file e file mover opto per la seconda--Formica rufa 21:49, 26 ago 2013 (CEST)

Trovo questa cosa del lavoro sporco uno spunto interessante. E certamente uno che già si adopera in categorizzazioni, risoluzioni di problemi di copyright e disorfanizzazioni sarebbe l'utente adatto ad operare sugli spostamenti dei file. --Roberto Segnali all'Indiano 22:05, 26 ago 2013 (CEST)

Ma un requisituccio dobbiamo metterlo, su... "abbiano esperienza nel lavoro sporco (categorizzazioni, disorfanizzazioni, proposte di spostare i file...)" Perché la caccia al copyviol sarebbe propedeutica allo spostare i file? @Formica rufa: non dimentichiamoci però che dobbiamo valutare se l'utente ha anche un minimo di competenza per usare il flag, quindi dei requisiti specifici ci vogliono :) --Dry Martini confidati col barista 09:35, 27 ago 2013 (CEST)

In realtà anche secondo me la lotta al copyviol non rientra nella casistica (anche se, volendo spaccare il capello in quattro, il nome originario del file può essere utile nella ricerca di immagini scaricate da internet, perché se l'immagine è stata tagliata o modificata, ma salvata con lo stesso nome, googlarne il nome può permettere di trovare la fonte; volendo si potrebbe inserire una raccomandazione del tipo “prima di spostare un file, assicurati che l'immagine non sia stata caricata su Wikipedia in violazione di copyright”, ma insomma non è una questione cruciale), mentre le ricategorizzazioni e i disorfanamenti sì. Il punto, Dry, è in fondo proprio questo: se l'utente:X non è solito caricare file né sa usare Photoshop o Illustrator, ma sa trovare la categoria giusta per una deteminata voce e conosce bene le convenzioni di nomenclatura, è (IMHO) ugualmente idoneo ad avere il flag.

Infine vorrei tornare un attimo sul suppressredirect: se l'obiettivo di questo flag è evitare che solo gli admin si sobbarchino lo spostamento dei file, in fondo il suppressredirect è una buona idea. Se comunque poi dobbiamo passare a cancellare i redirect tanto vale che lo spostamento lo facciamo noi: in fondo per spostare un file ci vogliono due clic e per cancellare un redirect pure, non vedo moltissimo risparmio di tempo (per tacere del rischio di rimanere con decine di redirect errati nel ns6). IMHO basterebbe scrivere a chiare lettere, come accennava Dry Martini più su, che la funzione può essere usata solo nel namespace File e che l'abuso può portare alla revoca del flag e/o al blocco. Lo facciamo già per gli admin temporanei e che io ricordi non ci sono stati abusi clamorosi.--Formica rufa 11:26, 27 ago 2013 (CEST)

imho la caccia al copyviol c'entra solo incidentalmente: magari stai spulciando contributi e ti trovi davanti un file da spostare anche se eri lì per altro. Non guasta che ci siano di queste attitudini, come non guasta però per qualsiasi flag, sicuramente è vero che il controllo googlando il nomefile è necessario e un po' di pratica la richiede, ma appunto mi pare che siamo nella media di quanto ci si attende da utenti mediamente esperti.
Su ciò che dice Formica, però, a proposito del "facciamo noi", io sono partito dalla constatazione che le giacenze sono tante, e sia chiaro che so bene perché sia fisiologico che ci si dedichi poco a spostare i file; l'idea era quindi consentire a quei non admin che non darebbero problemi di poterlo fare anche loro, non solo per avere più forze su questo versante, ma anche perché ci potrebbe essere qualche utente che poi ci si dedica e va a cercarsi ciò che per capitare all'admin, genericamente detto, deve passargli davanti e deve pure farci caso. Non è il clic, è trovarsi foto da spostare, magari dedicandoci delle sessioni. A quel punto, se un admin approfittando del C9 dà anche un'occhiata al volo, almeno a campione, a come funziona l'utente (se sposta correttamente), secondo me non guasta. -- g · ℵ (msg) 12:03, 27 ago 2013 (CEST)

Solo per dire che io non mi riferivo alla "caccia al copyviol", ma alla "risoluzione di problemi di copyright", intendendo con questo le riformulazioni necessarie laddove nelle voci vi sia già un avviso posto da altri. Insomma era in realtà uno degli esempi di lavoro sporco, come lo è tutto il resto. La caccia al copyviol la lascerei ovviamente a chi la vuole fare; sono stato poco chiaro, scusate. Sulla questione dell'uso del suppressredirect solo nel ns6, rivendico la paternità dell'idea. :P :D --Roberto Segnali all'Indiano 12:37, 27 ago 2013 (CEST)

[× Conflitto di modifiche] IMO niente suppressredirect, per ora: la differenza (per una volta :) ) non sta nel numero di clic. Spostare un file è più complesso che applicare un C9, ma comunque per quest'ultimo ci vuole un admin (almeno, il consenso nelle discussioni passate era orientato in tal senso). Quindi ben venga il flag per snellire la coda degli spostamenti, ma facciamo che un admin chiude in bellezza (e magari è anche meglio così, che almeno c'è un controllo sui neo-flaggati). --Dry Martini confidati col barista 12:48, 27 ago 2013 (CEST)

Chi mette uno "spostare" si ferma lì. Chi sposta una pagina/file ne controlla le occorrenze, sistema i redirect, corregge i wikilink e mette un C9. Si smazza il 90% del lavoro ;)

Per me il suppressredirect non è un pericolo, perché comunque non può servire a far sparire pagine, però se lo si concede lo si dia usabile anche nel normale lavoro sporco. Non ha senso avere un "suppressredirect" utilizzabile nello 0.5 % degli spostamenti... sarebbe decisamente frustrante! :D

Proprio per la bassissima frequenza di utilizzo, inviterei a non guardarlo come uno scarico di lavoro per gli admin, bensì una possibilità in più per l'utente di portare a termine il lavoro sporco in autonomia.--DoppioM 16:08, 27 ago 2013 (CEST)

Concordo con i punti di accordo espressi da Roberto Mura in apertura di questa sezione. Riguardo al suppressredirect condivido il pensiero di DoppioM. Se vogliamo solo creare il flag di file mover, allora tale funzione è, passatemi il termine, sprecata: pochi spostamenti, utilizzo solo in ns6, tendenzialmente inutile quando si tratta di grandi spostamenti, dal momento che cancellando immediatamente il redirect lasceremmo per un bel po' di tempo immagini assenti, molto più visibili dei wikilink (personalmente in questi casi io il redirect lo cancello alla fine per C9, in modo da lasciare fruibile l'Enciclopedia per più tempo). Se invece vogliamo creare un flag utile per il lavoro sporco, allora tale diritto è importante, in quanto garantirebbe un'azione in tutto il resto dell'Enciclopedia, laddove gli spostamenti sono molto più cospicui, e permetterebbe anche l'esecuzione delle inversioni di redirect. Per i requisiti invece per me è sufficiente un minimo di attività in ns6 che dimostri la capacità di attenersi a queste regole che sbozzeremo: qualcosa come 10-20 spostamenti richiesti e poi effettuati dai sysop o da file mover già attivi possono essere più che sufficienti. --Aplasia 16:41, 27 ago 2013 (CEST)

[← Rientro] Ho aggiornato i punti in base a quanto emerso finora. --Roberto Segnali all'Indiano 13:12, 28 ago 2013 (CEST)

io metterei un certo numero di edit nel ns File, non proprio come limite ("hai fatto fatto solo 99 modifiche nel ns6, non sei adatto!"), ma per poter capire se l'utente ha dimestichezza con il template {{Informazioni file}}, conosce un minimo le licenze dei file (almeno evita di spostare 80 screenshot di Google Earth come PD-Utente) ed è in grado di mandare in C18 e C20 i media che meritano di essere segati. --valepert 17:15, 28 ago 2013 (CEST)

Sono favorevole ai punti elencati in cima alla sezione di questa discussione, contrario a dare il suppressredirect proprio perché quando si sposta un file la cosa migliore sarebbe, spostare il file lasciando il redirect, così nelle voci non c'è nessun problema, si correggono i link al redirect e poi si cancella il redirect in C9, se si usa il suppressredirect quando si sposta il file, nelle voci in cui è inserito al posto della foto compare un wikilink rosso e la cosa non è bella. Poi a furia di proporre nuovi flag di aiuto avete visto dove va a finire la discussione, si inizia proponendo il suppressredirect, poi si dice perché non abilitarlo anche per tutti i namespace? A questo punto io potrei dire che magari è utile anche la cancellazione in C9 delle pagine a questo punto diamo direttamente il flag di admin che facciamo prima.--dega180 (msg) 17:37, 28 ago 2013 (CEST)

Favorevole al solo "file mover", Contrario all'aggiunta del "suppressredirect" per i motivi esposti da dega180.--MidBi 14:49, 29 ago 2013 (CEST)

Una buona conoscenza delle licenze è un requisito interessante. Certamente non si può quantificare, ma se non altro è possibile indicarlo come raccomandazione importante nella linea guida per richiedere la funzione di File mover.

Il suppressredrect è ormai fuori discussione, suggerirei di concentrarci il più possibile sulla questione dei requisiti, che di fatto sembra essere l'unico punto in attesa di definizione. ;) --Roberto Segnali all'Indiano 14:54, 29 ago 2013 (CEST)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Per me i requisiti dovrebbero essere

1. utente affidabile, quindi autoverificato e con un minimo di esperienza (ovvio, mi pare siamo tutti d'accordo);
2. attivo nel lavoro sporco e dunque già pratico nel fare lavori sistematici di correzione errori, sistemazioni ecc... (si guarda la crono come per i rollbacker);
3. dato che si lavora nel namespace dei file sarebbe utile una buona conoscenza della questione del copyright (questa è una cosa che possiamo scrivere lo stesso anche se nella pratica è molto difficile da verificare, del resto, anche per gli amministratori si richiede una buona conoscenza della policy ma non abbiamo mai fatto un compito a crocette per verificare se la conoscono veramente);
4. se proprio vogliamo, possiamo inserire, come è stato già proposto, almeno n richieste di spostamento andate a buon fine, magari sbaglio, ma non risulta un po' difficile vedere quante richieste di spostamento file andate a buon fine ha fatto un utente?

--dega180 (msg) 20:02, 29 ago 2013 (CEST)

vedere le richieste non è impossibile per gli admin, dovrebbero trovarle fra gli edit cancellati in ns:file (se il nome precedente non è rimasto a redirect), ed è peraltro un controllo auspicabile prima del flag (metti che gli hanno segato copyviol o altro) -- g · ℵ (msg) 23:46, 29 ago 2013 (CEST)

È un lavoro di scavo che possiamo addossarci quello di verificare il numero di richieste di spostamento. Data la vasta gamma di requisiti, eviterei di dare soglie numeriche. Favorevole a tutti i requisiti proposti da dega180 (sempre da riformulare la questione degli autoverificati per includere anche i rollbacker, IMO, ma non ho capito se a voi va bene o no che i rollbacker abbiano il flag :) ). --Dry Martini confidati col barista 10:21, 30 ago 2013 (CEST)

Anche a me vanno bene, ma una soglia numerica di una decina di spostamenti richiesti ed eseguiti la terrei, giusto per evitare richieste premature e avere una base su cui effettuare una valutazione di merito (un po' come abbiamo 500 modifiche per il flag di autoverificato). Per la questione rollbacker secondo me si tratta di un'inutile ridondanza, dal momento che questi utenti sono autoverificati di diritto avendo l'autopatrol, come da Speciale:ElencoPermessiGruppi; quindi se gli serve questo diritto in più, sono liberi di farne richiesta. --Aplasia 10:32, 30 ago 2013 (CEST)

È solo una questione di chiarezza: se scriviamo che possono fare richiesta gli autoverificati la cosa si presta a interpretazioni, se specifichiamo è tutto più facile e user-friendly :) --Dry Martini confidati col barista 10:35, 30 ago 2013 (CEST)

Non mi oppongo! Il fatto è che ho sempre visto il rollbacker come un utente autoverificato con funzione rollback aggiuntiva e quindi vedrei il file mover come un utente autoverificato con funzione movefile aggiuntiva. A questo proposito, il flag sarà con funzioni autopatrol e movefile e sostituirà il flag autoverificato (similarmente a come avviene per i rollbacker) oppure sarà fornito in associazione, a questo punto solo con movefile per evitare la ridondanza dell'autopatrol. --Aplasia 10:53, 30 ago 2013 (CEST)

Mi pare si sia concordato che è meglio tenere staccati i permessi di autopatrolled e move file (cioè si aggiunge il flag senza rimuovere quello di livello inferiore) perché altrimenti se il flag file mover li contenesse entrambi e un rollbacker volesse accedere anche a questa funzione ci sarebbe una ridondanza di permessi (anche il rollback include il permesso autopatrolled). Per quanto non credo faccia danni è comunque meglio evitare (anche per la questione che ho proposto più in alto della rimozione del flag... era un'argomentazione un po' complicata, per cui non la ripropongo, ma è importante in questo contesto). --Dry Martini confidati col barista 11:25, 30 ago 2013 (CEST)

A questo punto sarebbe più corretto affidare il rollback esclusivamente agli autopatrolled (tanto noi chiediamo che l'utente sia affidabile) e dunque avere così tre flag distinti: autopatrolled, rollback e file mover, ma questa forse è un altra storia. Non vedo il motivo per cui i rollbacker non dovrebbero poter accedere allo strumento dunque sono favorevole a qualsiasi "scappatoia" tecnica che permetta anche a loro di poter ottenere il flag.--dega180 (msg) 12:57, 30 ago 2013 (CEST)

È senza dubbio condivisibile (ma... il rollback agli autopatrolled? non capisco quale è il flag e quale è il permesso :) ), ma credo che al momento della creazione del flag rollbacker si sia pensato che era uno strumento così delicato che qualsiasi abuso dovesse essere considerato vandalismo (e a riguardo sono d'accordo) e quindi portare alla rimozione di tutti i permessi. Per il file mover c'è più flessibilità sulla rimozione, come abbiamo visto. In ogni caso, la proposta di Dega (poiché comporterebbe solo una modifica dei permessi attribuiti ai rollbacker) può essere discussa a parte senza influire con quest'altro flag. --Dry Martini confidati col barista 14:23, 30 ago 2013 (CEST)

Al momento della creazione del flag Rollbacker, il flag Autoverificato non esisteva ancora. Volendo si può fare richiesta per rimuovere la funzione autopatrol al flag di Rollbacker e assegnare ai detentori anche il flag Autoverificato, così si risolve il problema definitivamente. --Roberto Segnali all'Indiano 21:07, 30 ago 2013 (CEST)

Quagliamo?

Allora, ricapitolando:

1. Nome del flag: File mover
2. Il flag avrà come unico permesso movevile
   1. Niente autopatrolled per permettere anche ai rollbacker di ottenere il flag
   2. Non c'è consenso diffuso sull'assegnazione del suppressredirect
3. Assegnazione solo su richiesta dell'interessato, da parte di un amministratore
   1. Rimozione da parte di un burocrate
   2. La richiesta di assegnazione può essere commentata da altri utenti che possono fornire agli amministratori elementi utili alla valutazione, in modo del tutto analogo ad autoverificati e rollbacker
4. Requisiti per l'assegnazione:
   1. Avere già il permesso di autopatrolled (includendo quindi i flag utenti autoverificati e rollbacker)
   2. Avere esperienza nel lavoro sporco.
      • Resta da quantificare (e da decidere se quantificarlo) un numero minimo di richieste di spostamento di file
5. La rimozione del flag di file mover avviene in caso di utilizzo errato (anche in buona fede) dello strumento di spostamento dei file
   1. Comportamenti problematici, vandalici, fuori dalle linee guida (compreso l'abuso in mala fede dello spostamento dei file) portano ala rimozione del flag di autoverificato o rollbacker e quindi alla perdita dei requisiti per il flag di file mover, che va rimosso a sua volta
      • Non mi pare ci fosse un consenso lampante a riguardo, ma mi sembra una considerazione di buon senso abbastanza condivisibile. Possiamo ancora discuterne
   2. Il flag non ha scadenza né è soggetto a riconferma, data la bassa pericolosità (a differenza quindi del rollback)

Se non ci sono obiezioni possiamo iniziare a scrivere la linea guida, poi si può sempre limare... --Dry Martini confidati col barista 13:37, 30 ago 2013 (CEST)

Io sono favorevole a stendere una linea guida prendendo questi punti come spunto però il fatto che il file mover venga tolto anche con un utilizzo errato in buona fede deve voler dire che se un utente è troppo pasticcione perde il flag e non che se fa un errore (errare humanum est) perde i diritti di file mover. La questione della conoscenza del copyright mi sembrava una buona idea. Io introdurrei un numero minimo di richieste di spostamento andate in porto ma, dato che di solito se ne fanno poche, il numero minimo non deve essere superiore a 10, per me anche 6-7 può andar bene.--dega180 (msg) 14:07, 30 ago 2013 (CEST)

Concordo, ma comunque dovrebbe essere una rimozione abbastanza "facile": errare è umano e qualche errore si tollera, ma la priorità va a costruire un'enciclopedia funzionante (quindi non esitiamo a chiedere il deflag). D'accordo per 6 richieste valide e recenti come requisito numerico. --Dry Martini confidati col barista 14:30, 30 ago 2013 (CEST)

Sul punto 5.1 concordo sul buonsenso, considerando che la rimozione del flag andrà comunque discussa come facciamo per quella di autoverificato e di rollbacker: del resto errare humanum est, perseverare autem diabolicum. Sul numero di spostamenti sarei sui dieci, giacché sono convinto che una volta disponibile il permesso, in questa categoria di file da rinominare se ne troveranno assai. Siamo d'accordo nell'assegnazione automatica ai sysop italofoni di Commons, qualora siano attivi su it.wiki e non siano sysop pure qui? (al momento si tratta di cinque utenti, di cui due sono già sysop qui) --Aplasia 14:50, 30 ago 2013 (CEST)

Ragazzi, io direi che stiamo esagerando un pelino :D

Gl spostamenti di file sono poco frequenti (0.5% del totale), non sono poi così pericolosi visto che sono, alla fine, quasi semplici spostamenti. Se da un lato non abbiamo requisito alcuno per spostare le pagine, non chiediamo troppo per spostare i file. 6/10 richieste sono IMHO tante (non credo di averne spostati molti da admin), e la conoscenza delle licenze non vedo come coinvolga il file mover più di altri utenti attivi nel lavoro sporco: i file li rinomina e basta...--DoppioM 17:23, 30 ago 2013 (CEST)

[↓↑ fuori crono]Se ti metti a spostare un file guaderai prima se il file che stai spostando non viola il copyright no?--dega180 (msg) 17:49, 30 ago 2013 (CEST)

Alla fine ci sono stati dieci spostamenti negli ultimi quattro giorni, così pochi non sono (2% degli spostamenti). Se poi dieci sono troppi possiamo convergere anche su cinque spostamenti, ma almeno qualcuno per sapere se l'utente sa titolare a mio avviso ci vorrebbe. Del resto anche per lo spostamento nel resto dell'Enciclopedia si era provato a dare un limite basato sull'affidabilità. --Aplasia 17:47, 30 ago 2013 (CEST)

IMO bene per 5 richieste andate a buon fine. --Dry Martini confidati col barista 18:28, 30 ago 2013 (CEST)

Quando sposto una voce controllo che non sia in copyviol? Non è così scontato, ovviamente, per una voce, ma che la risposta sia "sì" o "no", non è un prerequisito per essere autorizzato a farlo. La differenza tra "rinominare un file" e "rinominare una voce" non è così ampia e IMHO non dovrebbe essere ampia nemmeno la differenza per poterlo fare. (Peraltro, anche se spostassi una img in copyviol, non creo alcun danno ultieriore: sono solo un pirla).

Sapere le licenze dei testi o le convenzioni di nomenclatura non è un requisito per il tastino "Sposta", e non vedo perché dovrebbe esserlo per farlo sui file. Che poi sia giusto o sbagliato, o che si voglia limitare il move è un altro discorso. Mi va quindi bene qualsiasi proposta, visto che oltrepassa i miei standard minimi :D--DoppioM 20:07, 30 ago 2013 (CEST)

l'unica differenza dello spostare una img in c/v, come era stato anche richiamato da qualcuno, è che per le verifiche può certamente aiutare sapere il nomefile precedente, ma questo comunque rimane nella crono del nuovo nome (esempio), quindi il controllo copyviol non ne soffre anche se viene effettuato dopo lo spostamento. Ad esempio, proprio con un controllo per nomefile ripescato da crono, adesso quello stesso che ho linkato (tranquilli, per un pelo è PD-Italy) sappiamo da dove viene anche se era stato spostato :-) Quindi la conoscenza delle questioni di copyviol non ha un grande effetto, farebbe effetto solo spostando il c/v palese. -- g · ℵ (msg) 20:48, 30 ago 2013 (CEST)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Ok, dato che il consenso non c'è la buona conoscenza del copyright non sarà un requisito necessario.--dega180 (msg) 21:35, 30 ago 2013 (CEST)

non sono né pro né contro, quindi non volevo disturbare un eventuale consenso. Volevo solo precisare che non ha influenza pratica su queste operazioni, e con l'esempio portato concludevo che non accorgersi di un copyviol durante lo spostamento non pregiudica l'attività di lotta al copyviol. In linea generale, una buona conoscenza è comunque auspicabile in tutti gli utenti che hanno un flag dal terzo in su, ma giusto perché la si richiede a tutti e non sarebbe carino dire altrimenti :-) -- g · ℵ (msg) 22:42, 30 ago 2013 (CEST)

Ho creato Wikipedia:File mover con i concetti emersi da questa discussione. Quanto ai criteri, sono rimasto sul generico. L'unico requisito numerico è quello delle 5 richieste di spostamento (ma sul numero possiamo discutere). Proporrei di continuare qui la discussione per non perdere pezzi. Al massimo quando variamo la linea guida archiviamo questa discussione come sottopagina di Discussioni Wikipedia:File mover.--Dry Martini confidati col barista 23:47, 30 ago 2013 (CEST)

ok per me su tutto. Quando sbozziamo, proviamo a sbozzare anche Aiuto:Nome del file (se pensate vada bene) -- g · ℵ (msg) 01:01, 31 ago 2013 (CEST)

In realtà la cosa ideale era scrivere la linea guida in Utente:Dry Martini/Spostatore di file e poi spostare in blocco tutto. Comunque ho spostato questa pagina e corretto i link in entrata, dovrebbe funzionare tutto. ;) --Roberto Segnali all'Indiano 09:11, 31 ago 2013 (CEST)

Vero, ma volevo lasciare gli appunti della sandbox fuori dalla crono della linea guida, è più ordinato :) Ho fatto un guazzabuglio fin dall'inizio, lo riconosco, ma almeno abbiamo avuto tempo, spazio e materiale a sufficienza per mettere in chiaro le cose. --Dry Martini confidati col barista 09:43, 31 ago 2013 (CEST)

In assenza di opposizioni, domani segnalo al bar per raccogliere il consenso all'attivazione. C'è ancora tempo per discutere la soglia delle 5 richieste andate a buon fine, unico punto ancora non del tutto chiarito, mi pare. --Dry Martini confidati col barista 13:00, 1 set 2013 (CEST)

Scusate se mi intrometto ora ma non ho avuto molto tempo per partecipare alla discussione sulla bozza: l'unico punto sul quale mi sento un po' dubbioso è l'assegnazione da parte di un amministratore. Perché non fare come i rollbacker e lasciare tutto il lavoro ai burocrati? Non penso ci sarà un numero oneroso di richieste ed il flag mi pare in un certo senso più delicato di quello di rollbacker.--Snow Blizzard 11:32, 7 set 2013 (CEST)

IMO il permesso move files (e più o meno questa è stata l'impressione emersa nel corso della discussione) è meno pericoloso del permesso rollback. Per come la vedo io il rollback è uno strumento che comporta una serie potenzialmente massiccia di modifiche e può facilmente essere usato in edit war, mentre la possibilità di spostare i file può più che altro portare a disguidi (link rossi, per capirci). Poi possiamo per ora attivare il flag così e se in seguito c'è consenso per l'assegnazione da parte dei burocrati facciamo un'altra richiesta ai developer (ma IMO una restrizione così sarebbe più che altro un avvitamento burocratico). --Dry Martini confidati col barista 20:40, 7 set 2013 (CEST)

Scatto finale: consenso esplicito da linkare ai developer

È più una formalità (dovuta anche al fatto che è la prima richiesta di cui mi interesso di persona, per cui preferisco far le cose per bene e pian pianino), ma vi chiederei di esprimere il vostro consenso alla creazione del gruppo utente File mover, da assegnare nelle modalità previste da questa bozza (che, contestualmente all'attivazione del flag, verrà resa operativa). --Dry Martini confidati col barista 19:09, 6 set 2013 (CEST)

• +1 --Roberto Segnali all'Indiano 19:24, 6 set 2013 (CEST)
• Favorevole (ricordiamoci di sbozzare anche Aiuto:Nome del file) Aplasia 19:42, 6 set 2013 (CEST)
• Favorevole--dega180 (msg) 20:52, 6 set 2013 (CEST)
• Favorevole—GJo ↜↝ Parlami 23:20, 6 set 2013 (CEST)
• Favorevole -- g · ℵ (msg) 00:09, 7 set 2013 (CEST) Visto che lo proponevo, se qualcuno pensa sia improprio che mi aggiunga, cancelli pure liberamente :-)
• Favorevole --Epìdosis 09:02, 7 set 2013 (CEST)
• Favorevole--DoppioM 11:23, 7 set 2013 (CEST)
• Favorevole --Snow Blizzard 11:28, 7 set 2013 (CEST)
• Favorevole --Pigr8 ^{La Buca della Memoria} 13:05, 7 set 2013 (CEST)
• Favorevole --LikeLifer (msg) 12:51, 8 set 2013 (CEST)