Ciclo di vita di una guida #2 - Proposte di modifica

[HAL 9000]

A distanza di tempo dai task di Revisione Wiki #55 (e i collegati: #56, #57 e #58) sul ciclo di vita di una guida, e a seguito della prima revisione delle guide da quando è in vigore il nuovo sistema di categorie nascoste sulle guide da controllare, penso siano emerse delle criticità da correggere e siano possibili anche alcuni miglioramenti.

Gli obiettivi sono:

1. permettere il controllo di categoria mancante dalle guide (impossibile se una guida appartiene a una categoria nascosta);
2. facilitare la fase di revisione delle guide, riducendo il numero di stati di una guida e gli interventi manuali non essenziali;
3. ridurre il più possibile la necessità di interventi su guide che non saranno revisionate, soltanto per spostarle da un template/categoria a un altro;
4. facilitare la verifica per la stable in via di rilascio; e migliore gestione delle release volatili durante l'anno di rilascio, tenendo conto dei maggiori cambiamenti cui vanno incontro;
5. rendere il template "Versioni compatibili" il più possibile completo, così da non necessitare di altre informazioni o messaggi di avviso per segnalare lo stato della guida che si legge; anche a distanza di tempo dalla stesura della guida;
6. far sì che la ricerca del Wiki restituisca, per quanto possibile con le risorse disponibili, le sole guide più aggiornate; lasciando che le guide che necessitano di interventi (e non solo di un controllo) siano tracciabili da template e relative categorie.
7. documentare il tutto, in modo che sia facilmente comprensibile e in futuro eventualmente anche modificabile.

E le proposte per raggiungerli sono le seguenti:

