Discussioni Wikipedia:Sondaggi/Aggiunta parametro mese anno al template S

Punto 3 dei pro

Gli abbozzi più antichi hanno facilmente altri problemi connessi

Intanto mi metto qui, eventualmente spostate: posso mettere un {{citazione necessaria}} al punto 3 dei favorevoli? Gli stub dei comuni creati via bot nel 2005 sono uguali a quelli creati l'anno scorso e anche in altri ambiti non ho visto tutta questa povertà in più nelle voci più vecchie (che nel frattempo in molti casi sono già state sistemate). --RaMatteo 15:58, 26 ott 2013 (CEST). Ma vedo che mentre stavo editando Bultro aveva già tolto il punto... come non detto.

Gli ho scritto di riaggiungerlo perché è meglio discuterne prima, soprattutto poiché lui è contrario all'aggiunta e mi sembra una rimozione un po' faziosa.

Quel punto non dice che ogni stub ha quel problema. Dice solamente che gli stub (in generale le voci, ma soprattutto) più vecchi possono avere problemi di quel tipo. E' evidente che voci create a stampino non abbiano problemi simili. --AlessioMela (msg) 16:05, 26 ott 2013 (CEST)

"faziosa" era la versione iniziale, con i contro praticamente assenti... Quel pro è oggettivamente falso, dato che

1. problemi di quel tipo non sono legati all'essere stub. se si vogliono esaminare le voci più "antiche", ciò è indipendente dalla presenza di S; ci sono altri modi di scovarle, i soliti EGO e anche qualche pagina speciale se non erro
2. una categoria sarebbe comunque inutile; se trovi un abbozzo del 2005 da wikificare, e lo wikifichi, rimane comunque un abbozzo del 2005 e rimane nella categoria --Bultro (m) 16:14, 26 ott 2013 (CEST)

(conflittato)Replico meglio: perché uno stub è rimasto stub per molti anni? Potrebbe essere perché c'è poco da dire o perché nessun vuole/sa scrivere di quell'argomento, come ad esempio certi comuni francesi (riportano tutti i dati oggettivi minimi ma ad esempio quelli storici non sono affrontati). Oppure potrebbe essere perché quello stub si è perso nel mare di Wikipedia (problema di connettività: una voce mal linkata è poco frequentata), perché l'argomento trattato è già presente da altre parti (magari perché ha un titolo sbagliato o tratta gli argomenti di una sezione di un'altra voce). Inoltre la qualità delle voci scritte molte anni fa si basava su standard diversi dagli odierni e stub dell'epoca potrebbero avere questa piccola pecca. Ovviamente questo discorso si potrebbe fare per voci create agli albori e praticamente mai più editate. Di questo insieme gli stub rappresentano secondo me la fetta maggiore. --AlessioMela (msg) 16:17, 26 ott 2013 (CEST)

Contro praticamente assenti. --AlessioMela (msg) 16:18, 26 ott 2013 (CEST)

Francamente nessuno più dei contrari può produrre una bozza migliore della parte "contro" dello specchietto. Io mi sono limitato all'origine a rileggermi la discussione e dove ho trovato argomentazioni più solide di embè? le ho inserite. Che siano poche non ha molta rilevanza: per es. il punto 3 (gli EGO) è molto solido. pequod76^talk 17:05, 26 ott 2013 (CEST)

Non stiamo a cazzeggiare su chi è fazioso (tutti), rispondete piuttosto ai due solidi punti di cui sopra. Adesso che è stato aggiunto il punto 6 poi, mi pare che sia sufficiente quello --Bultro (m) 11:50, 27 ott 2013 (CET)

Mi sembrava di aver risposto comunque sinteticamente riprendo:

1) sì è di tutte le voci antiche in generale, ancor di più se stub perché significa che da allora il loro stato praticamente non è cambiato e forse è anche "colpa" di altre cose. Tempo fa abbiamo fatto un fdq sulle voci meno editate di recente e questi problemi sono saltati fuori. Temo non ci siano pagine speciali funzionanti a riguardo.

2) questo punto non è l'unico e solo motivo per avere la categoria, è un aggiunta, un di più che si potrebbe fare avendo la categoria. Certo si potrebbe fare con gli EGO ma ci sono pro e contro (cat sempre aggiornata ma non "strikkabile", EGO strikkabile ma aggiornato manualmente se e quando qualcuno risponde visto che da quelle parti ci contiamo sulle orecchie o poco più).

Credo comunque che si possa unire al 6 senza però toglierne la sostanza (ovvero elencare i problemi trovabili). --AlessioMela (msg) 12:45, 27 ott 2013 (CET)

Punto 2 dei contro

La data sembra imporre delle scadenze

Sembra? Francamente non mi sembra un punto particolarmente sostenibile. Giusto inserirlo in fase bozza, ma lo metto fortemente in discussione. Ampliamento di massa? Anche qui non seguo il punto. Insomma, pro e contro devono essere fondati e condivisi. Non possiamo inserire tra i contro "la proposta sembra delegittimare l'operato di utente:Pequordio... :D pequod76^talk 17:03, 26 ott 2013 (CEST)

"può sembrare" o "ad alcuni sembra", se preferisci. L'hanno detto loro, non è che deve sembrare a tutti, sennò non c'era bisogno di fare un sondaggio... --Bultro (m) 11:48, 27 ott 2013 (CET)

Sinceramente, a parte il punto 3 dei contro (quello degli EGO), gli altri punti mi sembra che ricalchino la paura di cambiare le cose come stanno. In particolare questo punto mette le mani avanti dicendo che i wikipediani vedendo la data inizieranno ad agire con qualità peggiore perché spinti dalla fretta. Mi sembra un po' troppo WP:sfera (non è ns0 ma lasciatemi fare il paragone). Detto questo per me si può tenere nella lista dei motivi, per carità io non riesco nemmeno a comprendere le ragioni dell'1 e del 4 ma se qualche utente è perplesso per quei motivi è bene che restino scritti, poi ognuno si farà la sua idea. --AlessioMela (msg) 12:50, 27 ott 2013 (CET)

Prima che inizi il sondaggio, vorrei un tuo parere sugli EGO. Che ne pensi di quella argomentazione? pequod76^talk 21:03, 27 ott 2013 (CET)

Mi sembra un'argomentazione lecita. Si può tranquillamente lavorare sugli abbozzi vecchi chiedendo un EGO e si ha il vantaggio di averlo memorizzato su una pagina per segnare qualunque cosa. Questa modalità di lavoro ha lo svantaggio di essere lentamente aggiornabile (ci vuole un EGOista altruista :D che lo faccia) e di avere una bassa visibilità (di EGO utilizzati dagli utenti dopo diverso tempo dalla richiesta di creazione ce ne sono pochissimi): i meno scafati troverebbero più facilmente la categoria del suddetto. --AlessioMela (msg) 21:40, 27 ott 2013 (CET)

Se ci devi lavorare una tantum in maniera centralizzata l'EGO è IMHO vincente. Se l'idea è quella di poterci lavorare tutto l'anno in maniera non centralizzate credo invece che lo sia la categoria. --AlessioMela (msg) 21:57, 27 ott 2013 (CET)

Punto 2 dei pro

Elenco sempre aggiornato degli abozzi più vecchi
Più che un "pro" mi sembra un "in cosa consiste avere una categorizzazione per data". --Horcrux⁹² 21:15, 27 ott 2013 (CET)

Sì è vero. Si tratta di un punto pro perché senza l'aggiunta del parametro al template l'unico modo per avere quel servizio (quello esplicitato nel punto 2) è che si chieda un EGO, si aggiorni continuamente quest'ultimo e gli si dia la visibilità che ha categoria degli stub. --AlessioMela (msg) 21:32, 27 ott 2013 (CET)

Ossia è una ripetizione del punto 1? --Horcrux⁹² 21:46, 27 ott 2013 (CET)

Non è una ripetezione ma potrebbe essere integrato nell'1. In bozza li ho staccati in modo che si potesse fare una sorta di parallelo tra il punto 2 dei pro e il 3 dei contro. Ovvero tra gestione con categoria e gestione con EGO. Se pensi che sia comunque una ripetizione accorpa senza perde il concetto. --AlessioMela (msg) 21:53, 27 ott 2013 (CET)

Concludendo la bozza

Bene lavorare sui pro e i contro per cercare di renderli più chiari e vicini ai pensieri di coloro che li hanno espressi. Non vorrei però che ci consumassimo qui in diatribe forse poco utili per cambiare poca sostanza. Ad ogni modo, in bozza ho ipotizzato martedì mattina come data di inizio festival. Ad ormai poco più di un giorno dall'inizio, ritente che possa essere ancora una buona data o è meglio se ci prendiamo un altro po' di tempo? --AlessioMela (msg) 21:50, 27 ott 2013 (CET)

Io un tantinello in più aspetterei. Decidiamo martedì se eventualmente partire mercoledì? Possiamo sempre segnalare al bar generalista l'inizio della votazione. pequod76^talk 23:46, 27 ott 2013 (CET)

Certamente! --AlessioMela (msg) 00:10, 28 ott 2013 (CET)

[← Rientro]Ci siamo un attimo incagliati di nuovo. Viste le ultime modifiche vi sembra pronta la bozza? L'unica cosa forse in sospeso è l'ex punto 3 dei pro ora punto 2. Alla luce delle risposte, va bene così? Lo modifichiamo? A me sembra che sia i pareri dei pro che quelli dei contro scritti nella bozza rispecchino i pensieri delle discussioni precedenti. --AlessioMela (msg) 14:35, 30 ott 2013 (CET)

