Wikipedia:Bar/Discussioni/Proposte di modifiche per alcuni template usati massicciamente nelle voci

Scrivo al Bar in quanto le proposte che sto per fare avrà effetto su tutta l'enciclopedia. Esse sono:

1. Spostare il Template:S al nome Template:Abbozzo, in quanto la parola stub non esiste in italiano e non è usata al di fuori dei redattori di questa enciclopedia (anche nel template si usa, infatti, il termine abbozzo); lo spostamento al nuovo nome favorirà chi userà il Visual Editor, dato che Abbozzo è più facilmente rintracciabile di S. Ciò comporterà che si dovrà richiedere l'intervento di un bot per rendere orfano il vecchio titolo per poterlo poi cancellare quando non sarà più usato.
2. Aggiungere il campo mese anno al su citato S ed al Template:CN, parametro che permetterebbe di facilitare lo svolgimento del lavoro sporco e dei Festival della Qualità (è stato proposto un Festival per diminuire il numero delle voci considerate come abbozzi e se non si suddividono le voci da esaminare per data di inserimento del template si rischia di doverlo spezzare progetto per progetto o dover scegliere in modo arbitrario le voci da trattare).
3. Aggiungere altri parametri arg (3, 4 e 5 almeno) al Template:Cancellazione, in modo da diminuire il numero di template di avviso apposti nelle discussioni di progetto e poter segnalare voci afferenti a più di 2 ambiti in modo più facile.

Partecipate numerosi. --Gce (Il Vile Censore Mascarato 2013) 19:14, 29 set 2013 (CEST)

Io sono d'accordo.--Toadino2日本 貴方はキノコのお茶が好きですか。disc 20:47, 29 set 2013 (CEST)

non esiste il Progetto:Coordinamento/Template? sono state discusse lì queste tre proposte? in particolare quella del CN mi sembra complicare la sintassi di un template pensato per essere molto semplice da utilizzare. --valepert 20:51, 29 set 2013 (CEST)

Mi sfugge l'utilità *pratica* di sostituire una quantità enorme di occorrenze del tmp S con "abbozzo". Fra l'altro credo sia semplice dividere gli stub per area tematica visto che è un campo già presente e valorizzato. --Vito (msg) 20:54, 29 set 2013 (CEST)

No, valepert, ho preferito discutere direttamente in Bar, visto che si tratta di modifiche importanti che coinvolgeranno tutta l'enciclopedia e volevo la massima partecipazione possibile. Quella che chiami complicazione a mio parere non lo è affatto dato che il template diverrebbe {{cn|frase|mese anno}}, che ha lo stesso numero di parametri del Template:Chiarire, e permetterebbe di evitare di avere frasi senza fonti per anni; questa innovazione sarebbe molto utile anche per una proposta di Festival della Qualità che ho lanciato qualche giorno fa, dato che permetterebbe di catalogare le frasi senza fonte per anno di inserimento, non lasciando all'arbitrio di chi organizza il festival la scelta delle voci su cui intervenire.

La proposta sull'S non è, Vituzzu, pratica, ma linguistica: se Wikipedia non è una fonte primaria non dovrebbe esserlo nemmeno per quanto riguarda il linguaggio usato per gli avvisi di servizio, e quindi gli abbozzi vanno chiamati con questo nome anche nel template; inoltre, ho già descritto che la mia proposta aiuterebbe chi vuole usarlo con il Visual Editor e non è molto pratico dei template di servizio. Non voglio certo rimuovere la catalogazione degli abbozzi per area tematica, ma aggiungervi la categorizzazione temporale può aiutare ad evitare di sedimentare abbozzi per anni ed anni, potendo svolgere dei Festival della Qualità mirati all'espansione degli abbozzi, con la stessa struttura con cui attualmente si sta creando il Festival delle Fonti che si terrà nel 2014. --Gce (Il Vile Censore Mascarato 2013) 21:59, 29 set 2013 (CEST)

ma sì, discutiamo al Bar di modifiche importanti, così da aumentare la possibilità di smarrire tra gli archivi il raggiungimento del consenso e, se possibile, rischiare di perdere gli utili pareri degli utenti interessanti all'argomento che hanno fatto l'errore di inserire negli OS la relativa pagina di discussione del Progetto Coordinamento. --valepert 22:08, 29 set 2013 (CEST)

@gce: senza acrimonia alcuna (sul serio) ma del "valore linguistico" della cosa non me ne può fregare di meno, i nostri contenuti non sono fonti primarie, il lavoro dietro le quinte non deve subire simili preoccupazioni, altrimenti dovremmo sostituire qualche mezzo milione di occorrenze di "enciclopedico". --Vito (msg) 22:14, 29 set 2013 (CEST)

Progetto avvisato, valepert, quindi non si perde nulla. Vituzzu, appunto perché i contenuti non sono fonte primaria ho fatto la proposta; in ogni caso, è un tuo rispettabile punto di vista, e spero intervengano altri utenti per comprendere verso dove vira il consenso della comunità. --Gce (Il Vile Censore Mascarato 2013) 22:24, 29 set 2013 (CEST)

La 1 proprio no... Anni fa si è deciso di usare singole lettere per gli avvisi principali, cosa comoda e ormai radicata, e una sola lettera è una convenzione che c'entra comunque poco con l'italiano. Al massimo potrei capire rinominare la categoria:Stub.

Sulle altre niente in contrario--Bultro (m) 22:31, 29 set 2013 (CEST)

(conflittato)Scrivere "S" invece di "stub" o "abbozzo" è molto comodo, quindi lascerei le cose come stanno. Per le altre 2 proposte, quella del cn mi sembra un po' strana (però ha un senso), mentre sul template cancellazione non mi esprimo perché non sono solito usarlo spesso quindi non so quante volte capita di trovare con voci attinenti a più di due progetti attinenti alla voce. In generale, spero che non ci lasciamo trasportare troppo dalle esigenze del Visual Editor, perché gli utenti più attivi penso che resteranno fedeli al vecchio editor per ancora molti anni. --Daniele Pugliesi (msg) 22:33, 29 set 2013 (CEST)

D'accordo con la datazione di {{S}}, per quanto riguarda gli argomenti nel {{Cancellazione}} credo che 2 siano quasi sempre sufficienti, poi se proprio vogliamo aumentiamoli a 3, ma a questo punto si potrebbe fare lo stesso con gli argomenti in {{S}}, tanto più che quel template ha una sintassi semplicissima. Il resto non mi sembra così utile/opportuno. Sanremofilo (msg) 22:40, 29 set 2013 (CEST)