1. rimozione di tutte le categorie nascoste di compatibilità (eccetto che "compatibili per tutte le versioni"), lasciando solo quelle per la non compatibilità, in modo da permettere il controllo di assenza di categorie dalle guide valide; le altre sono comunque da revisionare;
2. riduzione della revisione delle guide a un solo task, quello attuale sulle "guide da controllare", eliminando le altre categorie e i relativi avvisi; la revisione ordinaria avverrà "dietro le quinte", con un avviso solo per gli ultimi 2 anni prima che una guida diventi obsoleta o da adottare; aggiunta di altri tag di revisione, come l'attuale ONLY, per permettere maggiore flessibilità nella revisione di una guida, lasciando più tempo per le guide più complesse o integrate con altre;
3. gestione automatica di Stub, Guide da adottare e Guide adottate; estendendo la durata in cui una guida può essere lasciata in queste categorie, ma automatizzando il passaggio da una categoria all'altra; inclusione del template di Adozione collettiva nel template di "Guida da adottare", con sintassi simile a quella prevista per il template Autori per le guide collettive;
4. riduzione del tempo di validità di una verifica per release volatili, quali testing e unstable, in particolare durante l'anno di rilascio, in quanto l'informazione è meno rilevante quando non recente; e permettere la verifica per la stable che sta per essere rilasciata (solo nell'anno di rilascio), così da portarsi un po' avanti con la revisione delle guide; ciò si può fare in automatico, senza bisogno di modificare il template più di una volta, come già adesso, quando avverrà il rilascio; resterebbero escluse (ossia trattate come adesso), in automatico, le guide scritte solo per una versione volatile;
5. rendere deprecata la compatibilità per tutte le versione per le guide di nuova stesura, e sostituita con sintassi diversa, per le guide relative a repository (di cui si aggiornano in automatico le informazioni relative ai codename), guide teoriche e quelle relative a pacchetti di sistema e/o che non hanno subito modifiche sostanziali; a seguito di revisione delle guide che ne fanno uso, la vecchia compatibilità per tutte le versione sarà eliminata dal template "Versioni compatibili";
6. le guide da adottare, ma non adottate, saranno spostate nel namespace Old come quelle obsolete, e il progetto adozione guide diverrebbe complementare a quello di revisione, volto a dare evidenza e a favorire il recupero delle guide obsolete più meritevoli (fermo restando che tutte possono essere adottate); inoltre tutte le guide obsolete, alpiù estendendo di un paio di anni quelle relative ad hardware obsoleto, saranno spostate nel namespace Old al momento in cui divengono obsolete (sempre previa segnalazione sul forum);
7. documentazione di tutto quanto (sul wiki e in Lab per i vecchi thread), anche riguardo quello che avviene a livello di codice MediaWiki, per le parti più complesse.

I vari task non (ri)partiranno prima di febbraio, quindi spero che chiunque voglia intervenire con proprie proposte, abbia il tempo per farlo.

Buone feste e ci si risente al prossimo anno!

[HAL 9000]

Aggiornamento

Nel 2020 non mi sono fatto più vivo, ed è arrivato febbraio dell'anno dopo ancora. Vorrei però concludere le modifiche prima del rilascio di Debian 11 "Bullseye", una volta testate offline per via dei cambiamenti al portale, e se non ci saranno obiezioni o altri suggerimenti.

Tralascerò i punti 3, 5 e 6 del messaggio precedente, relativi alla gestione automatica dei template, così le modifiche saranno ridotte all'osso. Eventualmente sarà ripreso per il rilascio successivo. Non avendo partecipato molto per questo rilascio, non mi sembra il caso di spostare guide per il momento.

Queste categorie (nascoste) verrebbero eliminate:

Guide compatibili con stable
Guide non compatibili con stable (ma compatibili con oldstable)
Guide compatibili con testing
Guide compatibili con Sid

E anche questo template:

Template:Guida_da_controllare

Non ci saranno messaggi di avviso ("es. link Verificala per *") nel template. E non ci saranno template in alto se non per guide considerate "abbandonate", ossia effettivamente a rischio di divenire obsolete. La sola categoria nascosta sarà per le guide "Da controllare", gestita dal template "Versioni compatibili" in automatico e legata all'unico task che rimarrà per la revisione di una guida.

Sarà possibile scrivere nuove guide per Bullseye prima del rilascio, e si terrà conto dell'anno di salto di versione per testing/unstable, visto che indirettamente sono affette dal freeze.

E infine documenterò il tutto. Buona parte delle modifiche finiranno solo con il dividere il template "Versioni compatibili" in più parti, così da consentire più facilmente la modifica della parte grafica piuttosto che di quella logica o delle informazioni sull'utilizzo.

[marcomg]

Per me va benone! Purtroppo è da molto che non contribuisco al wiki (e ad essere sincero non è che abbia mai scritto così tante guide ).

[s3v]

Ciao HAL, bentornato

Aggiungo solo che, a mio parere, le categorie nascoste andrebbero definitivamente eliminate e pensare a qualcos'altro per contrassegnare le guide da controllare (magari i tag).
Il grosso problema che si portano dietro è che diventa impossibile trovare guide senza categoria valida a meno che siano prive *anche* del template "Versioni compatibili" (link).

Grazie del lavoro che fai.

[HAL 9000]

Grazie, e spero di essere più presente a partire da quest'anno.

Aggiungo solo che, a mio parere, le categorie nascoste andrebbero definitivamente eliminate e pensare a qualcos'altro per contrassegnare le guide da controllare (magari i tag).
Il grosso problema che si portano dietro è che diventa impossibile trovare guide senza categoria valida a meno che siano prive *anche* del template "Versioni compatibili" (link).

Questa era propria la ragione per la loro soppressione, mi sembra su tua segnalazione tempo fa.

Le uniche guide che continuerebbero ad averne, e solo per un periodo di 2 anni circa, sarebbero quelle già oggetto di revisione e quindi di controllo, tutte associate a un'unica categoria nascosta, l'unica rimanente.
Comunque si potrebbe invece utilizzare un template fittizio al suo posto, che non contiene nulla e incluso solo per sfruttare l'elenco generato dalla ricerca "Strumenti -> Puntano qui", così da eliminare anche l'ultima rimasta.

Non so come funzionano i tag, ma per me va bene qualsiasi strumento che consenta di generare un elenco in modo dinamico.

[s3v]

Le uniche guide che continuerebbero ad averne, e solo per un periodo di 2 anni circa, sarebbero quelle già oggetto di revisione e quindi di controllo, tutte associate a un'unica categoria nascosta, l'unica rimanente.

Però sono tante...

Comunque si potrebbe invece utilizzare un template fittizio al suo posto, che non contiene nulla e incluso solo per sfruttare l'elenco generato dalla ricerca "Strumenti -> Puntano qui", così da eliminare anche l'ultima rimasta.

Non so come funzionano i tag, ma per me va bene qualsiasi strumento che consenta di generare un elenco in modo dinamico.

Sia i template che i tag necessitano comunque di essere inseriti manualmente.
Si potrebbe scrivere un bot che si occupa di inserire autonomamente un template in cima alla pagina.

[HAL 9000]

Però sono tante...

Al momento sì, ma dopo le modifiche (e il rilascio) sarebbero queste 33: https://guide.debianizzati.org/index.ph ... con_stable
Che resterebbero nella categoria per soli 2 anni circa. Non sarà più usata per tutte quelle precedentemente "da controllare", come invece adesso, che passano da una all'altra.

E quindi ultimando le modifiche prima del rilascio, si potrebbe controllare e confermare la presenza di categorie per tutte le guide Wiki.

Sia i template che i tag necessitano comunque di essere inseriti manualmente.

Se invece optiamo per il template fittizio, questo sarebbe sempre aggiunto da "Versioni compatibili" in automatico per simulare una categoria nascosta, come per l'attuale "Guida da controllare" (senza però alcun contenuto reale). Per esempio qui si vede l'elenco delle guide "da controllare" e "abbandonate" (tranne quelle escluse dal template con tag ONLY), anche se aggiunto in automatico, senza bisogno di interventi manuali.

Si potrebbe scrivere un bot che si occupa di inserire autonomamente un template in cima alla pagina.

Per me va bene anche questo, ma non so come funzionano.

[s3v]

Ok, se le guide in categoria nascosta saranno poche, allora è tutto facilmente gestibile manualmente senza barcamenarsi troppo, si può anche evitare di ricorrere a template e/o tag e/o bot.
Una volta rimosse si può passare a sostituire l'ingestibile indice attuale con l'indice per categorie; cambiamento atteso da... dieci anni?

[HAL 9000]

Non c'è problema, tanto più che il template gestisce comunque (pur senza categorie nascoste) qualche centinaia di guide, e il numero potrebbe crescere più avanti (con quelle "compatibili per tutte le versioni" al momento le uniche non gestite).
Ed eliminando le categorie nascoste, si potranno anche permettere altre ricerche per versione come prima, anche in un secondo momento.
Giusto il tempo, probabilmente arriverà questo fine settimana, di verificare che tutto funzioni offline.

L'importante è riattivare il controllo di categorie, eliminando tutte le categorie nascoste a questo punto, e liberarsi dell'odiatissimo Indice Guide. Finalmente!

[HAL 9000]

Le modifiche offline sono già state apportate, devo solo fare gli ultimi controlli sui casi più complessi prima di renderle effettive sul nostro Wiki.

Le novità, rese possibili grazie agli aggiornamenti di MediaWiki (e quindi nemmeno pensate inizialmente), sono:
- una migliore e più robusta gestione degli anni di revisione, sfruttando la manipolazione delle stringhe (prima non possibile perché le funzioni non erano incluse nell'estensione ParserFunctions), per "Testing_20XX" e "Unstable_20XX", così che sia sempre in automatico senza più bisogno di lunghi elenchi per ogni singolo caso;
- l'aggiornamento automatico e totale del template "Versioni compatibili" tramite il solo template Codename a ogni cambio di versione, senza dover intervenire anche su un secondo template intermedio come ora;
- il tracciamento della compatibilità per tutte le versioni con anno di ultima revisione, così da poter rimuovere anche la categoria nascosta "per tutte le versioni di Debian" successivamente, l'ultima rimasta (di cui mi ero scordato); sto pensando anche a delle varianti più flessibili, ma tanto non avranno effetti visibili prima della revisione manuale di queste guide.

Le uniche categorie automatiche (non nascoste) rimaste sono quelle che segnalano errori con l'uso dei template, che hanno una priorità più elevata rispetto al controllo di categorie e che comunque vengono tolte in automatico quando si risolvono gli errori (riabilitando il controllo di categoria mancante).

[marcomg]

Grazie per tutto quello che stai facendo

[HAL 9000]

Le modifiche sono finalmente state apportate e documentate, sia con commenti che in apposite pagine.

--- --- ---

Per chi lo usa

Non cambia nulla.

La sintassi di {{Versioni compatibili|...}} è rimasta invariata, se non che è possibile anche usare "bullseye" per portarsi avanti con il prossimo rilascio (e più in generale sarà possibile in automatico all'avvicinarsi di ogni rilascio), che si possono usare maiuscole o minuscole indifferentemente per i parametri (il che consente anche di mostrare in minuscolo il codename come è effettivamente da utilizzare) ed è gestito meglio l'uso di release "volatili" come testing/sid durante l'anno di un nuovo rilascio.

--- --- ---

Cambiamenti "dietro le quinte"

Ora vi è la quasi totale separazione tra logica, divisa in più sottotemplate in base alle funzioni svolte per il tracciamento/segnalazione delle guide, e parti grafiche del template, così che si possa modificarne una parte senza dover conoscere l'altra e viceversa.
Ci sarà un solo template da aggiornare a ogni rilascio (con un semplice copia-incolla e 3 semplici campi da compilare), e a breve tornerà operativo anche il controllo di categoria mancante.

Vi sarà un unico processo di revisione, invece dei tre attuali, "dietro le quinte" ma aperto a tutti, per la verifica delle guide, che sarà molto più flessibile e facile da modificare (anche in base alle nostre capacità effettive), grazie anche a dei "flag di revisione" ignorabili da chi non partecipa (tipo il già esistente "ONLY" per comunicare la non compatibilità per versioni più recenti) e altre idee che mi sono venute, ma che saranno da discutere.

Verrà mostrato un messaggio di avviso soltanto quando una guida è a rischio di diventare obsoleta, così da garantire la massima visibilità, in aggiunta alla segnalazione in apposita discussione sul forum come avviene già adesso.


Categorie nascoste - ricerca per categoria mancante

Tutte queste pagine (categorie nascoste, template non più usati) sono diventate da cancellare come conseguenza di queste modifiche:

https://guide.debianizzati.org/index.ph ... li_con_Sid
https://guide.debianizzati.org/index.ph ... n_recenti)
https://guide.debianizzati.org/index.ph ... on_testing
https://guide.debianizzati.org/index.ph ... n_recenti)
https://guide.debianizzati.org/index.ph ... con_stable
https://guide.debianizzati.org/index.ph ... con_stable
https://guide.debianizzati.org/index.ph ... ontrollare
https://guide.debianizzati.org/index.ph ... ontrollare
https://guide.debianizzati.org/index.ph ... ili_elenco

(EDIT: è già stato fatto, non esistono più.)

Le categorie nascoste rimaste riguardano quelle relative a errori da correggere nei template, EDIT:e per cui si è interessati alla "non appartenenza" di una guida (quindi si vuole poter accorgersi subito che una guida vi è stata associata), e il cui numero quindi sarà estremamente ridotto, così da non ostacolare il controllo di categoria mancante in alcun modo. Oppure quelle che necessitano della maggior visibilità possibile, come per le guide abbandonate, per cui la categoria eventualmente potrebbe essere eliminata una volta spostata in Old in ogni caso.


Guide contrassegnate come "compatibili per tutte le versioni"

Le uniche guide rimaste da tracciare sono quelle contrassegnate come "compatibili per tutte le versioni". Per queste ho provato a identificare tutti i casi per cui possa avere senso questa forma e anzi tornarci utile, e come garantire comunque la massima trasparenza a chi le legge, fornendo a loro più informazioni possibili circa il loro stato.
Per queste comunque si discuterà prima in discussione a parte per come implementare il tutto al meglio per il prossimo processo di revisione. Al momento per retrocompatibilità nemmeno per quelle cambia nulla, ma la relativa categoria nascosta resta in funzione, fintanto che questo task non sarà concluso, e poi anch'essa non sarà più necessaria e sarà da cancellare.

[marcomg]

Ottimo lavoro! Ho proceduto alla cancellazione Poi cerco di studiarmi le modifiche

[HAL 9000]

Grazie, che tempismo!

Ho notato degli errori minori con template Codename che succedono solo nell'uso all'interno di link, che prima non c'erano, e che non avevo minimamente notato con le mie verifiche offline, anche se erano lì in bella mostra...
È possibile che siano causati dalla categoria. A questo punto elimino anche quella e via. (EDIT: fatto.)

EDIT: E c'è da sistemare il controllo di versioni non supportate per guide scritte unicamente per release volatili (testing/sid). (EDIT: fatto.)

---

Aggiornamento del giorno dopo:

Tutto dovrebbe essere a posto adesso, ed è stato aggiunto anche il supporto per sarge, anche se probabilmente sarà da rivedere la loro permanenza nel namespace principale più avanti: si tratta di guide già da cancellare o per cui ce ne sono di più aggiornate già disponibili.

La categoria nascosta Guide_che_utilizzano_il_template_Codename è da eliminare, in quanto non più utilizzata. (EDIT: è stato fatto.)
Di categorie nascoste ne restano solo 3, e più avanti ce ne saranno solo 2: 1 per gli errori con il template (che dovrebbe restare sempre vuota e quindi non creare problemi), e l'altra per quelle abbandonate, che hanno una priorità più elevata rispetto al controllo di categorie e facilita l'individuazione delle guide (rispetto a "Puntano qui").

Queste attualmente le guide senza categorie: ce ne sono 4, se non si contano quelle speciali. (EDIT: sistemate, ora hanno categoria.)

Mancano solo quelle (eventuali) "compatibili per tutte le versioni", ma saranno verificate prossimamente.

[HAL 9000]

Riprendendo il punto 5 del messaggio iniziale, e collegando questo task a quello #53 di Revisione Wiki in corso, questo è quello che avrei in mente per le guide "compatibili per tutte le versioni", le uniche ancora non tracciate in automatico (e per cui sarebbe necessario sempre andare a controllarle una ad una, in futuro anche senza la categoria nascosta attuale).

Questa parte può comunque tranquillamente attendere il rilascio di Debian 11 (bullseye), quando comincerei il controllo delle guide. Per implementarla si farebbe uso di due template di supporto, attualmente inutilizzati, e opportunamente modificati e configurati, tenendo conto di eventuali critiche o suggerimenti.

La mia prima proposta è di lasciare documentata soltanto la forma "con parametri" (es: {{Versioni compatibili|bullseye}}), in modo che chi scrive nuove guide sia portato a usare direttamente quella. E, una volta revisionate le guide attualmente "per tutte le versioni", rimuovere la forma "senza parametri".

La seconda proposta prevede di usare la forma "per tutte le versioni" (con un'altra sintassi) quando ci si occupa della revisione di una guida (documentandola soltanto lì), garantendo che la stabilità della guida sia accertata in due momenti distinti. E di dividere tali guide, seguendo quelle che comunque erano informalmente le "linee guida" già da diversi anni, tra:
1- quelle tenute aggiornate dal template Codename (quelle relative a repository, in cui ci si limita ad aggiornare l'associazione tra suite oldstable/stable/testing con i relativi codename a ogni rilascio); queste comunicheranno che sono aggiornate in automatico, e anche la versione per cui sono state aggiornate (così da coprire anche il caso di eventuale nostro ritardo di aggiornamento);
2- quelle relative a software di sistema e le cui funzionalità in genere non cambiano (bash, apt, ecc...), e per cui sarebbe solo una perdita di tempo ricontrollare come le altre; il vantaggio è che se sappiamo che per esempio c'è una modifica a un pacchetto di sistema che ne altera la compatibilità con versioni successive, si potrebbe cambiare la compatibilità a tutte le guide che lo usano agendo su un'unica pagina;
3- pacchetti che ricevono solo aggiornamenti di sicurezza, ma che per il resto non sono cambiati; come sopra e inoltre si può comunicare il pacchetto e la versione che determina la compatibilità (e pure verificarla in modo automatizzato a ogni passaggio di versione);
4- (categoria residuale) guide teoriche o che si ritiene comunque stabili; queste saranno tracciate come per la forma con parametri, ma si può pensare a un controllo meno frequente, basato sull'anno di ultima revisione.

Fermo restando che:
1- si deve poterne ignorare l'esistenza, sia in fase di stesura sia di revisione di una guida, per cui la nuova sintassi resta una mera possibilità;
2- si potrà sempre usare il template Versioni compatibili per aggiungere semplicemente la versione per cui si è verificata la guida, anche nel caso che abbia compatibilità "per tutte le versioni"; e avrà comunque sempre almeno una versione, così da renderlo esplicito e agevolarne il cambiamento;
3- ogni guida diventa "normale", semplicemente rimuovendo la prima stringa speciale dal template "Versioni compatibili", in caso si voglia alterare la compatibilità di una singola guida;
4- la compatibilità di tutte le guide "compatibili per tutte le versioni" può essere alterata in blocco e con la granularità desiderata (per pacchetto o per pacchetto e versione; quest'ultima non è ancora implementata nel nostro Wiki), agendo soltanto su una pagina.

Spero che così facendo si possa, senza aumentare la complessità di chi scrive nuove guide o le revisiona, sfruttare la possibilità di una compatibilità "per tutte le versioni", che torna davvero utile per evitare inutile lavoro a ogni nuovo rilascio, e allo stesso tempo tenere tracciate tutte le guide.

Gli strumenti automatici di verifica che si possono implementare offline, in un secondo momento potrebbero poi essere usati anche su altre guide che seguono convenzioni particolari, per esempio per verificare se sono ancora presenti per l'attuale stable i pacchetti di "elenco programmi senza interfaccia grafica", "Tabella Software", quelli elencati dopo un comando di installazione, ecc... così da individuare facilmente cambiamenti anche sul resto del Wiki, in maniera analoga a come si era effettuato approssimativamente il controllo di broken link sugli URL non più raggiungibili.