La mia proposta è di eliminare il punto 2 dei pro, perché comunque non è pertinente ed è vero che i problemi connessi delle voci più vecchie non abbisognano di una categorizzazione per data di S (che sarebbero solo strumentali), ma di altri strumenti più specifici.

La mia seconda proposta è di eliminare il punto 2 dei contro, completamente gratuito. La data suggerisce l'esistenza di "scadenze" che invece non ci sono. Si potrebbe rispondere che l'argomentazione suggerisce cose che invece non ci sono. Le argomentazioni devono avere un minimo di falsificabilità e questa è del tutto oracolare. Wikipedia può crescere spontaneamente dove e nelle direzioni che la comunità desidera, senza che alcuni argomenti abbiano precedenze. Cosa c'entrano gli argomenti? Si parla di inserire "mese anno", la precedenza della filosofia sul calcio è evidentemente un problema del tutto diverso. è comunque impensabile un ampliamento di massa, ancor più se basato sull'età delle voci. Una chiosa tanto per dire qualcosa? Scusate, a me risulta impenetrabile.

Non vedo di quale faziosità si possa parlare, non stiamo parlando di quote rosa in parlamento. Io non so se voterò, sono indeciso, per cui l'aggettivo sicuramente lo rifiuto e penso che tutti, pro e contro, stiano dando il loro contributo per definire la strategia migliore per il progetto.

Segnalo questo edit, che si riferisce al thread precedente.

Insomma, dobbiamo risolvere la questione dei punti 2 (in particolare quello pro) e poi possiamo partire. pequod76^talk 01:03, 31 ott 2013 (CET)

@AlessioMela: "Ad ogni modo, in bozza ho ipotizzato martedì mattina come data di inizio festival" quale festival? --valepert 19:49, 31 ott 2013 (CET)

Mi sono sbagliato. La parola da dire era sondaggio. --AlessioMela (msg) 19:52, 31 ott 2013 (CET)

Temo che questo fine settimana non ci sarò. Segnalo di aver messo atto al mio insano proposito e ho rimosso i 2 punti 2. Rollbeccate se non siete d'accordo, ovviamente. Qui il diff.

A queste condizioni penso si possa partire lunedì. E quando finisce questo (lo facciamo durare 14 dì, nespà?), probabilmente saremo lì lì per avviare quello sullo stile unico di citazione. :D :P pequod76^talk 02:31, 1 nov 2013 (CET)

Ok, poi lunedì si linkerà al bar e sul wikipediano. --AlessioMela (msg) 19:32, 1 nov 2013 (CET)

Come si era detto, ho fatto partire il sondaggio (spostando avanti l'ora visto il leggero ritardo). --AlessioMela (msg) 19:47, 4 nov 2013 (CET)

Anche gli EGO "depennati" hanno un problema

Punto 2 dei pro:

• spesso ci si dimentica, o non ci si accorge, di dover togliere un avviso S dalle voci che non lo necessitano più.

Punto 2 dei contro: per controlli come quelli [al punto 2] dei "pro", è più utile un elenco nel quale si possano - per esempio - depennare le voci già analizzate. La categoria per data serve a poco, visto che gli abbozzi già controllati continuano a rimanervi.

Però è anche vero che quando si rifanno gli EGO, gli "abbozzi", veri o presunti, ti tornano, a meno che tu non ci metta un qualche segno che dica all'EGOista (il quale avrà creato robe come "Voci create nel 2005 e col template S", "Voci create nel 2006 e col template S", "Voci create nel 2006 e meno lunghe di X byte" - cito da dr. Zimbu) di non inserire una certa voce in elenco. Ed è precisamente quel che si intende fare con la proposta di {{permastub}}.

Ho anche proposto un {{check stub}} (con sintassi {{check stub|data=mese anno}}), tramite cui indicare che un abbozzo - mettiamo - del febbraio 2010 è stato controllato (in data XY, indicata dal parametro "data") ed è ancora stub. pequod76^talk 01:40, 3 nov 2013 (CET)

Dipende anche dal motivo per cui rifai l'EGO, anche perché di "Voci create nel 2005 e col template S" (ad esempio) non ne spuntano tutti i giorni, e quindi quegli elenchi tenderanno a svuotarsi. Il motivo principale di ricreare un EGO del genere è ricontrollare le voci (ad esempio perché lo standard di qualità è diventato più alto), una situazione nel quale il controllo precedente è obsoleto o comunque da rivedere (anche se ovviamente sarebbe utile avere a portata di mano il commento precedente; forse il modo più comodo sarebbe spostare in una sottopagina l'EGO precedente, anziché sovrascrivere). Se poi lo scopo è togliere le voci che nel frattempo sono state destubbate, allora mi sembra ragionevole che comunque vengano viste da un utente che si occupa di quel lavoro sporco (perché ce ne saranno, vero?) in modo da controllare i famosi problemi connessi (categorie, connettività...) che sono legati solo di striscio al template S.

Segnalo inoltre che è tecnicamente possibile segnalare le voci da escludere da un EGO (è stato fatto qui, ad esempio)--Dr ζimbu (msg) 14:07, 3 nov 2013 (CET)