Aggiungo che preferirei che certe proposte vengano fatte ognuna in uno spazio separato. In generale, quando si fanno 3 o più proposte tutte insieme aumentano infatti le possibilità che nessuna passi, mentre se si fanno separatamente è possibile che una tra esse venga accolta. --Daniele Pugliesi (msg) 22:41, 29 set 2013 (CEST)

[× Conflitto di modifiche] Sul template S la penso decisamente come Vito. Perché allora non spostiamo anche {{P}} a template:Non neutrale ("P" è l'abbreviazione di "point of view", no?) e tutti i template nel namespace "Sagoma:"?. Addirittura la cancellazione, poi... Il template per gli abbozzi deve necessariamente avere una sola lettera, come tutti i più importanti template di avviso di questo genere, poiché ne facilita l'inserimento; e "S" la lettra più adatta dopo "A", dato che "stub" non è, banalmente, un termine "non italiano", bensì è ormai entrato a far parte del gergo wikipediano. Sul {{cn}} non mi esprimo, mentre le modifiche al template Cancellazione non mi sembrano così importanti da essere incluse in questo topic (sry for english) argomento. --Horcrux⁹² 22:42, 29 set 2013 (CEST)

Mi accorgo di avere detto una sorta di contraddizione a proposito di {{S}}, cioè che quel template ha una sintassi semplicissima, ma se si aggiunge la data non sarà più così... Sanremofilo (msg) 22:51, 29 set 2013 (CEST)

L'idea di Bultro del rinominare la Categoria:Stub in Categoria:Abbozzi mi trova Favorevole, la appoggio ed in futuro potrei chiederla nella discussione della stessa, se non dovesse essere fatta tramite questa discussione.

Daniele Pugliesi, in realtà l'idea sul {{cn}} l'ho avuta perché la applicano su en.wiki e mi è sembrata utile; comunque non è detto che facendo 3 proposte assieme non ne passi nessuna, a me sembra che vi sia consenso sull'applicare la seconda.

Sanremofilo, non mi è mai capitato di dover mettere 3 argomenti per un abbozzo, ma nel proporre per la cancellazione la voce su un doppiatore sono arrivato tranquillamente a 4 argomenti (biografie, animazione, cinema e televisione), per questo ho proposto argomenti aggiuntivi solo per questo e non per quello sugli abbozzi (che poi, a differenza degli altri template, l'{{S}} accetta molti più parametri, come attore italiano o politico messicano, al posto di cinema ed Italia per il primo esempio e politica e Messico per il secondo, quindi lì il terzo argomento non serve molto). --Gce (Il Vile Censore Mascarato 2013) 23:10, 29 set 2013 (CEST)

Un altro argomento a cancellazione (anche se è raro) si può aggiungere, solo che lo fare in lua per non appesantire il codice. --Vito (msg) 23:16, 29 set 2013 (CEST)

Non penso che il codice sarebbe così appesantito da un arg3... Lua sarebbe? --Gce (Il Vile Censore Mascarato 2013) 23:21, 29 set 2013 (CEST)

I doppiatori sono un caso particolare, anche se è raro che un doppiatore lo sia frequentemente sia in film che in produzioni televisive e pure animazione, ma proprio per questi casi tempo fa creai Categoria:Pagine in cancellazione - spettacolo, e possiamo sempre fare Categoria:Pagine in cancellazione - doppiaggio. Ripeto: in genere di argomenti ne bastano un paio, dunque non vedo la necessità di andare oltre i 3. Sanremofilo (msg) 23:23, 29 set 2013 (CEST)

[← Rientro] Come vari altri qui sopra, sono contrario a rinominare il template S. Quando decidemmo l'unificazione dei template di avviso a una sola lettera fu fatto per un motivo che mi pare valido ancora oggi: l'estrema comodità e sveltezza d'uso. Come suggeriva Bultro, la categoria può essere rinominata e lo farei. Neutrale/favorevole all'introduzione del mese anno. Due argomenti al template cancellazione mi paiono invece sufficienti e non ne aggiungerei altri. --Lucas ✉ 08:00, 30 set 2013 (CEST)

Concordo con Lucas e Bultro: rinominare la categoria per coerenza con la pagina di aiuto. Ciò detto, io ero contrario alla riduzione a singola lettera e lo sono tuttora, ma è chiaro che tale decisione andrebbe ribaltata in modo coerente su tutti gli avvisi e non ha al momento consenso quindi discuterla è inutile; sarebbe utile avere qualche analisi o dato concreto degli effetti che ciò ha sugli utenti specialmente nuovi, mentre le chiacchiere fra noi "dinosauri" non portano a molto. --Nemo 10:19, 30 set 2013 (CEST)

Per quanto riguarda il template S, non sarebbe un grosso problema se Template:Abbozzo fosse un redirect (o viceversa, la cosa sarebbe irrilevante). Alla fine è un template tecnico, per cui va bene un nome che anche se non è italiano è comunque riconoscibile dal wikipediano medio. È lo stesso discorso che si può applicare a termini come "wikificare", descrive talmente bene il concetto che il fatto che non esista è secondario. --Cruccone (msg) 15:56, 30 set 2013 (CEST)

{{S}} è di gran lunga uno dei template più usati e preferirei anche io, sinceramente, mantenerlo col nome attuale e l'abbreviazione a una sola lettera. Oltretutto, se si implementasse il redirect come {{Abbozzo}} si introdurrebbe un piccolo elemento di confusione tra la versione lunga che ha il nome che inizia per "A" e quella corta che è "S", cosa non proprio immediata. Sono invece favorevole all'inserimento in {{S}} di data e anno come parametri opzionali, sia perché questa modifica non avrebbe impatti sull'esistente, poi perché anche gli altri template "frequenti" lo prevedono e quindi non sarebbe poi tutta questa complicazione in più, e infine perché agevolerebbe il "lavoro sporco" individuando per esempio le voci nate e rimaste stub (che presumo siano non poche). Sul {{cn}}, direi che più che introdurre data e anno, forse sarebbe più utile ragionare se invece non sarebbe meglio fonderlo con {{chiarire}} e usare un unico template per entrambi gli scopi. Sul {{Cancellazione}} preferirei evitare di toccarlo, visto che è già alquanto complesso di suo e che il ricorso a eventuali terzi o quarti argomenti mi sembra davvero evento rarissimo (come del resto per gli altri template che prevedono un argomento), ma se ci si orienta verso questo, allora concordo con Vito che tanto vale farlo tramite codice Lua che a quel punto renderebbe praticamente illimitato il numero di argomenti inseribili (ovviamente con relativo avviso a tutti i progetti corrispondenti :)). --L736E^{l'adminalcolico} 18:06, 30 set 2013 (CEST)

Per me S va bene come sta, ma sono favore dell'omogeneita' di codice di tutti i template (la richiesi gia' in passato, trovo molto scomodo avere sintassi diverse, tipo per la data). S ha poco l'uso della data anche per questo fatto.

Per la fusione {{cn}} e {{chiarire}} una certa idea me la ero fatta anche io, ma mi frena il fatto che {{cn}} in parte e' correlato a {{NN}}. In ogni caso la data, anche se opzionale e' oramai un campo indispensabile per organizzare il lavoro sporco.

Sugli arg di cancellazione, il problema vero secondo me e' che non tutti i progetti sono avvisati in automatico. Comunqe ci sono due tipi di template: il tipo uno, S e F, che ha arg ramificati (e che sto contribuendo con altri utenti ad omogeneizzare fra loro e alle cat di voci) e gli altri, come cancellazione, che hanno argomenti piu' generali e scarsa ramificazione. Ovviamente se gli arg sono generali necessariamente e' piu' facile averne bisogno di un terzo. Ma succede la stessa cosa col monitoraggio, che due non bastino.

La proposta che volevo fare per il futuro, che abbozzo adesso ma non ne sono ancora convintissimo e' che all'incirca S e F (fra 130000 e 250000 voci) mantengano la ramificazione estesa attuale e che U, A, CC, O, E... (fra 1000 e 10000 voci) ce l'abbiano meno estesa, ma che i due gruppi siano trattati omogeneamente (ovvero gli arg siano omogenei in ogni sottogruppo), e che il secondo sia un livello meno dettagliato del primo. A questo secondo gruppo potrebbero esserre concessi tre argomenti, perche' sarebbero anche piu' brevi e i template non sarebbero troppo pesanti.

Di fondo e' quanto sto gia' cercando di realizzare quando affronto il problema, piu' per buon senso che per ossessione da ordine. Anche qua mi frena per avere una visione generale come considerare {{NN}} che secondo me dovrebbe avere lo stesso livello di ramificazione di F, nel senso che li lascerei distinti ma li metterei nelle stesse categorie chiamandole qualcosa tipo "voci carenti di fonti". Oltre al vantaggio di evitare un duplicato, questo avvicinerebbe ulteriormente F(+NN) e S come numero di grandezza, e fluidificherebbe l'adozione di NN che e' frenata anche dalla inefficiente ramificazione. Anche W mi lasciava eprplesso ma secondo me non necessita' di un ampia categorizzazione, e lo associerei al secondo gruppo.

Comunque rimane la mia speranza di trattare Template:Cancellazione in modo unisono con tutti gli altri template "meno usati". Se tale template funziona meglio con 3 arg, allora presumibilmente anche E,U,O,D,NPOV che hanno simili ramificazioni delle cat funzionerebbero meglio con 3 arg.--Alexmar983 (msg) 19:26, 30 set 2013 (CEST)

Da un punto di vista strettamente tecnico, per aggiungere campi del tipo argomento3, argomento4, eccetera piuttosto che metter mano ai template usando la wikisintassi attuali, preferirei di gran lunga che si passasse a una gestione di questo tramite codice Lua, lo stesso che ha permesso di risolvere una volta per tutte il problema analogo del template {{Tracce}} che a furia di richieste di estensione si trovava ad avere prima 20 poi 50 parametri del tipo parametro1 parametro2 parametro3... e ancora non bastavano. La codifica in Lua permette invece di svincolarsi da una struttura di template rigida o rigidamente limitata, potendo gestire in automatico e senza limiti prefissati un numero qualsiasi di parametri di questo tipo che venissero inseriti nel template.--L736E^{l'adminalcolico} 21:25, 30 set 2013 (CEST)

Sono d'accordo con Bultro, Gce, Lucas e Nemo nel rinominare la "Categoria:Stub" in "Categoria:Abbozzi". -- Gi87 (msg) 21:27, 30 set 2013 (CEST)

Per me:

• Ok rinominare in categoria:Abbozzi.
• Ok implementare tramite Lua tmp:Cancellazione in modo da avere qualche argomento in più. A me non è mai capitato di avere bisogno di più di 4 argomenti, ma di 4 argomenti ho avuto bisogno abbastanza spesso.
• Ok a inserire mese anno in S.
• Lasciare S con questo nome.

Vorrei capire meglio come mai si intende unificare Cn e Chiarire: mi pare abbiano sensi e scopi molto diversi. Una frase può essere fontata ma, anche a causa di un semplice refuso (una parola mancante...), risultare incoerente. Qual è l'utilità di avere un unico tmp che si biforca tramite parametro per segnalare cose completamente diverse?

OT: Per la prossima volta, aprire la discussione al progetto competente, segnalare agli altri progetti interessati, segnalare come discussione esterna al bar quando, come in questo caso, la proposta affetta centinaia o migliaia di voci o è cmq di interesse generale. Anzi, per quanto mi riguarda, il bar generalista potrebbe tranquillamente vivere di sole segnalazioni esterne, poiché c'è sempre una talk di progetto più adatta. --pequod76 15:05, 1 ott 2013 (CEST)

@Quelli che vorrebbero aggiungere la data agli stub: sarei proprio curioso di sapere come pensate di operare sulle 286.120 voci che sono abbozzo in questo momento. Come pensate che si possa aggiungere il nuovo parametro? Per quanto a mia conoscenza non penso che un bot sia in grado di rilevare il momento in cui il template è stato apposto (che può essere anche a distanza di anni dalla creazione della voce).

Per inciso, personalmente sono sfavorevolissimo all'aggiunta del parametro data, trovandolo del tutto inutile ed ininfluente per quel determinato tipo di avviso. --Pil56 (msg) 17:01, 2 ott 2013 (CEST)

Se non è possibile via bot (mi sembra strano, però, che un bot non riesca a scorrere le varie versioni di una voce, farò intervenire qui qualche manovratore) qualche volontario lo farà a mano, se necessario, anche perché con un Festival degli abbozzi in cantiere una suddivisione per data risulta quasi indispensabile per non dover usare criteri personali nella scelta delle voci da inserire o escludere dal Festival. --Gce (Il Vile Censore Mascarato 2013) 18:42, 2 ott 2013 (CEST)

Il mese scorso abbiamo aggiunto il parametro "data" al template:Correggere, ma è andata bene perché si trattava di poco più di mille voci. In questo caso sarebbe un bel problema. Anch'io sono contrario all'introduzione del parametro "data" al template S, ma non per il problema suddetto (i tempi di sviluppo di una soluzione, se non pressocché infiniti, non dovrebbero pesare sulle decisioni prese in un progetto dinamico), bensì per la mancanza di utilità di tale parametro. A me non interessa sapere da quanto tempo una voce è uno stub, mentre mi interessa sapere da quanto tempo una voce è da controllare o carente di fonti. Un compromesso potrebbe essere inserire un parametro opzionale con dichiarazione esplicita, ma in tal caso la categorizzazione per mese sarebbe risulterebbe solo parziale e non potrebbe essere utilizzata per FdQ o simili. --Horcrux⁹² 19:23, 2 ott 2013 (CEST)

In realtà, se non ho visto male, il consenso vira proprio verso il parametro opzionale, quindi non sarebbe questo il problema. Per me l'importante è che venga inserita la possibilità di avere questo parametro, perché poi sulla datazione una soluzione in qualche modo si trova. --Gce (Il Vile Censore Mascarato 2013) 19:33, 2 ott 2013 (CEST)

Mi interessa capire meglio chi pensa che la data sia inutile in S e utile altrove. A me sfugge la differenza, sul serio. Poco o tanto utile, l'utilità mi pare la stessa. Del resto, una voce da correggere tutto sommato è da correggere: quella che è da correggere da più tempo è più urgente solo relativamente. A mio avviso la data serve a enfatizzare una priorità soprattutto per ragioni *connesse*, per es. per evitare che la voce diventi dormiente e che assommi non solo la stubbagine ma anche problemi di connettività. Oppure che sia una voce non più abbozzo su cui grava ancora l'avviso. Per quanto riguarda che data inserire, ricordavo che negli altri casi si era inserita una data "fittizia", nel nostro caso potrebbe essere "settembre 2013" (così le distinguiamo da quelle indicate propriamente con "ottobre 2013"). --pequod76 19:56, 2 ott 2013 (CEST)

[← Rientro] Per rilevare la data di quanto è stato inserito il template, probabilmente basta usare il dump del database completo di cronologia o il dump completo di tutte le versioni. Non ho mai provato, ma sto scaricando una copia del primo tipo proprio adesso, vi farò sapere. Personalmente sono d'accordo nell'aggiungere la data sia al template S che al CN. Eventualmente si può rendere opzionale per qualche mese, per poi renderlo obbligatorio. Il CN lo preferisco separato dal Chiarire, aiuta comunque a smistare il "lavoro" in maniera più dettagliata. Sulla rinomina del template S non mi pronuncio perché normalmente uso la toolbar, non vedo però il vantaggio per chi usa VisualEditor, a meno che non si intenda che Abbozzo è una parola più nota di Stub. Per le cancellazioni se avere più argomenti significa aumentare la visibilità ben venga ma a questo punto anch'io preferirei l'uso di Lua per aumentarne a flessibilità. --ValterVB (msg) 20:10, 2 ott 2013 (CEST)

Non rilevo la difficoltà ad inserire S con VE. In cosa consisterebbe? --pequod76 20:21, 2 ott 2013 (CEST)

Inizio con una battuta: qualche volontario lo farà a mano, se necessario, GCE, sei sicuro di quel che dici? hai idea di quante siano 286.000 voci da passarsi a manina? ;-) :-) (e, en passant, non sono di certo il miglior manovratore di bot, però una qual piccola esperienza ce l'ho anch'io sull'argomento, in particolare proprio sul lavoro sporco).

Tornando in argomento e per rispondere a Pequod, prendendola un po' alla lontana: quando si è fatta la revisione dei template di avviso (vado ovviamente a memoria) si è scelto di corredarli di una piccola banda laterale a sinistra con vari colori, colori che indicavano il livello di "urgenza" dell'intervento sulla voce (come del resto si può ancora vedere in Aiuto:Avvisi). Almeno a me è sempre sembrato ovvio che più erano urgenti gli avvisi, più era il caso di indicare la data di apposizione e più era il caso di fare iniziative affinché le categorie si svuotassero tempestivamente. Seguendo questo ragionamento, l'avviso "S" è proprio l'ultimo dell'elenco, senza alcun vincolo temporale di essere tolto velocemente e, per me, la situazione è ancora quella.

Con un po' di amarezza ci aggiungo anche il fatto che, sempre ovviamente opinione personale, troppo spesso questi "festival", pur nascendo con tutte le migliori intenzioni, ottengono dei risultati controproducenti. Il solo pensiero ipotetico di uno come me (io mi definisco il re dei somari sull'argomento filosofia) che, nell'ambito di un festival del "togli lo stub", passasse su una voce filosofica e provasse ad ampliarla o decidesse che è abbastanza sviluppata da poter togliere l'avviso, è una cosa che mi fa accapponare la pelle. :-|

Anche per questo, vedendo oltremodo che Categoria:Wikificare per mese ha voci di oltre 5 anni fa, Categoria:Pagine orfane per mese di oltre 3 anni, Categoria:Senza fonti per mese e Categoria:Controllare per mese di oltre 6 anni, ecc.ecc. trovo una vera e propria perdita di tempo e una dispersione inutile di energia tutta questa "datazione" degli stub. --Pil56 (msg) 21:43, 2 ott 2013 (CEST)

pequod76, come ha già accennato ValterVB, Abbozzo è una parola più nota di S ed un utente non avvezzo all'ambiente (solitamente un nuovo utente) potrebbe trovare più facile scrivere Abbozzo per cercare il template piuttosto che S; anche per questo avevo fatto la prima proposta (di fatto respinta).

Pil56, lo so bene che è una quantità enorme, ma la proposta di Festival non è urgente, quindi c'è tutto il tempo necessario per poter completare il tutto. Sarà anche il problema meno urgente fra quelli del lavoro sporco, ma è diventato quello più numeroso (oramai quasi il 20% delle voci ha apposto questo template) e non vorrei proprio che una voce si ritrovi con questo template anche per decenni (cosa attualmente possibile e che una serie di Festival della Qualità potrebbe evitare, anche se non ti piace molto come opzione).--Gce (Il Vile Censore Mascarato 2013) 21:59, 2 ott 2013 (CEST)

Sono d'accordo con Pil, anche a me i festival "togli lo stub" non piacciono: sono al più festival di progetto, per utenti dichiaratamente interessati ad un certo argomento. Non deve sussistere serialità in questo genere di operazioni. In genere, il lavoro migliore che uno può fare è studiare con l'adeguata profondità UN argomento (=una voce) e scrivere di quello. --pequod76 02:41, 3 ott 2013 (CEST)

la data in S io la inserisco gia', trovo soprattutto assurdo la differenza di sintassi nel codice visto che in un caso ho arg2 e nell'altro no, in un caso non ho date e nell'altro si... una percentuale a due cifre degli S hanno gia' una data. La data e' solo un'altra informazione, che male non fa. Se si inzia a inserirla si piu' da un certo momento, lo trovo positivo. Ognuno perde del resto il tempo come preferisce, se mi si consente una battuta "perderlo" per giustificare perche' gli altri lo "perderebbero" e' ad esempio uno dei tanti modi. l'aggiunta della data per me che inserisco molti avvisi sono 5 secondi di battitura (ma anche meno). Per una media di 5 S al giorno (gonfiatissima stima) fa... 25s! ( am anche 10 s). Senza contare che se ho S e F assieme comunque perdo tempo per la differenza di sintassi, copiaincollando gli avvisi faccio prima ma perdo comunque due secondi a cancellare "arg2" e altri due a inserire "date=". Anche se parliamo di spiccoli, col sistema attuale in cui comunque a data a F viene messa l'attuale sintassi me lo fa comunque perdere tempo perche' non posso copia incollare. E copia incolare il codice e' comunque piu' rapido che ricompilare i campi a uno ad uno in VE, per me che faccio errori di battitura spesso.

Per il resto, vedere la dinamica di riempimento delle categorie di servizio la dice lunga sui problemi che ci sono stati in passato e come evitarli. Per esempio c'e' differenza fra una categoria che ha avvisi vecchi di 6 anni ma pochi recenti e una categoria che ha avvisi vecchi di 4 anni ma molti recenti, in crescita. Idem quando segnalo a utenti competenti, ma nuovi, il lavoro sporco, perché le energie sono limitate e una voce sviluppata male da piu' tempo ha esteso i suoi effetti su molte altre voci.

In ogni caso pur avendo sempre proposto festival generalisti molto tecnici e concentrato l'attenzione sugli avvisi su casi talmente critici da non poter essere ignorati (tipo l'accumulo di piu' di 4 o 5 avvisi), sono sempre stato tendenzialmente neutrale ai festival sul semplice concetto di rimozione di avviso F o S in quanto tali. D'altro canto, nessuno dei partecipanti si e' mai forzato a intervenire su voci di cui non era pratico (non credo proprio che i festival F o S siano stati intesi con questa filosofia). Qua parliamo di eventualita' anche se la frase "troppo spesso questi "festival", pur nascendo con tutte le migliori intenzioni, ottengono dei risultati controproducenti" è riportata in indicativo. tralasciando l'uso delle virgolette su festival, lo spesso è un po' forzato visto che sono reiniziati da maggio 2013, e fatico a vedere cosa ci sia di controproducente nel mettere un infobox laterale, inserire portali a voci non editate dal 2008, o riformulare un testo in violazione di copyright. Se sono stati citati degli esempi di problemi effettivi, cosa che mi sembrerebbe importante fare, me lo sono perso. Altirmenti sospetto che ci si riferisca a quelli che devono essere ancora fatti, ma appunto siamo nella dimensione delle ipotesi, non dei fatti concreti. Parlando di ipotesi, io ipotizzo che qualunque errore puntuale/singolo sarà sotto la media di quelli che vengono fatti ogni giorno, e minimale in valore assoluto sul totale delle voci trattate, e che i suoi effetti saranno nettamente compensati dagli effetti positivi del miglioramento globale della qualità di queste voci da bassissima a medio-bassa. Sono pur sempre uno degli utenti di festival che è attivo anche sui vagli, quindi ci provo a tenere d'occhio tutta la "fliera della qualità"... e tutte queste criticità non le vedo. --Alexmar983 (msg) 12:29, 3 ott 2013 (CEST)

Comunque, nel complesso, un templatista dovrebbe aiutarci a sistemare gli avvisi nella forma base {{X|arg1|arg2|arg...|mese anno|commento}}, e questo a prescindere da che il commento sia o no un parametro fondamentale (come in C o P) o un puro commento facoltativo (come in F). Questa armonizzazione prescinde dalla decisione da prendere su S, per cui qui mi sto permettendo un OT, perché ho ragione di credere che l'unico motivo per cui non si fa questa cosa non è il consenso, ma la riottosità di chi potrebbe farlo e o non si "scomoda" o non aderisce all'opzione. --pequod76 15:07, 3 ott 2013 (CEST)

Andrebbe benissimo come puro commento, che ad esempio nelle migliaia di stub su calciatori sarebbe del tutto superfluo, dato che mi pare del tutto ovvio che a Bio+Sportivo+Link con al massimo un accenno alle gare disputate in prima/seconda serie od in nazionale si può certo aggiungere qualcosina. Però è effettivamente un parametro utile per spiegare chiaramente in quali aspetti la voce può senz'altro essere sviluppata, IMHO decisamente meglio che creare appositamente delle sezioni solo per segnalarle come mancanti od usare diversi {{S sezione}} nella stessa voce. Sulla questione della datazione: anche quella IMHO è utile, e come per gli altri avvisi è preferibile che chi passa in rassegna le voci col tag inizi da quelle più antiche. Perché evidentemente si tratta di voci trascurate, cosa che può capitare per svariati motivi: ambito familiare a pochi adepti, estrema difficoltà a reperire fonti, oggettiva impossibilità di ampliare la pagina, pagina della quale a suo tempo non ci si accorse nonostante fosse poco comprensibile od anche poco rilevante (il pensiero va agli stubbini su film creati 8 anni fa, diversi dei quali sono stati cancellati solo dopo averli cercati col lanternino). Sono tutte ipotesi verosimili in pagine che evidentemente sono rimaste in quello stato perché anche poco visitate, per uno dei motivi elencati, ed individuarle facilmente sarebbe dunque utile anche per il retropatrolling. Sulla spinosa questione della datazione degli stub già presenti, farei comunque notare a chi propone di provvedere a mano che, prendendo ad esempio il recente caso delle voci col {{correggere}}, se è quasi trascorso un mese perché si completasse la datazione di un migliaio di pagine, operata in massima parte da un paio di utenti che vi hanno dedicato una parte consistente del loro wikioperato del periodo (Antenor81 ed il sottoscritto), significa che realisticamente, supponendo che a dedicarsi alla datazione degli "S" sia una ventina di utenti, ossia il decuplo di quegli altri, se ne verrebbe fuori all'incirca nel giro di due anni e mezzo: ne varrebbe la pena? Non avendo competenza su ciò che sia possibile o meno fare tramite bot, se non si riuscisse agevolmente a risalire alla data di inserimento, butto lì una proposta: non si potrebbe semplicemente inserire la data di creazione della voce? Perché in generale, al di là di quando è stato segnalato come tale, una pagina che adesso è uno stub lo è sempre stata, a differenza di quanto può succedere un po' con tutti gli altri avvisi: una voce può essere, dopo un certo tempo dalla creazione, segnalata come {{T}} in seguito all'inserimento di una nuova parte di testo (in questo caso nascosto), e sempre in seguito ad ampliamenti può essere sopravvenuta l'opportunità di inserire {{W}}, {{Correggere}}, {{P}}, {{C}}, {{Controlcopy}}, {{L}}, mentre il semplice trascorrere del tempo può rendere necessario ricorrere in un momento successivo alla prima stesura di {{Aggiornare}} od addirittura {{E}}, dato che magari un argomento era stato ritenuto enciclopedico sull'onda del recentismo ma poi non si è neppure concretizzato. In sostanza una voce può "diventare stub" dopo molto tempo dalla scrittura in occasioni piuttosto eccezionali, tipo copyviol pressoché integrali non scoperti all'inizio, od in alcuni casi in cui si sia proceduto ad un sostanzioso scorporo. Credo che i bot almeno la datazione in base alla creazione possano farla tranquillamente, che ne dite? Sanremofilo (msg) 17:11, 3 ott 2013 (CEST)

[× Conflitto di modifiche] Sul punto 1 anche io sono contrario per le motivazioni già anticipate da alcuni e favorevole al 3. Invece per quanto riguarda il punto 2 sono d'accordo con la proposta principalmente per due motivi. In primo luogo questo ci avvicinerebbe all'ideale dei template ricordato da Pequod qui sopra, in cui la sintassi è uguale per tutti gli avvisi di servizio (con differenze di obbligatorietà). In secondo luogo ci dà un informazione in più. E secondo me non è inutile. Forse non così essenziale come in altri casi, ma può servire a non abbandonare voci magari facilmente ampliabili da qualcuno. In questo momento se io volessi ampliare qualche stub potrei sfogliarli per argomento, ma sarebbero ancora una marea. Aggiungendo un'altra discriminante si potrebbe focalizzare meglio il lavoro sporco (con i FdQ ancora di più). Quindi perché no? Mi sembra che l'unica motivazione contraria sia la fatica data la mole di lavoro. Ammetto che anche io ora come ora non saprei come fare col bot ma forse possiamo raccogliere le idee dopo. Intanto decidiamo se implementare la cosa (come ha detto Horcrux92, i problemi tecnici sono secondari alla proposta). --AlessioMela (msg) 17:21, 3 ott 2013 (CEST)

Proposta tecnica: ma a questo punto, non avrebbe più senso scrivere un unico modulo Lua di servizio che renda uniformi tutti i template di avviso più usati (sostanzialmente quelli "monolettera")? Adesso abbiamo:

1. Tutti i template accettano la data tranne {{S}} (ma togliere una voce dallo stato di stub non è altrettanto importante che dotare una voce di fonti o eliminare il POV? Questo come punto per chi trova "inutile" mettere la data: se serve per tutti gli altri, non capisco perché per gli stub, che son comunque "lavoro sporco" diventi improvvisamente inutile).
2. Alcuni template vogliono l'argomento in testa, altri in coda, alcuni accettano come sintassi sia arg che argomento, altri accettano solo uno e non l'altro
3. Per i campi di testo libero, alcuni template usano motivo altri commento, alcuni lo accettano in modo implicito, altri no
4. Per non parlare degli alberi delle categorie associati agli argomenti, che son diversi da template a template per cui il template X accetta l'argomento "pippo" mentre quello Y no....

A questo punto, un modulo di servizio Lua che, grazie alla flessibilità del codice, può gestire una situazione per cui tutti i parametri possono esser di fatto opzionali (e dove non lo sono, potrà esser sempre il resto del codice del template specifico a generare l'eventuale messaggio di errore), non pone limiti numerici su parametri del tipo arg, arg2, arg3,..., può gestire l'uso equivalente di arg piuttosto che argomento o di motivo/commento, risolverebbe in un colpo solo tutti i problemi di uniformità per quanto riguarda i parametri dei template di avviso. Poi, sarà il codice "tradizionale" specifico dei singoli template a giostrarsi le differenze specifiche di utilizzo, ma così, con un lavoro di codifica unico e centralizzato, mettiamo a posto le cose per tutti in una botta sola, col vantaggio che qualsiasi miglioria al codice Lua di servizio sarà inoltre automaticamente disponibile subito per tutti i template di avviso. Per quanto riguarda poi l'aggiunta della data a {{S}} rispetto ai template esistenti: se si crea una categoria, si può anche creare una categoria degli "Stub senza data" oppure, con un parsing del database meno "pesante" anche una più grossolana categoria di stub "per anno" invece che "per mese e per anno".. --L736E^{l'adminalcolico} 00:24, 4 ott 2013 (CEST)

L736E, se si può fare, tutto santo e benedetto. :) Queste difformità sono fastidiose. Quella relativa alla posizione del parametro "commento" è stata difesa in base all'obbligatorietà, ma non mi pare troppo pertinente.