Gli elenchi tenderanno a svuotarsi: vero, ma resta il problema di un controllo che non porta a niente (cioè S rimane), per cui una certa voce, controllata, viene ricontrollata e ricontrollata... (questo discorso vale per le "meno lunghe di x byte, che è appunto il raggio d'azione di un tmp Permastub).

È vero che esistono whitelist, ma sono sottopagine di specifici EGO, mentre Permastub ha un significato generale e sarebbe utile a diversi EGO (funzionerebbe cioè da whitelist di diversi EGO possibili sul tema abbozzi. Inoltre, mentre un tmp Permastub è dentro la voce, per sapere se una voce è in una whitelist-sottopagina di EGO, devo cacciarmi nei magmatici Puntano qui (peraltro gestiti malissimo dai dev). A me pare abbastanza evidente che i templatini "promemoria" del genere permastub sono molto più alla portata di un utente mediamente esperto rispetto al contesto degli EGO. E trovo strano che, mentre si è disposti a derogare qualunque logica stringente in funzione della presunta efficacia di avere un tag "stub" (che esW e deW hanno buttato alle ortiche e che molti qui pure butterebbero alle ortiche), di botto si hanno crisi di concetto rispetto a "permastub" (è un concetto soggettivo!, mentre stub... pure, ma ormai c'abbiamo fatto il callo).

Nel complesso, in un panorama privo di certezze, si rifiutano idee snelle, la cui inutilità o dannosità è tutta da provare, e ci si viene anche a dire che gli stub sono un quarto dell'intero patrimonio di voci: certo, con la liberalità concettuale della parola "stub" (che tutti assicurano di dominare convenzionalmente), è un miracolo che gli stub indicati non siano 750.000! (scusate l'enfasi, resta un commento cordiale). pequod76^talk 14:43, 3 nov 2013 (CET)

È lo stesso problema della categoria: solo che un EGO viene aggiornato così spesso (se si deve dare il tempo di controllare le voci, e queste sono tante, anche un aggiornamento ogni tre/sei mesi può essere sufficiente).

Sul Permastub, avevo evitato di risponderti perché qui, nel contesto di questo sondaggio, mi sembra OT. Se vuoi la mia opinione, comunque, creare un template per trasformare un confine vago in due confini (anzi tre: tra stub e permastub, tra stub e niente e tra permastub e niente) altrettanto vaghi non è affatto un miglioramento--Dr ζimbu (msg) 15:11, 3 nov 2013 (CET)

Anch'io penso che cat e EGO abbiano lo stesso problema. Infatti, in entrambi i casi hai due scansioni:

• EGO - whitelist
• stub - permastub

Anche la whitelist, mi pare, inserisce un ulteriore confine meramente convenzionale (o più precisamente: valutato caso per caso): in ogni caso un confine arbitrario (e lo dico con tutta la simpatia per l'arbitrio sensu stricto). Si tratta di due modi paralleli di gestire inclusioni ed esclusioni rispetto ad un insieme X.

D'accordo con te che l'aggiornamento in tempo reale non è poi così importante.

Trattandosi di strategie, è chiaro che io non ho certezze, eh! :) Di fatto, solo l'utilizzo concreto può dirci se una strategia è meglio dell'altra, se è bene usarle entrambe (spesso alcune strategie sono escluse SOLO perché ce n'è già un'altra operativa)... Permastub secondo me è un tema collegato, perché è uno dei termini possibili per cui svuotare una "Voci create nel 2006 e meno lunghe di X byte". pequod76^talk 16:47, 3 nov 2013 (CET)

Necessario?

Non per far l'avvocato del diavolo, ma questo sondaggio mi pare eccessivo per la "problematica" presentata. Tant'è che è già venuto fuori qualcuno a proporre idee alternative (altri template, template più precisi, etc..). Insomma... ormai è partito e vada così, ma per la prossima volta ci penserei forse un paio di volte in più! --Gnumarcoo 15:36, 5 nov 2013 (CET)

Ci sono state due discussioni, entrambe arenatesi verso l'impossibilità di determinare il consenso; per questo si è arrivati al sondaggio. --Gce (Il Vile Censore Mascarato 2013) 18:46, 5 nov 2013 (CET)

Non potevamo fare altrimenti, io potrei obiettare perche' certe opzioni non mi soddisfano, ma nel migliore dei casi me ne viene riportata un'altra che non mi soddisfa... il problema e' che nel momento in cui si assume che le cose possano essere fatte in modi diversi, ed e' vero, non c'e' nessuna discriminante epr cui uno sia più giusto, ergo nessuno è più sbagliato. Infatti il No dal punto del si non fa altro che prendere qualcosa e proiettarlo per la tangente estremizzandolo, mentre per me almeno e' solo un quadro composito di strumenti, e in questo quadro composito vorrei anche questo. Finirà che ogni cosa per il rischio che diventi estrema sara' bocciata e poi regolarmente criticata perché funziona a metà proponendone la soprressione (penso al monitoraggi, o a cosa che non esistono tipo i permastub), quando invece se si mettessere piu' strumenti a lavorare sinergicamente si bilancerebbero/completerebbero perfettamente...--Alexmar983 (msg) 15:54, 6 nov 2013 (CET)

Anch'io non me l'aspettavo un sondaggio cosí, ma se i partecipanti a quella discussione l'hanno ritenuto utile/necessario allora mi va bene e partecipo. Un sondaggio è spesso utile per mettere un punto fermo, fosse anche "abbiamo sbagliato tutto, ripartiamo da zero con una discussione su basi diverse". --Nemo 23:50, 8 nov 2013 (CET)

Commenti

apro la sezione commenti per evidenziare due cose:

1. il sondaggio risulta ancora "In preparazione" nella pagina relativa ai sondaggi
2. è corretto andare a sondaggio per una questione su cui c'è il rischio di non ottenere un netto consenso? se al termine del sondaggio n utenti hanno votato No e n+1 Sì, rischiamo di andare ad incidere ad un template stra-utilizzato, su migliaia di voci e centinaia di categorie. se it.wiki dovesse andar giù il giorno dell'applicazione della nuova norma (che, ricordo, diventa valida chiuso il sondaggio), con quale coraggio si spiega alla WMF che la modifica è stata applicata "per un solo voto"? non rischiamo di andare in contraddizione con il concetto di "non è una dittatura della maggioranza"? --valepert 15:06, 6 nov 2013 (CET) ps. tale commento non vuole essere una critica globale al sistema dei sondaggi, ma all'utilizzo dello strumento per questioni più "tecniche", come appunto l'inserimento del suddetto parametro, che richiedono discussioni anche con il lato developer per capire l'impatto sul software in uno (bot a parte).

1. Ho spostato il sondaggio di sezione. Ma non capisco perché non l'abbia fatto tu stesso invece di "lamentarlo" qui.
2. Penso avremmo tutti evitato il sondaggio se ci fosse stata l'ombra di un qualche consenso; itwiki non andrà giù l'eventuale giorno dell'applicazione della norma perché, semmai dovesse inserire il nuovo parametro, il bot lo farà con le tempistiche standard di circa 10 edit al minuto, come per ogni altro intervento (vedi ad esempio quando sono stati tolti i link ai mesi su tutta Wikipedia). --AlessioMela (msg) 15:29, 6 nov 2013 (CET)

sono d'accordo con alessiomela nel caso del sì+1 non dovessimo applicare il sondaggio allora applicheremmo una decisione presa da una minoranza (fermo restando che il consenso wikipediano non c'è comunque) --Limonadis (msg) 15:45, 6 nov 2013 (CET)

(confl.) ricordo che S ha già un parametro data, non e' obbligatorio o uniformato, ma ce l'ha. D'altro canto se N+1 votano NO, non credo che questo implicherebbe che tutte le date inserite vanno tolte. Anche perché molti in realtà stanno votando NO al fatto che la data rappresenti una scadenza a giudicare dai commenti, cioè di fondo a una cosa differente, altri invece riportano di voler sostituire S con altri template (peccato che in teoria si suggerisca di fare il contrario) e altre infine questionano l'inutilità di S in quanto tale, altri infine ritengono che non dovrebbela data essere piu' discriminante dell'importanza della voce (infatti non e' così, nessuno ti obbliga a ritenerla piu' importante, e lasciarla se vuoi a un fattore al secondo ordine dopo l'importanza). Visto dal lato del Si il no appare impressionatemente frastagliato, che poi e' il motivo per cui siamo arrivati al sondaggio, non potevamo chiudere la questione dell'allineamento stilistico, perche' in realtà non e' una questione di per sè. Temo che finiremo col mantenere lo status quo. --Alexmar983 (msg) 15:46, 6 nov 2013 (CET)

il che significa che il sondaggio e' scritto male, ecco perche' i voti sono frammentari. Mi dispiace di essermi perso i giorni finali di discussione senno' lo facevo presente.--Alexmar983 (msg) 15:48, 6 nov 2013 (CET)

Mi dispiace davvero che sia scritto male dopo tutti i giorni spesi per migliorare i testi. Però ho visto che i commenti espressi durante il voto ricalcano la sintesi dei pro e dei contro sebbene forse alcuni non siano perfettamente mirati alla questione tecnica dell'aggiunta della data. --AlessioMela (msg) 15:54, 6 nov 2013 (CET)

I testi vanno bene, il "problema" è il quesito :) Dice proprio "Vuoi che venga aggiunto al template S il parametro "data"?" ma appunto S HA il paramtero "|date=", è proprio il suo nome :) E' la sintassi mese anno uniformata quello che volevamo (e implicitamente obbligatoria). Ma tanto cvambierebbe nulla, meta' della gente voterebbe NO scrivendo cose del tipo "no alla data in generale". Ergo metà la vogliono obbligatoria, metà la vogliono sbarbata, la sintesi è che rimane facoltativa. E noi ci troveremo l'ennesimo strumento di lavoro azzopato. Peccato.--Alexmar983 (msg) 16:05, 6 nov 2013 (CET)

@Alex: per curiosità, ma dove è scritto che il template possiede già il parametro "data" (o date) e a cosa serve in questo momento? --Pil56 (msg) 16:15, 6 nov 2013 (CET)

(conflittato) @Alex Ho capito cosa intendi, ma penso che questo nessuno l'abbia frainteso. Allo stato attuale il parametro data "facoltativo" di cui parli non viene giusto segnalato come errore, ma non ha alcuna utilità pratica ed è come se non ci fosse, per questo il quesito chiede l'aggiunta (senza entrare nei dettagli tecnici di come attivarla nel template). --AlessioMela (msg) 16:17, 6 nov 2013 (CET)

io l'ho imparato dal codice i primi tempi che esisteva, e dall'allora l'ho sempre inserito perché non mi costava di fondo nulla. Sono uno scienziato, per me ogni dato si rivela importante e non ha senso sprecarlo. Alcune volte l'ho usato ad esempio comparando la data quando i vari template sono stati messi, che mi fornisce informazioni sul livello medio di certe aree. Ma anche casi pratici per esempio sapere che S è stato apposto molto prima di U mi dà un'indicazione maggiore che quella U poteva essere sensata, e spesso a guardare nelle fonti era così. trucchetti, ma ti cambiano oggettivamente il wiki-lavoro soprattutto se fai quello sporco e voi avere il minimo impatto possibile. Siccome a me serviva se veniva messo da altri, per cortesia l'ho inserito a mia volta a beneficio di altri.--Alexmar983 (msg) 16:33, 6 nov 2013 (CET)

[a capo] IMHO è difficile valutare questa integrazione di parametro. Non credo che il sondaggio sia scritto male. Semplicemente il fronte del No ha evidenziato dei punti critici che io trovo non banali. Premesso che non dobbiamo alcuna spiegazione a WMF su come gestiamo quello che possiamo gestire, finché le decisioni sono consensuali e non idiote o volutamente autodistruttive - non più di quanto la fondazione debba o senta di dovere a noi nel momento in cui opera modifiche molto più sensibili e decisamente più idiote di questa (ma vedi anche la gestione barbina di VE)... premesso ciò, se i Sì vincono per una manciata di voti, ovviamente il sondaggio non vale e si torna a discutere: a) per approfondire sulle soluzioni diverse che sono venute fuori (durante la preparazione del sondaggio e dopo il suo avvio); b) per preparare *eventualmente* un secondo sondaggio. A me pare che a fronte dell'andamento del sondaggio, attualmente, possiamo dire con il senno di poi che si poteva temporeggiare un altro po', ma d'altra parte il sondaggio ha attirato altri pareri e questo, al di là del risultato, è comunque un fatto utile per chiarirci una faccenda non autoevidente. pequod76^talk 17:30, 6 nov 2013 (CET)

secondo me il vero problema qua è che non importa cosa proponi di qualsivoglia potenziamento/modifica, fra un terzo o la metà della comunità sarà contrario, e quindi siamo in stallo... ci sono strumenti diversi, e secondo me andrebbero adottati tutti in modo da permettere che ognuno usi strategie diverse. Non è un caso che ho iniziato a fare queste cose dopo la connettivita'... la connettivita' veniva da strumenti extra-itwiki, quindi non avevo problemi. Ma la conettività non risolve tutto, ci sono molte cose che si potrebbero spingere fino al massimo livello, ma vanno create in una logica equilibrata con altri strumenti. Per questo sono passato da quell'ambito a altri settori. Ma su it.wiki nessun altro strumento può essere veramente introdotto allo stato. Per esempio a chi dice "si valuti l'importanza e non la data"... certo che sono a favore, ma come posso introdurre p.e. "importanza" nel monitoraggio (come in altre wiki) se c'è chi il monitoraggio lo ritiene inutile? Tutti gli strumenti sono potenzialmente fallaci.. se si è realmente convinti che finiranno tutti usati male (ma perché poi se ne è convinti?), non c'è strategia migliore che potenziarli tutti. Se vai da un utente e gli fornisci un range ampio di opzioni capirà da solo che nessuna è quella corretta in assoluto. Qua invece si ha così sfiducia che si finisce in generale con lasciarle tutti gli strumenti "analitici" a metà. Che senso ha di fondo?--Alexmar983 (msg) 17:48, 6 nov 2013 (CET)

@valepert: Il sondaggio serve proprio quando non c'è consenso. Se su una certa cosa la comunità è nettamente divisa, non si può far altro che votare. Cosa potremmo fare altrimenti? Continuare a discutere all'infinito? O eleggere dei judge-user? --Horcrux_九二 19:55, 6 nov 2013 (CET)

il problema è che, come probabilmente fa notare lo stesso pequod, il sondaggio forse è stato aperto ad un punto della discussione prematuro. possibili segni a supporto di tale tesi sono i pro/contro che si sono delineati nel giro della settimana precedente all'apertura della procedura (almeno, guardando le date, gli interventi sono compresi tra il 26 ottobre e il 3 novembre). non voglio fare il guastafeste, ma mi sembra decisamente paradossale che nei Sì e nei No si finisca per citare la stessa pagina del ns Wikipedia a sostegno di due tesi opposte (il sondaggio è per sua natura dicotomico). si è forse compreso male il problema che, IMHO, è di natura squisitamente tecnica e non credo che una "chiamata alle urne" rivolta alla comunità possa dirimere il problema senza avere conseguenze future (non chiedetemi quali, non ho la sfera di cristallo). --valepert 21:58, 6 nov 2013 (CET)

Va be', con tutto il rispetto, non mi pare che il riferimento di Toadino alle scadenze sia particolarmente sostanziale. Se il sondaggio continua su questa china di parità, vorrà dire che è stato un "sondaggio" vero e proprio, più che una votazione con riflessi concreti. Evidentemente l'aspettativa dei proponenti era quella di trovare una marea di sì a fronte di un pur nutrito consenso. Non è stato così e questo deve fare riflettere. In ogni caso sondiamo, vorrà dire che questa pagina di Commenti resta uno spazio per idee alternative. Ero partito molto convinto per il sì, ma nella preparazione del sondaggio sono entrato in una dimensione di incertezza perfetta per qualsiasi filosofo che si rispetti. :P pequod76^talk 02:46, 7 nov 2013 (CET)

Credo che sia stato proposto perché in discussione preliminare il rapporto fra favorevoli e contrari andava verso i primi. Tuttavia il fallimento di un sondaggio si vede dalla reazione nelle risposte, non dalla loro quantita'. In discussione si e' stabilita la classica dinamica "obiezione A - risposta a obiezione A - obiezione B scorrelata da A - risposta a obiezione B - di nuovo obiezione A, troppo spesso senza considerare elementi della prima obiezione a A", quando questa si verifica vuol dire che la discussione non ingranerà mai. Lo vedevo sempre quando ero rappresentante. Fra l'altro non vedo tutta sta grande differenza di contenuti fra la discussione preliminare e la preparazione e i commenti alla votazione a scorrerle velocemente. Sono sempre le solite cose a) è compito il monitoraggio/importa la rilevanza della voce non la data b) gli EGO c) la scadenza che diventerà "certamente" una finalità d) costi operativi.--Alexmar983 (msg) 09:17, 7 nov 2013 (CET)

@Pequod: non c'era proprio nessuna aspettativa da parte dei proponenti. Anzi sapevo benissimo, visto le precedenti discussioni, che sarebbe stato difficile trovare un consenso, anche minimo. Quindi l'unico modo per toglierci dell'enpasse era affrontare il sondaggio. Tutto qui. Nessuna marea di sì attesa. Ne tanto meno penso ci debba essere un forte distacco tra i sì e i no per procedere in una direzione o nell'altra, se no sarebbe proprio indice di aver fatto male a scegliere di fare un sondaggio. --AlessioMela (msg) 10:51, 7 nov 2013 (CET)

fc. All'inizio della discussione e poi della preparazione del sondaggio, io personalmente mi aspettavo questo panorama. Cmq per una decisione così grossa non basta un "vantaggio" di 10 voti, soprattutto con la sensazione di una discussione involuta alle spalle. Sorry! :) pequod76^talk 11:15, 7 nov 2013 (CET)

ovviamento quando intendevo che era stato fatto vedendo una certa tendenza in discussione , non intendevo dire che chi lo ha proposto si apsettava un forte distacco, ma che si potesse superare un impasse almeno, con un margine accettabile, perché era la prima discussione in cui si sembrava delineare una "maggioranza". Poi, almeno per me, un 52% di risultato per SI o NO significa che nella fluttuazione statistica dei partecipanti c'è perfetta spaccatura, e nella mutevolezza di scenari di wikipedia non sarebbe utile procedere (nel caso del SI, il NO difatti non cambia nulla). Tuttavia anche per questo non esiterei a rifare il sondaggio dopo p.e. 2 anni per vedere se in effetti c'e' una tendenza. Un margine limitato ma che persiste nel tempo indipendentemente da votanti e scenario globale, indicherebbe già qualcosa di più.--Alexmar983 (msg) 11:02, 7 nov 2013 (CET)

[a capo] confl. Anch'io vedo un po' di deficit nella discussione, nel senso che le due parti hanno un po' stentato a costruire il dialogo, anche perché non è stato granché partecipato. Ma da questo dialogo involuto sono comunque usciti i quattro punti dei pro e bisogna ammettere che non sono esattamente irresistibili:

1. Aiuta a organizzare il lavoro sugli abbozzi: assunto un po' oracolare; di oggettivo c'è l'elemento "lista aggiornata" (gli EGO non sono così aggiornati, ma è stato fatto notare che su questo piano la cosa non rappresenta esattamente un dramma, non si tratta di un intervento del 911); si parla di "un elemento in più", senza provarne adeguatamente la rilevanza.
2. Verifica più efficiente dell'attualità dell'avviso: a dire il vero abbiamo già strumenti per risolvere questo problema; ovviamente è sensato aggiornare le decisioni, quindi vagliare le più antiche. Anche qui, ci sono gli EGO, un po' meno aggiornati, ma siamo lì.
3. Uniformità con gli altri avvisi: devo testimoniare che da quando è iniziato il sondaggio inserisco la data anche in S. Prima non lo facevo, dev'essere qualche strana allucinazione. Mi segna errore, correggo...
4. La qualità delle voci scritte molte anni fa si basava su standard diversi dagli odierni: come per il punto 2; il confronto è sempre quello con gli EGO. Sia L736E sia io avevamo chiesto che differenza ci fosse rispetto agli altri avvisi. Ebbene, riflettendoci, mi sento di dire che è vero: S ci dice che c'è qualcosa in meno. Guardando agli altri avvisi...:

• F: una frase senza fonte è una cosa in più che non può stare lì placidamente a tempo indeterminato: l'assenza di fonti non è in sé motivo di cancellazione, ma l'assenza di fonti per tre anni sì
• W: una voce o pezzi di voce da wikificare sono una presenza sgradevole
• U: un compito che attende e che importa per la strutturazione e la connettività
• A: l'avviso con scadenza par excellence
• E: con scadenza, non fissa, ma cmq con un timing incorporato
• NN: Alexmar ha proposto di attribuirgli lo stesso albero di servizio di F: poiché imho questo avviso è senza senso (non in assoluto, ma alle condizioni in cui si lascia che la bibliografia possa essere anche consigliata, cioè comprendente fonti non direttamente utilizzate per scrivere la voce), non posso che essere d'accordo
• O: problema principe della connettività, giusto avere ordini di priorità secondo la data di inserimento
• P: anche qui, presenza indesiderabile, vanno curati prima i più vecchi e, tranne casi particolarmente complessi (magari con archivi stracolmi di discussioni sul punto), si tratta di manutenzione ordinaria (toni enfatici, promo malcelato...)
• C: Per C va fatto un discorso a parte. C è molto legato a S, anche C parla di "voce involuta", di aspetti che mancano (c'è anche un legame con {{...}}, dunque). Ho più volte avanzato una proposta organica che comprende Permastub, {{...}} e C. Purtroppo non è facile discutere proposte organiche su wp, perché si impigliano in microresistenze settoriali che impediscono una visione d'insieme.

Infatti penso che il vero sondaggio che dovremmo fare è: abolire o no S, dato che il sistema stub di it.wiki è davvero solo abbozzato e, allo stato, è una categorizzazione inerte, nel senso che non ha alcuna effettività manifesta, a parte quella di provocare Festival per vagliare l'adeguatezza degli avvisi stessi, quindi provoca *costi*, è assurdo. Ed è inerte perché la cat è stracolma di qualsiasi cosa. E ciò è così perché "stub" non è un concetto definito, ma non di poco, eh, è proprio un UFO, una chimera del senso. Non serve al lettore: chiunque si accorge spannometricamente se una voce è o no più che abbozzata. Non serve all'editor, il quale si muove sostanzialmente secondo le sue competenze e i suoi desideri attuali. Certo, se si avesse modo di tenere pulita la cat:stub e di avere un concetto nitido (cat:stub = raccolta di voci brevi, tolti i permastub), allora un membro di progetto potrebbe ben rivolgersi ad una cat del genere ("vediamo dove siamo laschi"). Invece, ad oggi, sostanzialmente questo membro di progetto, nel rivolgersi a questa cat, sostanzialmente si confronta con opinioni ("a me questa voce pare abbozzata in rapporto a ciò che potrebbe dire"). Di fronte a questa vaghezza, l'albero di S rappresenta il secondo albero di cat più raffinato dopo quello di ns0 e fa da falsariga per gli altri alberi di servizio, ponendo questioni di rapporto con l'albero di ns0 che ci prendono tempo e intelletto. Se stesse a me, il sistema abbozzi così com'è formato oggi lo depennerei senza esitazione e, da membro del progetto linguistica, - mettiamo - mi farei fare un EGO delle voci di linguistica più brevi di tot, risparmiandomi cento altri orpelli di enorme peso nell'organigramma del lavoro sporco (abbiamo pure le icone stub!!!!!). --pequod76^talk 11:13, 7 nov 2013 (CET)

ma si dimentica la interconnessione fra gli avvisi. S si sovrappone in parte ma non e' l'unico avviso. E' la combinazione di avvisi che ti fornisce un'informazione preziosa di come agire. Comunque dovresti aver permastub quindi non semplificheresti molto. Hai comunque bisogno di indicazioni umane, e indicazioni quantitative "di EGO", perché nessuna è perfetta in sè.

fra l'altro la divisione degli S e' una cosa con cui nel lavoro sporco abbiamo delle affinità con altre wiki. Insomma e' un patrtimonio, sfruttato male, ma lo è. fra qualche mese S e F saranno sostanzialmente alineati come categorie, anche all'ns0 (sono solo finendo il lavoro inziiato da altri, ma giusto di tanto in tanto) e F trascinerà S anche a una certa riduzione di taglia (ma giustamente prima si devo linearizzare e POI sforbiciare, e così che si fa un ordine che dura). Proprio quando arriviamo a un risultato finalmente organico, rischieremo di buttare via l'insieme senza ancora vedere il suo esatto potenziale. Adesso per esempio mi tocca linkare alberi distinti ma in futuro avrei potuto linkare il semplice albero di lavoro sporco ai nuovi utenti (perche' l'obiettivo e' spingere a ampliare e non a creare, perché e' più gestibile e formativo). Come dicevo sopra, prima si gestiscono tutti gli strumeti a metà e poi si buttano perché sono a metà o, peggio ancora, quando si avviano a essere complete perché il fatto della riorganizzazione in breve lasso di tempo "richiama l'attenzione e mette tutti sull'allerta"...--Alexmar983 (msg) 11:41, 7 nov 2013 (CET)

Riallacciandomi a quanto detto da pequod, anch'io penso che vada svolto un sondaggio per abolire il template:S, che trovo inutile e "costoso". Il fatto che tale stub sia presente o no in una voce, non si ripercuote sulla sua sorte: infatti se una voce è troppo corta si mette il template:A, mentre negli altri casi si può ampliare quasi sempre e quando è troppo lunga basta vedere nelle pagine speciali quelle che sono le pagine più lunghe per rintracciarla, dunque non abbiamo bisogno del template S. Non sono l'unico a pensarla in questo modo, quindi mi pare giusto aprire un sondaggio per abolirlo, così ci possiamo poi concentrare ad altre faccende realmente importanti, ad esempio l'inserimento delle fonti, che è un lavoro sporco dignitosissimo e che funge anche da azione di verifica del contenuto delle voci, aumentando la qualità delle voci, non la quantità, così risolviamo anche una volta per tutte il dilemma quantità-qualità. Credo che Wikipedia abbia ormai passato l'adolescenza (= la fase della crescita), per cui è ora di concentrarci a valorizzare le conoscenze quello che abbiamo accumulato piuttosto che riempire Wikipedia di altra fuffa. --Daniele Pugliesi (msg)

I sistemi interrelazionati complessi non "maturano" mai, sono un continuum di evoluzioni e fissare verticisticamente una diga in un lato o l'altro (dubito che sara' cosa condivisa) e' un'operazione pericolosa. Le strutture d'analisi tornano ciclicamente ai punti di partenza a volte passando da visioni opposti (capita), ma sempre acquisendo valore aggiunto. Prendere qualcosa in formazione/in evoluzione e sbarbarlo sostuituendolo con altro non equivalente (anche a me piace rimuovere duplicati, ma questi non sono due duplicati, anzi ci sono chiaramente utenti che li suano entrambi) interrompe questo processo dialettico. Il punto è che questo processo in quanto tale rappresenta la maturita' di un sistema complesso, quindi bloccarlo non mi sembra una grande idea. Pensare che rimuovere un marcatore analitico sposti risorse "la' dove occorre" in sistemi di collaborazione complessi non funziona. Intendiamoci, se esistesse una linea editoriale, un "capo", andrebbe anche bene, ma nel nostro caso stai solo cannibalizzando una parte con un'altra.

Se alcuni quando fanno il loro lavoro non hanno bisogno di S buon per loro, ma altri sì e sono entrambi maturi, in un modo diverso che si chiama plurarità e che non è una terribile deviazione, ma parte integrante di un ambiente di lavoro condiviso. Per esempio io non ho bisogno di O per individuare le orfane, vado di toolserver! Nemmeno per l'argomento in teoria, c'è anche per quello la statistica di toolserver su singola categoria, quando d(ov)evo segnalare problemi struttrali ai progetti competenti. Inserisco e rimuovo le O ma curiosamente non uso tanto quel template, eppure non mi sognerei mai di toglierlo anche se lo uso poco in sè. Se io potessi molto banalmente inserirei tanto S e F in voce automatico dai dati del monitoraggio in discussione e se potessi inserirei un campo "conettivita'" nel monitoraggio e sarebbe tutto sinergico e molto più semplice, specificando il progetto di monitoraggio e le cat di lavoro sporco... e ognuno userebbe quello che gli pare. --Alexmar983 (msg) 12:41, 8 nov 2013 (CET)

S gestito dal monitoraggio mi sembra una grande idea. Sarebbe bene tornarci un domani. Sto buttando un'impressione molto a pelle, ma ho la sensazione che sia la risposta a chi vuole S, a chi non vuole S, a chi gli contesta aleatorietà... S sarebbe il risultato di una valutazione articolata, non un avviso messo o tolto alla c++++ come adesso. Una soluzione del genere toglie anche la necessità di permastub. Alex, la cosa va approfondita. Già adesso il monitoraggio restituisce una valutazione "abbozzo" e infatti ci siamo posti il problema di evitare ridondanza, *togliendo* al monitoraggio questo livello di (non)qualità. Forse è appunto meglio seguire la procedura inversa, togliendo un avviso che al lettore non serve, mantenendo una categorizzazione degli abbozzi, eliminando l'aleatorietà del mettere o del togliere a naso, cui oggi ci stringiamo perché non riusciamo a immaginarci alternative. --pequod76^sock 12:50, 8 nov 2013 (CET)

L'idea di lasciare l'indicazione di abbozzo solo nel monitoraggio mi piace: potremmo fare passare un bot che sostituisca i template:S attualmente nelle voci con il valore "abbozzo" nella tabella del monitoraggio nelle discussioni delle voci (creando la tabella se non esiste). In questo modo l'avviso di abbozzo non comparirebbe al lettore (a cui non gliene importa molto, soprattutto nel caso dei permastub), la data verrebbe inserita nel template monitoraggio e ci sarebbe un'indicazione più precisa dell'accuratezza della voce, passando da abbozzo a un grado di accuratezza maggiore fino a "voce completa". Dunque appoggio in pieno l'idea di Pequod. --Daniele Pugliesi (msg)

Anche a me piace quest'idea, l'avviso stub come è ora può "sporcare" una voce fino a tempo indeterminato considerando poi che il concetto di stub non è così oggettivo --Limonadis (msg) 15:15, 8 nov 2013 (CET)