La proposta di Sanremofilo, indicare per "mese anno" la stessa data della creazione, mi pare assai ingegnosa e la adotterei senza esitazione. --pequod76 01:34, 4 ott 2013 (CEST)

Sulla difformità delle categorie ci stiamo lavorando, ma come ho detto solo per F e S, agganciandole alle voci e wikidatando alle altre lingue gli stub. Come ho suggerito sopra tuttavia sugli altri avvisi ci andrei cauto. A meno che non trovassimo un modo flessibile di creare cat vuote o redirectarle (tipo l'avviso U ha come argomento "Bretagna" ma in realtà rimanda alla categoria "voci da unire - Francia". In ogni caso l'uniformità di sintassi accelerarà l'uniformità di categorie di servizio, e la considero prioritaria al momento.--Alexmar983 (msg) 10:10, 4 ott 2013 (CEST)

Sì, quanto all'albero delle cat di servizio, penso anch'io che S e F debbano viaggiare ad un'altra velocità. Se però si analizza la cosa da vicino, quasi quasi sarebbe meglio associare a S e F anche E, W e A. Certo, si tratta di avvisi virtualmente più volatili, ma sono anch'essi di largo utilizzo. Un caso a parte è C, che per altre considerazioni farei andare alla profondità dei precedenti. Solo U, NN, O e P sono avvisi in cui possiamo certamente permetterci una categorizzazione più leggera. Riassumendo: S, F, C, W, E, A armonizzati alla massima profondità. Certo, possono prodursi delle cat di servizio meno utili di altre, ma almeno gli utenti non perdono la testa a cercare quelle che servono. E questo albero di servizio così armonizzato non deve comunque andare in parallelo a quello di ns0, perché si tratterebbe di una frammentazione non necessaria. --pequod76 10:32, 4 ott 2013 (CEST)

quando ho detto armonizzato, non intedevo ovviamente allo stesso livello. Su altri avvisi, tralasciando NN che forse ho detto andrebbe fuso con F a livello di categorie ma su cui non ho idee chiare, ho forti dubbi su C,E,A... piu' neutrale su W, ma ne abbiamo di strada da fare quindi se riparleremo con calma minimo fra un anno se tutto va bene quando abbiamo "finito" con S e F... Anche portare U, NN, O,P allo stesso livello di cat ( e A,C,E almeno fino a quel livello) sara' comunque un lavoro corposetto (meno cat ma molto piu' avvisi...). A quel punto apriro io una discussione al bar, voi continuate a ragionarci su nel frattempo. Estote paratii--Alexmar983 (msg) 11:26, 4 ott 2013 (CEST)

Copio qui per comodità il Mementovert (alcuni dati li lascio nascosti: qui non ci interessano, ma valga da riferimento per il futuro):

• Da wikificare: 13606
• Da controllare per inesattezze: 4801
• Da aiutare: 590
• Da verificare per enciclopedicità: 2094
• Da verificare per neutralità: 1974
• Mancanti di fonti: 77972
• Da disorfanare: 9261
• Stub: 286120

Da queste cifre si evince che S, F e W viaggiano ad un ordine diverso e poi c'è la sorpresa di O. Non so per O, ma a questo punto W andrebbe imho inserito nelle allstar degli avvisi con cat di servizio profonde. --pequod76 12:46, 4 ott 2013 (CEST)

sorpresa O? L'abbiamo saccheggiata per due anni... il motivo per cui W non mi convince troppo è che F e S sono inerenti al contenuto, quindi categorie affini implicano fonti affini ad esempio, il che e' utile. Mentre W e' un'azione "meccanica", di stile, quindi conta poco da dove inizi basta che inizi. Un calciatore lituano non è diverso da un calciatore russo, e lo stesso un comune spagnolo da uno congolese... la bozza di stile e' unica. Si certo non si deve fare solo quello, a volte, e ci sono sovraposizioni, quindi per questo mi pongo "neutrale", ma comunque per questo pur sapendone l'entita' numerica non l'ho mai avvicinata troppo alle 260000 stub e 130000 (reali) F come priorità. E poi F e S sono cat per niubbi anche volenterosi quindi ci tengo a dare loro una base di lavoro ordinata e dettagliata, mentre le altre di fondo sono cat un po' più per wikipediani "esperti". Ma come ho detto, io W non la tocco per priorità soprattutto, poi se qualcuno vuole mettersi a fare cat anche la', io non giudico troppo.--Alexmar983 (msg) 13:04, 4 ott 2013 (CEST)

Per chiarezza, poi magari è ovvio: non mi aspettavo che le O fossero così tante.

Su W la tua osservazione è corretta, anche se non so se possono pesare alcune convenzioni a livello di progetto. Certo, nel complesso, W si applica fondamentalmente a grassetti, corsivi o altre cose marchiane, quindi il tuo ragionamento filerebbe.

Quanto a NN, ho provato persino a cancellarlo, è iperarduo capire se una voce è senza note ma creata con la bibliografia pertinente oppure proprio senza fonti e "ingrassata" di bibliografia non pertinente o pertinente solo per caso. Cmq il caso di NN è meno diffuso, meno di 4000 casi: non lo allineerei a F. --pequod76 13:54, 4 ott 2013 (CEST)

9261 sono poche, non tante. Abbiamo smesso di cacciarle e forse altre 500 sono facilmente orfanabili (oppure a dubbio E) ma la cat iperspecifica non avrebbe molto senso operativo: rimagono soprattutto voci disorfanabili via voci-liste o navbox (che e' correlato alle cat delle voci, comunque iper-specifiche), via unione (che abbiamo detto non ha bisogno di grande ramificazione) oppure per creazione o ampliamento di altre voci, che spesso non rientrano nella stessa cat di lavoro sporco o di voci. Senza contare che il problema non sono le O, ma le isolate (altre 4000), che rimangono fuori. Per questo secondo me non "conviene".

per NN non voglio allineare le cat in duplicato, vorrei fonderle. Ovvero vorrei che le F e le NN siano nella stessa categoria. Non necessariamente questo implica sbarazzarsi del template come significato, ma forse ripensarlo. Vorrei in futuro un gradazione di problemi di F insita nel template: per intenderci, ma potrebbe essere in modo diverso, F0=senza fonti, F1= senza fonti terze, F2= non abbastanza fonti, F3(=NN)= fonti non puntuali... anche in combinazione e aggiungendo una semplice aggiunta di parametro non dovrei fare un esplicito commento sempre. Secondo me su quella tua proposta si manco' la tempistica (era troppo presto, la gente allora sottostimava le voci totalmente prive di fonti di un fattore 4!) e forse il modo (la PdC). Quando la dimensione e la natura del problema delle fonti mancanti sara' "condiviso" in generale, secondo me troveremo una migliore soluzione "funzionale". --Alexmar983 (msg) 14:33, 4 ott 2013 (CEST)

Ah, ok, su NN e F non avevo capito. Dato che dal mio pdv NN semplicemente non ha alcun senso, sono favorevole a fondere le sue cat di servizio con quelle di F. Non penso che su NN ci sia spazio su rimodulazioni del suo (non-)significato: non riesco a immaginare alcuna sua evoluzione.

Su O, concordo, non dico che siano tante in assoluto, mi riferivo al numero che stiamo considerando in relazione a questo discorso delle cat di servizio. Su O va bene rifletterci in un secondo momento.

Non ho capito bene questo F1: per noi una fonte non terza o è tollerabile per particolari ragioni o semplicemente non è una fonte. Non vedo grande interesse nel distinguere tra F2 e F0. Quanto a F3, visto che NN per me non ha alcun senso non lo ritengo neppure una gradazione funzionale. Come avevo opinato, poiché non ci limitiamo a inserire in bibliografia fonti effettivamente utilizzate ma abbiamo deciso (hanno deciso) che in biblio possono andare anche testi non direttamente usati per fontare, allora, ripeto, non è più un problema di "note puntuali": lo sa Jimbo se a una voce con NN mancano solo le note o proprio le fonti.

Comunque, restando al topic:

1. Ok per mese anno in S.
2. Ok a gestione Lua per avvisi monolettera e armonizzazione dell'ordine dei parametri.

--pequod76 14:58, 4 ott 2013 (CEST)

Bhe, la differenza la farebbe per me fra scrivere in un commento una spappardella lunga con errori di battitura annessi o limitarmi a un semplice codice addizionale di una stringa. Un niubbio mica lo capisce subito che una fonte non terza non è fonte vera e che a volte qualche riferimento puntuale aiuterebbe... magari in qualche caso -pochi temo- non glieli dovrai spiegare a parte in talk ;) --Alexmar983 (msg) 15:16, 4 ott 2013 (CEST)

Comunque non mi risulta che siano accettabili esclusivamente le fonti "terze", dato che dipende da ciò che si deve fontare: ad esempio, se devi scrivere chi è il "capo" di una certa cosa (azienda, manifestazione, ente territoriale...), come fonte va bene il sito ufficiale di quella cosa. Sanremofilo (msg) 16:28, 4 ott 2013 (CEST)

Anche, avevo scritto qualcosa di simile aprlando delle voci di aziende ma poi avevo cancellato epr scorciare l'intervento --Alexmar983 (msg) 16:40, 4 ott 2013 (CEST)

non mi risulta che siano accettabili esclusivamente le fonti "terze": sì, si sa e l'ho scritto. ;) per noi una fonte non terza o è tollerabile per particolari ragioni o semplicemente non è una fonte. Appunto per questo non ha imho molto senso fare distinzioni in astratto, tanto da modulare un tmp come F a seconda che abbia o meno fonti terze. In un caso una voce non ha fonti terze e la cosa non fa specie, in un altro non ha fonti terze e c'è un problema di POV. F è un avviso e generico com'è imho fa il suo dovere. --pequod76 12:56, 5 ott 2013 (CEST)

non sono distinzioni astratte, sono pratiche. Non solo per spiegare a chi è nuovo meglio (Quando inserisco un template F e specifico che non ci sono fonti terze mi sto solo evitando un passaggio inutile in talk, così vedo anche subito chi è in malafede ;) ), ma anche per organizzare il lavoro. Una voce fatta mettendo un sito non terzo p.e. ha statisticamente più problemi di NPOV, una fatta senza alcun sito ha statisticamente più problemi di W. Non neghiamoci funzionalità operativa in fase di riordino futura SE non costa nulla... Queste info se non costa fatca inserirle (e mica deve essere obbligatorio farlo) mostrano sempre una loro utilità. --Alexmar983 (msg) 20:05, 5 ott 2013 (CEST)

Guarda, tante volte ho avuto esigenze che gli altri non capivano e non se n'è fatto niente, quindi ti dico certamente che se non costa nulla o se non costa nulla troppo non ci metto becco. :-) --pequod76 22:16, 5 ott 2013 (CEST)

Riassumendo: la proposta 1 è respinta, sulla 3 non c'è molto consenso, sulla 4 c'è consenso se si passa a Lua e sulla 2 c'è abbastanza consenso. È così? Se sì, si può procedere al più presto all'applicazione del consenso emerso? --Gce (Il Vile Censore Mascarato 2013) 17:23, 8 ott 2013 (CEST)

Mo' sono 4? :) Presumo tu sottintenda che hai separato la numero 2 in A = mese anno in "S" e B = mese anno in "CN". Credo che si debba discutere ancora un po', per valutare il consenso alla mia idea di datare gli stub in base alla creazione e la fattibilità dell'aggiunta argomenti negli avvisi tramite Lua (non ho idea di cosa si tratti). Sanremofilo (msg) 14:10, 12 ott 2013 (CEST)

Anche io non ho capito perché 4. L'idea di mettere la S con la data di creazione della pagina è fattibile via bot. --AlessioMela (msg) 20:50, 12 ott 2013 (CEST)

Che fosse fattibile l'avevo capito, infatti per quella avevo parlato solo di "valutare il consenso". Sanremofilo (msg) 21:15, 12 ott 2013 (CEST)

Errore mio XD Credevo di averle proposti separatamente... Beh, c'è comunque del consenso per fare queste operazioni, l'importante è questo. Comunque non ho capito se c'è consenso a datare i CN o meno... --Gce (Il Vile Censore Mascarato 2013)

Mi scoccia un po' tornare a cercare i pareri in merito, ma mi pare di no (o forse la questione è stata un po' snobbata rispetto alle altre). Personalmente trovo la cosa ben poco utile: se il passaggio col "CN" non è stato cancellato, vuol dire che era almeno "verosimile", e l'eventuale inesattezza di qualche passaggio non inficia l'attendibilità generale della voce (sennò si sarebbe messo "F"), del resto la stessa presenza del "CN" invita il lettore a prendere l'affermazione con le pinze, ma la complessiva fruibilità della voce non ne risente certo come succede con gli altri avvisi. Sanremofilo (msg) 23:23, 13 ott 2013 (CEST)

Direi di chiudere le partite più nitide, riservandoci di discutere quelle dubbie ad altra volta. Questa discussione ha "conquistato" due punti importanti: si vuole mettere il parametro mese anno a S e si vuole armonizzare gli avvisi tramite Lua. Continuando a rigirare carne al fuoco imho perdiamo semplicemente di vista questi due punti. Intanto ho aperto Discussioni template:S#Inserire il parametro mese anno: è la volta buona?, in modo da raccogliere un consenso nitido per una faccenda così rilevante. Per la forma degli avvisi, invece, (ricordo la questione: il parametro commento/motivazione lo mettiamo sempre alla fine, per favore?) il consenso mi pare abbastanza largo: manca solo un templatista che curi la cosa ya. pequod76^talk 23:58, 13 ott 2013 (CEST)