Tuttavia credo che il template F debba rimanere visibile, se è vero che una voce stub è palesemente ed incontestabilmente incompleta (ad es. manca la trama di un'opera) il template F ha una sua funzione, c'è un mucchio di gente che prende per oro colato quello che dice wp e questo credo che sia un atteggiamento sbagliato anche quando ci sono le fonti, almeno uno che legge che le fonti mancano capisce che 1. quello che è scritto al momento non è verificabile 2. wikipedia apprezza le fonti. --Limonadis (msg) 15:24, 8 nov 2013 (CET)

Si ma e' comunque importante per alcuni di noi a livello operativo che rimanga la data. Intendo per quelli come me sarebbe da potenziare drasticamente la tabella di monitoraggio permettendo una flessibilita' di data nei campi singoli. Gia' in passato sostenevo che il monitoraggio andava sbarbato via dal concetto di "unica data" e "unico utente" e credo sia una strada percorrebile. Quando proponevo una gradazione di commenti alla F pensavo a questo ad esempio. Per esempio tu scrivi in campo fonti un certo codice e lui "automaticamente" (via bot con ritardo) segnala quel codice come agomento della F, con la sua data). Idem con la W. Rimangono ovviamente avvisi singoli di paragrafo da gestire, e la struttura degli argomenti, e appunto la possibilita' di avere nuovi campi (connettivita'? rilevanza?)... Mi sembrava un lavoro talmente tanto complesso da morire fra veti incrociati... vi ricordo che ci sono utenti che non amano il monitoraggio, spero solo che un giorno usciremo d questo clima di "sfiducia" incrociata. Non vorrei solo che si perdesso cose utili per alcuni, perché ritenuti inutili da altri e spero tanto che un giorno arrivi uno strumento "centralizzato" in discussione voce che trasformi tutte queste cose in dettagli al secondo ordine che ogni utente puo' modulare o ignorare come preferisce.--Alexmar983 (msg) 17:15, 8 nov 2013 (CET)

[a capo] Visto che qui siamo OT, ho aperto una sezione dedicata alla proposta: Discussioni progetto:Qualità/Monitoraggio voci#Gestire la cat:stub tramite il monitoraggio. pequod76^talk 18:35, 8 nov 2013 (CET)

Motivazione del No

Essendo favorevole all'introduzione di questo parametro ho letto attentamente soprattutto le motivazioni dell'"altra campana". Mi hanno colpito due motivazioni in particolare che ho faticato a capire:

• Quella di Sbisolo: Forse sarebbe meglio sostituirlo, quando è il caso, con avvisi più precisi; questo non è un sondaggio per abrogare il Template:S, né votando "no" lo si abolisce. Quindi proprio mi sfugge il nesso tra quanto scritto e il voto.
• Quella di Cotton: unica utilità sarebbe verificare i più vecchi per vedere se è il caso di rimuoverli, ma per questo basta un minimo di boldaggine senza complicare il template. Concordo parzialmente con la prima parte del discorso (serve anche a organizzarsi il lavoro: cerco di "completare" le voci più vecchie), non con la seconda: senza la data non ci vuole boldaggine, ma un lavoro nella cronologia. Perché, alla fine, è questo il motivo per cui voto sì: quando veto una pagina che mi sembra completa con una S in cima, verifico se va tolta analizzando la cronologia cercando di capire quando è stata inserita; quindi vado di diff per capire se la situazione è migliorata in maniera tale da giustificare la rimozione dell'avviso. Inserire questo parametro semplificherebbe questa attività.

Scrivo qui per avere delucidazioni, nel caso in cui avessi capito male. --Cpaolo79 (msg) 13:10, 7 nov 2013 (CET)

Se controllare la cronologia ti fa fatica, ti suggerisco di ignorarla. :) Giudica se la voce sia un abbozzo o no e lascialo o rimuovilo di consequenza, non andare a vedere quanti caratteri sono stati aggiunti rispetto alla situazione considerata deficitaria da un predecessore: altrimenti la sua valutazione influenza la tua e invece di due pareri ne abbiamo uno e mezzo. --Nemo 21:43, 7 nov 2013 (CET)

dipende: alcune persone sono influenzate da certi fattori, altre sono più obiettive o eprsino meglio obiettive. Nessuno ha un modo perfetto di fare le cose. Ad esempio io non ho mai valutato la rimozione di S partendo dalla crono, a me servirebbe poco per questo. Tuttavia capita che io giudichi S rimuovibili guardando altre lingue (o cercando fonti integrative, da qui l'importanza di avere anche la F ad esempio) e POI guardo la crono in cerca di ampiamenti consistenti cliccando su alcuni punti della crono, Se vedo che quando materiale è stato aggiunto S era già riportata sono bold e rimuovo. Non è mai successo ma Se vedessi che S è stata apposta dopo un ampliamento, lascere una cortese richiesta in talk, perché non voglio edit war per una tale sciocchezza. Quindi a me ad esempio la crono di S non servirebbe come a Cpaolo79 in quetsi contesti.

Sinceramente, il motivo principale per cui non ho paura di nessuna deriva di tutti questi strumenti "analitici" e della loro "influenza" in una certa direzione, è perché sono sempre più convinto che siamo tutti molto creativi nel modo con cui li usiamo.--Alexmar983 (msg) 22:35, 7 nov 2013 (CET)

@Nemo bis: proprio questa settimana mi è capitato questo: ho apposto un S di sezione in questa voce e poche ore dopo un utente l'ha tolto. Motivo? Ha visto che la sezione era "grande" e non ha guardato nella cronologia. Indipendentemente dalla contingenza In questo io vedo un pericolo per l'enciclopedia, che introducendo la data in {{S}} (e in {{S sezione}}). --Cpaolo79 (msg) 08:41, 8 nov 2013 (CET)

"Rischio" mi pare un'esagerazione. Certo ci sono le rimozioni (come anche le aggiunte) superficiali; il problema non è se l'utente si sia chiesto quando è stato messo o se abbia controllato la cronologia, è se si è posto delle domande e se ha riflettuto prima di decidere che era sbagliato. --Nemo 23:52, 8 nov 2013 (CET)

Proposta alternativa

E se invece aggiungessimo un parametro obbligatorio del tipo "Mancanze", "Motivazione" o simili, in cui debba essere specificata nel dettaglio cosa manca alla voce? E magari invece di chiamarlo stub/abbozzo potremmo chiamarlo Template:Da completare e gli "abbozzi" chiamarli "Voci non complete". In questa maniera di trasformerebbe in un template simile a Template:..., che ritengo al momento molto più importante del template:S in quanto indica con esattezza la sezione in cui mancano informazioni, mentre il template:S dice tutto e niente e non aiuta affatto ad ampliare le voci. In ogni caso la data la trovo superflua. --Daniele Pugliesi (msg) 10:28, 9 nov 2013 (CET)

Quindi vorresti scorrerti decine di migliaia di voci, analizzarle, trovare il problema e scriverlo nel campo "motivazione"? Non sarebbe più semplice aggiungere un parametro facoltativo ma consigliato? Io, tra l'altro, sarei favorevole. --Horcrux_九十二 17:47, 9 nov 2013 (CET)

È vero, abbiamo migliaia di template:S, ebbene, che ce ne facciamo?

Senza una motivazione, il template stub serve a ben poco. Adesso infatti succede che passa un utente, che probabilmente non sa nulla dell'argomento della voce, la guarda di sfuggita, vede che contiene poche righe e inserisce il template:S. Ma se uno vuole ampliare la voce per togliere il template:S deve andarsi a leggere tutta la voce, capire se può essere ampliata e in che modo. Ebbene, in questa maniera il template:S serve a bene poco e in tantissimi casi è fuori luogo oppure può succedere che la stessa voce da alcuni sia giudicata abbozzo e da altri no. Inserendo una breve motivazione, ad esempio "Mancano i cenni storici", "Bisogna approfondire la sezione...", "Mancano richiami a...", l'utente che passa per togliere il template:S legge l'avviso e inizia subito ad ampliare la voce nella maniera che è stata proposta, per cui grazie all'aggiunta "Motivazione" il template:S diventa un template "pratico" e preciso. --Daniele Pugliesi (msg) 17:59, 9 nov 2013 (CET)

Sono assolutamente d'accordo, ma lo stesso discorso è applicabile alla mancanza di fonti ecc., i cui annessi template anch'essi possiedono un campo di commento facoltativo (o si è in procinti di renderlo tale, per uniformità). --Horcrux_九十二 18:08, 9 nov 2013 (CET)

Se una voce è "senza fonti" o con poche fonti, si capisce subito cosa bisogna fare: appunto cercare le fonti che riguardano la voce e aggiungerle. E se uno che legge un template senza fonti vuole scendere nel particolare, piuttosto che inserire una motivazione generica del tipo "Mancano completamente le fonti", può prodigarsi a leggere la voce e inserire il template:cn dove necessario, così l'utente successivo leggendo i cn ad occhio vede le frasi dove servono le fonti. Con il template:S invece già ci partiamo da una generica definizione di "abbozzo" che è molto più soggettiva di un "senza fonte", in più non viene specificata quale parte della voce necessita di essere ampliata e quali informazioni bisogna aggiungere, per cui è l'avviso più vago in assoluto dopo il template:C, che è la vaghezza fatta persona ("da controllare" vuol dire tutto e niente). Quindi per il template:S e per il template:C e altri template "vaghi" una motivazione è indispensabile, altrimenti si rischia che ciascuno interpreta l'avviso a modo suo oppure che nessuno mette mano alla voce per rimuovere l'avviso perché non sa cosa fare. Mettere un template:S è troppo semplice, mentre ampliare una voce è spesso tutt'altro che semplice, quindi almeno chi mette l'avviso potrebbe sforzarsi un pochino per agevolare la vita a chi farà il grosso del lavoro. --Daniele Pugliesi (msg) 18:21, 9 nov 2013 (CET)

Non credo che il template S sia molto più vago di F. Ci sono alcuni punti di una voce che spesso hanno molto più bisogno di fonti di altri punti, specialmente quando l'avviso si riferisce solo ad alcune sezioni, e questo può saperlo in primis chi appone l'avviso (se lo fa con cognizione di causa), il quale può scegliere di rendere o meno cosciente il lettore di quali punti sono più carenti di fonti. Rendere obbligatorio il commento potrebbe essere controproducente in termini di tasso di avvisi inseriti e dannoso per chi, come me, tiene d'occhio le categorie dove finiscono le voci con errori di compilazione nei template di avviso. --Horcrux_九十二 18:41, 9 nov 2013 (CET)

Forse non mi sono spiegato: la possibilità di inserire il template:cn rende il template:F meno vago. Personalmente preferisco i cn ad una motivazione vaga nel template:F. Da questo punto di vista, accoppiando il template:F con il template:cn riusciamo ad avere delle informazioni precise sui punti della voce dove bisogna inserire le fonti. Invece in presenza del solo template:S non abbiamo nessuna informazione sugli argomenti che vanno ampliati. Finora mi sembra che la logica del template:F ha funzionato, nel senso che se per assurdo ci mettessimo di buona volontà tutti gli utenti per inserire le fonti in tutte le voci del template:F l'unica incognita sarebbe il tempo necessario a inserire tutte le fonti, visto il gran numero di voci senza fonti. Invece non si può fare lo stesso discorso per il template:S, in quanto prima bisogna verificare se realmente la voce è un abbozzo, poi bisogna capire cosa manca nella voce, come scriverlo, come organizzarla, ecc. In pratica il template:S non dice nulla, ti dice solo: "amplia la voce" e al malcapitato tocca andarsi a documentare sull'argomento, scegliere i contenuti, come organizzarli, ecc. In questo senso dico che è molto più importante per il template:S avere una motivazione o qualcosa che dia "significato" al template. --Daniele Pugliesi (msg) 18:54, 9 nov 2013 (CET)

Ok, resta il fatto che IMHO la situazione non è tanto grave da necessitare un parametro obbligatorio, per tutte le motivazioni suddette (elevati costi di inserimento e manutenzione, abbassamento della frequenza di inserimento del template). Attendiamo altri pareri e magari riapriamo la questione dopo il termine del sondaggio ;-) --Horcrux_九十二 19:21, 9 nov 2013 (CET)

Ok. --Daniele Pugliesi (msg) 19:55, 9 nov 2013 (CET)

[← Rientro] Favorevole al parametro commento facoltativo anche io, ma rimane sempre il problema che, fra i contrari alla mia proposta di datazione, parecchi non vogliono proprio parametri aggiuntivi, quindi anche questa proposta potrebbe essere cassata in pieno. Un parametro commento, comunque, potrebbe essere usato anche per inserire volontariamente la data, aiutando (parecchio) il lavoro sporco. --Gce (Il Vile Censore Mascarato 2013) 12:13, 10 nov 2013 (CET)

Template {{I}}

Mi piace l'idea castanea di una template per indicare che una voce sia incompleta, stub dovrebbe indicare che si tratta di una voce embrionale o su cui vi e' ben poco da dire, incompleta viceversa segnalerebbe che vi e' molto di piu' da scrivere ed effettivamente essere oggetto di festival di miglioramento, lavoro sporco e quant'altro.--Bramfab Discorriamo 09:47, 13 nov 2013 (CET)

Attenzione, meglio fare un ragionamento complessivo: abbiamo già C, Sezione vuota, S sezione... Io, ad es., spesso uso C e tmp:... (cioè Sezione vuota) per indicare mancanze e articolare una proposta di architettura della voce.

Dovremmo ripartire da capo, chiederci cosa ci serve, astraendo da quello che esiste. pequod76^talk 10:39, 13 nov 2013 (CET)

Non mi piace per niente l'idea di questo template è come quello stub ma molto più aleatorio, inoltre rischierebbe di stare su una voce eternamente, non sono forse tutte le voci di wp incomplete? cioè a meno che una voce non sia di qualità o da vetrina è molto probabile che manchino sezioni od altro inoltre si veicolerebbe il messaggio che le voci incomplete vanno migliorate ma le altre posso rimanere così --Limonadis (msg) 11:57, 13 nov 2013 (CET)

A parte il nome, sarebbe più o meno la stessa proposta che avevo avanzato più sopra sul Template:Da completare senza però il campo "motivazione", che secondo me è fondamentale per avere un template utile. Concordo con l'intervento di Limonadis e a questo punto ritorno sulla mia idea iniziale, cioè di abolire definitivamente il template:S, che non fa altro che complicarci la vita senza renderci in cambio alcun vantaggio concreto. --Daniele Pugliesi (msg) 12:14, 13 nov 2013 (CET)

Visto che trova interesse, provo ad articolare un po' meglio, dopodiché se ne potrà discutere - se lo si vorrà - nei tempi e nei luoghi opportuni. L'avviso S è in Ns0, quindi è rivolto prima di tutto al lettore (solo in subordine genera, come ogni avviso, categorie utili per il contributore, ma volte - si badi bene - ad arrivare alla rimozione dell'avviso). E cosa dice S al lettore? Sostanzialmente qualcosa del tipo: occhio che questa voce non è soltanto in eterno divenire come tutte le voci di Wikipedia, ma seriamente incompleta; potrebbero perciò mancare informazioni fondamentali, per cui se vuoi informazioni su questo tema è meglio che tu ti rivolga anche altrove. Ed è questo che potrebbe dire un ipotetico avviso I (giusto per completare il vocalismo), o da completare, o come le si vorrà chiamare - peraltro comodamente integrabile da tutti i campi - data, motivazione, argomento - che si riterrà utile prevedere. Ripeto: è solo un... abbozzo di idea, uno spunto: potrà fiorire come rimanere morto qua. --CastaÑa 00:43, 14 nov 2013 (CET)

Ma nella tua idea I sostituisce S, lo accompagna... cosa? :) IMHO già C, se ci decidessimo a ragionarci sopra e a renderlo fruibile (perché, come è stato detto, è il più aleatorio degli avvisi, dopo S) potrebbe essere inteso come una segnalazione di "non accuratezza" della voce. Io lo uso - credo - proprio come tu intendi I. Per questo lo uso in coppia con Sezione vuota (sezioni che spesso creo io stesso, proprio per prefigurare una struttura delle informazioni). C, nella mia testa, non segnala solo informazioni non accurate, segnala che la voce non è accurata. Infatti, una info controversa o è senza fonti (cn, dunque) o fonti ne ha (e allora P o altro genere di problema "articolato"). Una info con fonti in che senso può essere "non accurata"? Se diamo per buono questo uso "integrato" di C, abbiamo già il template da usare, attribuendogli, peraltro, la consistenza che ad oggi non ha (da controllare: sarebbe? poca accuratezza di info specifiche, quindi un avviso per l'intera voce è sbalestrato). Infatti Aiuto:Voci da controllare recita voci che contengono informazioni non accurate. Si può anche continuare ad usare C come lo usiamo oggi (controllo generico, avviso generico, allerta generico), ma va benissimo imho che C venga usato come intendi tu I (se ti ho compreso): *mancanza di informazioni fondamentali*. Io almeno lo uso così. Un abbozzo, invece, può anche accennare a tutte le informazioni fondamentali, ma le tratta appunto in nuce. pequod76^talk 01:15, 14 nov 2013 (CET)

Sostituirebbe S, laddove opportuno. Infatti lo suggerivo come elemento di una strada, che ho visto riscuotere un certo interesse, di progressivo abbandono di S, percepito da molti come legato a un'altra epoca di Wikipedia. Allo stesso modo anche C mi pare ormai poco utile, specie da quando abbiamo Organizzare; ha una funzione residuale come avviso unico in luogo di un elenco di avvisi più propri (P, W, F, CN, ecc.), ma mi pare ormai ridondante.--CastaÑa 01:34, 14 nov 2013 (CET)

Io uso il template C ad esempio nelle voci tecnico-scientifiche per segnalare un possibile errore nelle formule o nei valori forniti dalla voce. In altre parole, lo utilizzo quando penso che la voce potrebbe essere sbagliata in altri punti, ma non ne sono sicuro. Quindi per me il template C serve essenzialmente a richiamare l'attenzione di altri utenti e chiedere ai più esperti di controllare la voce. A tale proposito, mi sembra che en.wikipedia abbia un avviso specifico per chiedere l'intervento di un esperto su una voce, mentre it.wikipedia mi sembra che non ce l'abbia (confermate?).

Dunque per come la vedo io il template C serve a evidenziare che la voce contiene alcune informazioni sbagliate (o possibilmente sbagliate), mentre il template S dovrebbe servire a evidenziare che una voce manca di alcune informazioni importanti. Il punto è proprio questo: quali informazioni mancano? Proprio per questo chiedevo di inserire come parametro obbligatorio "Motivazione" in cui indicare cosa va inserito nella voce. Se poi lo vogliamo chiamare I o S, il template rimane sempre lo stesso: dire che una voce è "incompleta" o è un "abbozzo" è un'informazione poco significativa se non accompagnata da altre informazioni più specifiche. Inoltre i termini "abbozzo" e "incompleta" fanno riferimento al problema, mentre sarebbe meglio usare un nome che metta in evidenza l'azione che va compiuta su tali voci, ad esempio "Da completare" o "Da ampliare". In alternativa, possiamo usare il Template:Promemoria, che si inserisce nella pagina di discussione ed è molto meno invasivo e più preciso del template S. --Daniele Pugliesi (msg) 07:36, 14 nov 2013 (CET)

[a capo] Sono contento, il tenore della discussione mi pare sia quello giusto. Secondo me dovremmo ispirarci ad un sistema generico di rilevazione delle criticità. Stante un oggetto X, quali sono le criticità e i sistemi di allarme da utilizzare? Quindi partiamo dall'inizio.

1. ha senso categorizzare le bozze? Secondo me sì: l'elemento warning del tmp S in voce penso abbiamo capito da tempo che non serve a granché, per lo più il fatto di essere un abbozzo è autoevidente, soprattutto se intendiamo l'abbozzo nel senso di "prima redazione". L'utente Ciccio, appassionato della materia X, potrebbe voler indirizzarsi a queste "prime redazioni" per il proprio intervento. Sostanzialmente, se decade questo presupposto, decade tutta l'architettura di S. Che importi la precisione nella categorizzazione, proprio in vista di questo ipotetico utente che decida di aiutare il progetto lì dove esso è riuscito a produrre *solo* prime redazioni, è dimostrato dalla raffinatezza dell'albero di S, che quanto a raffinatezza è il secondo tra tutti (dopo quello di ns0) e il maggiore tra quelli di servizio. Proprio in relazione alla complessità gestionale che comporta S, eventuali sistemi alternativi che rispondano alla stessa esigenza e che siano più facili da gestire vanno valutati con attenzione. A naso io ritengo che abbiamo gli strumenti per servire le esigenze di questo ipotetico utente. Un primo strumento è l'EGO, ma l'EGO è "cieco", è robotico, quindi una sua prima traccia di lettura deve intendere l'abbozzo come voce breve, quindi convenzionalmente inferiore a n kb. Di qui l'esigenza di escludere dalla ricerca tutte quelle voci in cui la brevità non è un problema specifico. Di qui la proposta di {{permastub}}, un'etichetta certamente convenzionale e "soggettiva", ma non vedo dove stia il peccato. Quindi il punto di partenza - ha senso categorizzare le bozze? - si è trasformato in ci serve identificare stub e permastub, non importa con quale strumento (cat, EGO...): l'importante è individuare strumenti che costino poco. L'albero di S costa da matti (creazione manuale di cat, categorizzazione manuale delle stesse, raffinatezze come "icona stub" e altre amenità del genere). Inoltre l'albero, a fronte dei costi, ha dimostrato di funzionare male: un quarto del totale delle voci è indicato con S, ma organizziamo dei festival per toglierlo da dove risulta inadeguato. Il problema sta nel fatto che S viene inserito manualmente e tolto manualmente, quindi è un sistema cronicamente non aggiornato. Gli EGO restituiscono una foto aggiornatissima, ma bisogna sapere matematicamente che cosa si sta domandando: gli EGO ci chiedono di formalizzare la domanda e la domanda non può che essere inferiore a n kb?. Peraltro un EGO può essere prodotto attraverso domande più raffinate: "è inferiore a n kb? + è presente tmp:Permastub? + è presente un avviso C/Cn?".
2. Una voce può contenere specifiche informazioni "problematiche"? Quando si tratta di criticità puntuali, il tmp da usare deve essere puntuale, proporzionato. Abbiamo cn e chiarire. Quindi C va riformato o cmq vagliato (se lo si mantiene). Questo template va apposto all'inizio delle voci o sezioni che si ritiene contengano informazioni errate o non accurate (è il man di C). Se è vero che C è sproporzionato per criticità puntuali, esso può essere mantenuto solo a condizione di ritenere desiderabile un avviso "ultima spiaggia", cioè un warning generico (con parametro motivo valorizzato, ovviamente). Non mi pare che questa elasticità sia un danno. L'alternativa è creare una montagna di tmp di avviso, come fanno su enW: prima delle 4 milioni di voci me lo risparmierei. Elasticità: non a caso, la versione francese di C dice jeter un œil, "gettare un occhio". Poi qui ci si abbandona al dissolvi: articles qui présentent principalement des déficiences de forme de l’article (style, orthographe, typographie, etc.) ou qui suscitent des questions concernant leur teneur (intérêt de l’article, fiabilité des informations, neutralité, etc.). Decisamente troppa roba. Piuttosto che fare esempi, rubando campo ad altri avvisi, un man di C inteso come avviso generico di allarme dovrebbe dichiarare la sua genericità. C è l'avviso che un niubbo potrebbe voler inserire, perché ci vuole segnalare qualcosa. Idealmente può persino essere convertito in altri tmp o il suo succo spostato in talk per una discussione. C non ha una funzione warning per il lettore: messo in testa alla voce sostituisce indebitamente cn o chiarire o altri sistemi di segnalazione di criticità puntuali. Se un avviso di allarme generico non ci interessa, allora potrebbe interessarci un avviso analogo a quello proposto da Castagna, un avviso cioè che indica *mancanze* clamorose.
3. Mancanze clamorose: poniamo che si chiami {{I}}. In alcuni casi può essere usato contestualmente alla creazione di sezioni vuote (+{{...}}), se le mancanze clamorose sono relative a punti che meritano lo spazio di un paragrafo (come può essere il tema "migrazioni" per gli Indoeuropei, mettiamo). Se i "buchi" hanno dimensioni più modeste, non si profila l'esigenza di creare sezioni vuote.
4. Organizzare: questo tmp nasce per un taglio di analisi che prescinda completamente dal contenuto, cioè dal merito del tema trattato. La questione che si pone è "i materiali per esporre il tema sono ben formati?". L'intento divulgativo può fallire in tanti modi, ad es. per l'utilizzo di un linguaggio troppo tecnico, ma qualsiasi "penso e scrivo" fallisce senza una rielaborazione della brutta. Prima accumulo materiali, dati oggettivi, opinioni etc. (il "bambino" della creazione letteraria in Flaubert), poi, solo poi, posso provare a costruire secondo un progetto (la "piramide" in Flaubert). In un progetto wiki l'importanza di questo problema è evidente. (vedi qui, da frW).
5. Stante questo panorama, il tmp:Promemoria appare utile soprattutto per problemi "particolarmente incrostati". Un utilizzo di questo genere non è imho molto giustificato. Meglio un avviso direttamente in voce. WP questo è, un prodotto editoriale che mette in mostra i ponteggi per spingere il lettore a intervenire in prima persona. Già questo utilizzo mi pare più sensato: "quando queste voci saranno blu vanno aggiunte alle Voci correlate". Si tratta di un problema non immediatamente risolvibile, che "pende" da un altro fatto, cioè la creazione di alcune voci. Quindi un avviso (quale che sia la lettera scelta) direttamente in voce non fa che "sporcare" la voce, senza grande utilità. Un altro utilizzo sensato di Promemoria è il seguente: appuntare fonti (cartacee o online) da utilizzare a beneficio della voce. In sostanza Promemoria evita che con l'archiviazione della talk un appunto del genere vada sostanzialmente smarrito. Quindi è particolarmente importante per talk di voci importanti, talk cioè che crescono continuamente. Bisogna cmq riflettere sul rapporto tra Promemoria e altri avvisi, perché in tantissimi casi trovo utilizzi di Promemoria in cui ogni singolo punto annotato corrisponde a specifici avvisi in voce, che sarebbero stati più appropriati (esempio).
6. A tutto questo panorama, si aggiunge la vertente Monitoraggio. Qui c'è una discussione aperta sul tema "gestire la cat:stub tramite il monitoraggio". Ma più precisamente dovrebbe intitolarsi "gestire la bozzitudine tramite il monitoraggio". La prima conseguenza di una opzione del genere - mi sembra - è rendere inutile la creazione di tmp:Permastub.

So che questi temi ci allontanano dal ns0. D'altra parte, non discuterli significa patire in modo irriflesso le conseguenze di un sistema formato male. S ci fa certamente perdere tempo. E sembra che non ce ne accorgiamo. Vale quindi forse la pena di perdere tempo coscientemente, avendo almeno uno scopo, cioè quello di risparmiarlo in futuro, attraverso l'ideazione di sistemi di rilevazione delle criticità che costino meno degli attuali. pequod76^talk 12:54, 14 nov 2013 (CET)

Vedendo le ultime discussioni sul template:S (ma anche molte precedenti), si nota che dopo qualche intervento iniziale sul template:S la discussione si allarga in maniera paurosa: siamo partiti dall'aggiunta della data e siamo arrivati ad analizzare insieme una decina di template, tra avviso, promemoria e monitoraggio.

Perché allarghiamo così spesso la discussione?

Ovviamente perché le problematiche non sono solo associate al template:S, ma a tanti altri template di avviso.

Dunque a mio parere la cosa migliore da fare è cercare di mettere delle pezze adesso, in modo da utilizzare questi template nel migliore dei modi, e allo stesso tempo iniziare un dialogo con tutte le altre Wikipedie per trovare insieme una soluzione definitiva.

--Daniele Pugliesi (msg) 14:39, 14 nov 2013 (CET)

Quotando Daniele, vorrei anche ricordare che più di una volta la questione di un fantomatico template I è stata sottoposta al bar: addirittura delle volte si è arrivati anche a fare congetture strampalate solo per il gusto di completare la cinquina (A, E, I, O, U). Il tema è mettere o non mettere un parametro, il resto IMHO è OT. --Umberto NURS (msg) 15:03, 14 nov 2013 (CET)

Un dialogo con le altre wp? La vedo male. No. Non ne vale la pena. Magari qui è decisamente OT, ma non usciremo mai dal ginepraio finché faremo discussioni settoriali. Ci vuole un'analisi complessiva del tema "rilevazione e segnalazione delle criticità" (cioè: gli avvisi). Finché non faremo ciò, continueremo a "subire" decisioni prese 10 anni fa, che hanno avuto il merito di sgrossare l'infinita materia primigenia, ma che adesso meritano di essere vagliate e imho superate. Perché S e C sono avvisi aleatori? Perché facciamo solo discussioni settoriali, senza attaccare il problema complessivamente. Il tema era mettere o non mettere un parametro, il sondaggio già ha praticamente detto la sua e quindi ritorniamo al punto di partenza. pequod76^talk 16:27, 14 nov 2013 (CET)