Come costruire un sito per la storia pubblica delle decisioni

Cos'è (e cosa non è) una public decision history

Una public decision history è un registro curato di decisioni significative sul prodotto—pubblicato sul tuo sito—affinché le persone possano capire cosa hai scelto, quando lo hai scelto e perché aveva senso in quel momento.

Pensala come lo “strato delle motivazioni” che sta accanto alla documentazione e al changelog. Non è un testo promozionale e non è la trascrizione di una riunione. È un riferimento pratico che riduce le speculazioni, velocizza l’allineamento e impedisce che gli stessi dibattiti ricomincino ogni pochi mesi.

Cosa è

Una buona public decision history:

• Cattura decisioni che influenzano utenti o contributori (feature, deprecazioni, cambi di modello di pricing, cambiamenti di postura sulla sicurezza, principi API, convenzioni UX)
• Spiega contesto e vincoli (bisogni dei clienti, requisiti normativi, limiti tecnici, tempistiche)
• Indica le opzioni considerate e i trade-off che avete accettato
• Rende facile indicare un URL stabile quando qualcuno chiede “Perché lo avete fatto così?”

Cosa non è

Per allineare le aspettative, sii esplicito su ciò che non stai pubblicando:

• Non ogni conversazione interna: è un registro di esiti, non la riproduzione di Slack, chiamate o thread di dibattito.
• Non una promessa di lavoro futuro: registra decisioni prese, non una roadmap.
• Non un luogo per dettagli sensibili: puoi spiegare le motivazioni senza esporre informazioni private sui clienti, vulnerabilità o metriche interne.

Perché pubblicarla (obiettivi pratici)

La maggior parte dei team pubblica una public decision history per:

• Costruire fiducia mostrando ragionamenti coerenti
• Velocizzare onboarding per clienti, partner e nuovi colleghi
• Ridurre discussioni ripetute (“Abbiamo già deciso questo”) collegando a una voce canonica

Per chi è

I tuoi lettori target includono solitamente:

• Clienti che valutano l’allineamento e la direzione a lungo termine
• Partner che si integrano con il tuo prodotto
• Contributori (open-source o community) che si allineano su standard
• Stampa e analisti in cerca di fonti primarie

Se riesci a nominare il lettore primario, le voci saranno più brevi, chiare e utili.

Scopo: quali decisioni pubblicare

Una public decision history funziona meglio quando i lettori possono prevedere cosa troveranno. Se pubblichi tutto, il sito diventa rumoroso; se pubblichi solo i “successi”, sembra marketing. Definisci uno scopo coerente, utile e sostenibile per il tuo team.

Inizia nominando i tipi di decisione

Elenca le categorie che vuoi catturare e scrivi una regola semplice per ciascuna. Tipi comuni includono:

• Feature di prodotto: perché hai costruito (o rimosso) una feature e quale problema risolve
• Pricing e packaging: cambi di piani, limiti, trial, politica sugli sconti
• Sicurezza e privacy: miglioramenti significativi, trade-off e implicazioni per i clienti
• UX e design: cambiamenti significativi nelle interazioni, decisioni di accessibilità, modifiche di navigazione

Un buon test: se un cliente potrebbe chiedere “perché l'avete fatto?”, probabilmente appartiene al sito.

Scegli un intervallo temporale che puoi mantenere

Decidi se pubblicare decisioni:

• Dal giorno uno (ideale per prodotti nuovi)
• A partire da un traguardo specifico (es., “v2.0 e successivi”)
• Solo per release importanti (un punto di partenza pragmatico)

Se stai riempiendo la storia a ritroso, scegli un cutoff chiaro e dillo in una nota introduttiva. È meglio essere espliciti che sembrare incompleti.

Scegli il giusto livello di dettaglio

Non tutte le decisioni richiedono una lunga narrazione. Usa due livelli:

• Voci brevi: un riassunto di 3–6 frasi con link a documenti o release correlati
• Approfondimenti: per decisioni ad alto impatto (pricing, breaking changes, trust/safety)

La coerenza conta più della lunghezza; i lettori vogliono un formato affidabile.

Definisci cosa resta privato

Scrivi le esclusioni in anticipo per evitare dibattiti caso per caso:

• Dettagli sensibili per la sicurezza (path di attacco, controlli interni)
• Dati personali (clienti, dipendenti, appunti di interviste)
• Specifiche di contratti e negoziazioni
• Metriche interne che potrebbero danneggiare utenti o competitività se usate in modo improprio

Quando devi omettere dettagli, pubblica la decisione con una breve nota “Cosa possiamo condividere” in modo che la voce resti onesta e completa.

Template della voce di decisione e campi richiesti

Una public decision history funziona solo se ogni voce risponde alle stesse domande fondamentali. I lettori non dovrebbero dover indovinare quale problema stavi risolvendo, cosa hai considerato o cosa è cambiato dopo la scelta.

Il template principale (Contesto → Opzioni → Decisione → Rationale → Impatto)

Usa una struttura coerente per ogni pagina di decisione. Un flusso ripetibile mantiene gli autori disciplinati e facilita la scansione:

• Contesto: cosa ha innescato la decisione? Includi vincoli (tempo, budget, policy), bisogni degli utenti e background rilevante.
• Opzioni: le reali alternative valutate (di solito 2–4). Nota brevemente i trade-off.
• Decisione: l'opzione scelta, detta chiaramente.
• Rationale: perché questa opzione ha vinto. Includi fattori chiave e assunzioni.
• Impatto: cosa è cambiato dopo la decisione—comportamento visibile all'utente, processi interni, deprecazioni o nuovi rischi.

Metadata richiesto (perché le voci siano ordinabili e affidabili)

Aggiungi un piccolo blocco “header” di campi in cima a ogni voce:

• Date (e opzionalmente “decision effective date” se diversa)
• Status: proposed / accepted / reversed (o superseded)
• Owners: persona/team responsabile (non necessariamente l'autore)
• Tags: area prodotto, segmento cliente, piattaforma, ecc.
• Audience (opzionale): chi dovrebbe interessarsi—clienti, partner, utenti interni

Questi metadata alimentano filtri e timeline più avanti e segnalano quanto la decisione sia definitiva.

Collega la decisione a ciò che le persone possono verificare

Una decisione è più credibile quando i lettori possono risalire ai risultati e agli artefatti:

• Link alla voce correlata del changelog (es., /changelog/2025-04-18-search-update)
• Link alla documentazione di supporto (es., /docs/search/indexing)
• Link alla release o alla pagina di versione (es., /releases/1.12)

Pianifica reversal e decisioni “superseded”

I reversal sono normali—pubblicali chiaramente. Quando una decisione viene sostituita:

• Cambia Status in reversed o superseded
• Aggiungi Superseded by collegando alla voce più recente (es., /decisions/014-new-rate-limits)
• Aggiungi un breve paragrafo Perché è cambiato (nuovi dati, costi imprevisti, cambiamento di policy)

Questo mantiene onesta la timeline delle decisioni senza riscrivere la storia.

Architettura dell'informazione e navigazione

Una public decision history funziona solo se i lettori possono rispondere rapidamente a due domande: “Cosa è successo?” e “Dove trovo la decisione che spiega questo?” La tua architettura dell'informazione dovrebbe rendere la navigazione ovvia, anche per chi non conosce il prodotto.

Scegli una navigazione primaria che corrisponda al modo in cui le persone cercano

La maggior parte dei team fa meglio con 3–4 voci principali che coprono diversi stili di lettura:

• Timeline — vista cronologica per chi segue la storia dall'inizio alla fine.
• Topics/Tags — modo per saltare a temi come “Pricing”, “API”, “Accessibility” o “Security”.
• Key Decisions — elenco curato delle decisioni che si citano spesso (e che gli estranei chiedono).
• About — cos'è questo sito, cosa include/esclude e come interpretare le voci.

Mantieni la navigazione principale stabile. Se aggiungi nuove pagine (es., “Methodology”), mettile sotto About invece di espandere il menu principale.

Decidi pattern URL (e non cambiarli dopo)

URL chiare rendono il sito più facile da condividere, citare e cercare. Un pattern semplice che funziona bene è:

• /decisions/2025-03-feature-flags

Usa le date per ordinare e uno slug leggibile. Se prevedi molte decisioni al mese, includi anche il giorno (/decisions/2025-03-18-feature-flags). Evita di rinominare gli URL dopo la pubblicazione; se necessario, aggiungi redirect.

Aggiungi una pagina “Start here”

Una breve guida riduce la confusione e impedisce ai lettori di fraintendere bozze o registri parziali. Crea una pagina prominente come /start-here (e collegala nell'header e in About) che spiega:

• cosa conta come “decisione” in questo sito
• come usare tag, ricerca e filtri
• cosa significano gli stati (es., Proposed, Accepted, Reversed)
• come interpretare aggiornamenti e revisioni

Progetta per la scansione prima e la profondità poi

La maggior parte dei visitatori scansiona. Struttura ogni pagina di decisione in modo che l’essenziale sia visibile subito:

• un paragrafo di sunto (cosa è cambiato e perché)
• metadata chiave in alto (data, stato, owner)
• la rationale dettagliata sotto, con sezioni che possono essere espanse/compresse

Nelle liste (Timeline, Topics), mostra anteprime tipo “card” con titolo, data e 1–2 righe di sommario. Questo permette la navigazione rapida senza aprire ogni voce, mantenendo il dettaglio a portata di click.

Modello dati: come archiviare le decisioni

Una public decision history è utile quanto la sua struttura sottostante. Se i lettori non possono collegare una decisione, filtrarla o capire a cosa si riferisce, il sito diventa presto un mucchio di post.

Scegli lo storage più semplice che si adatta al tuo team

Hai generalmente tre opzioni:

• File Markdown in un repo: ottimo per versioning, revisioni e basso costo. Funziona bene con static site generator e workflow basati su Git.
• Voci in CMS: più facile per editor non tecnici e con bozza/approvazione integrata, ma controlla URL ed esportazioni.
• Record in DB (app personalizzata): ideale per relazioni complesse e analytics, ma richiede più sforzo per costruire e mantenere.

Parti con Markdown o un CMS a meno che tu non abbia già bisogno di relazioni avanzate (es., molti-to-molti tra prodotti, release e segmenti cliente).

Usa un ID stabile per evitare link rotti

Tratta ogni decisione come un record permanente. Assegna un decision ID stabile che non cambia, anche se il titolo cambia.

Esempi di formato:

• DEC-00127
• PDH-2025-04-15-analytics-export

Usa l'ID nell'URL (o come parte) così puoi rinominare pagine senza rompere i link da ticket di supporto, docs o blog post.

Modella campi che abilitano filtri e navigazione

Anche se non esponi tutti i campi pubblicamente, definiscili in anticipo per costruire filtri successivi. Campi comuni includono:

• Product area (es., Billing, Reporting)
• Customer segment (es., SMB, Enterprise)
• Status (Proposed, Decided, Revisited)
• Release (versione, data, o link a /changelog)
• Decision date e effective date
• Tags (privacy, pricing, performance)

Pianifica dove archiviare gli allegati

Decidi dove vivono diagrammi, screenshot e PDF:

• Mantieni immagini leggere vicino alla voce (es., una cartella /assets/decisions/DEC-00127/).
• Per PDF o file più grandi, usa un percorso file stabile e nominali con l'ID della decisione.

Qualunque scelta, rendi prevedibili gli URL degli allegati in modo che restino validi col tempo.

Scelte tecniche: sito statico, CMS o app personalizzata

Il tooling dovrebbe corrispondere a due cose: quanto spesso pubblichi decisioni e quanto esperienza lettore vuoi offrire (ricerca, filtri, relazioni). La maggior parte dei team inizia semplice e passa a qualcosa di più complesso se l'archivio cresce.

Opzione 1: sito statico (veloce, poca manutenzione)

Un static site generator (per es., uno stile docs) trasforma file Markdown in un sito veloce. È di solito il modo più semplice per lanciare una public decision history.

Funziona bene quando:

• Pubblichi decisioni occasionalmente o con cadenza prevedibile
• I filtri necessari sono basici (area prodotto, data, stato)
• Vuoi basso onere operativo (niente server, meno parti in movimento)

I siti statici si prestano al paradigma “decisioni come codice”: ogni voce è un file Markdown in un repository, revisionato tramite pull request. Abbinalo a un provider di ricerca ospitato se vuoi ricerca full-text di qualità senza costruirla.

Opzione 2: Git-based Markdown vs headless CMS

Git-based Markdown è ottimo se i contributori sono a loro agio con PR e vuoi una traccia di audit chiara. Revisioni, approvazioni e storia sono già integrate.

Un headless CMS è migliore se molti autori sono non tecnici o hai bisogno di campi strutturati obbligatori in un form (tipo decision type, impact level, tags). Pubblicherai comunque spesso su un sito statico, ma l'editing avviene nel CMS.

Opzione 3: app personalizzata (filtri avanzati e relazioni)

Un'app personalizzata ha senso quando ti servono filtri ricchi (facet multi-selezione, query complesse), cross-linking (decisioni ↔ release ↔ docs) e viste personalizzate. Lo svantaggio è l'impegno continuo di ingegneria e sicurezza.

Se vuoi i vantaggi di un'app senza una lunga build, un workflow di tipo “vibe-coding” può essere una via di mezzo pratica: descrivi il data model (decision entries, tags, status, supersedes links), le pagine (Timeline, Topics, Key Decisions) e l'admin workflow, poi itera rapidamente.

Ad esempio, Koder.ai può aiutare i team a mettere in piedi un sito di decision-history o una app leggera da un processo di pianificazione e build basato su chat—usando React sul web, servizi Go e PostgreSQL sotto—mantenendo comunque un codebase esportabile e URL prevedibili. Questo è utile se vuoi filtri, ricerca, anteprime e publishing con ruoli senza rifare tutta la piattaforma interna.

Ricerca e ambienti di preview

Per la ricerca, scegli una di queste opzioni:

• Ricerca integrata del sito (veloce da impostare, limitata)
• Ricerca ospitata (migliore rilevanza e filtraggio)
• Ricerca server-side (massimo controllo, maggiore manutenzione)

Qualunque strada prendi, configura build di anteprima così i revisori possono vedere una voce come apparirà prima della pubblicazione. Un semplice link “preview” per ogni bozza riduce rifacimenti e mantiene la governance leggera.

Ricerca, filtri ed esperienza lettore

Una public decision history è utile solo se le persone trovano velocemente la decisione che gli interessa—e la capiscono senza leggere tutto. Considera ricerca e navigazione come funzionalità di prodotto, non decorazioni.

Ricerca full-text che capisce l'intento

Inizia con ricerca full-text su titoli, sommari e campi chiave come “Decision”, “Status” e “Rationale”. Le persone raramente conoscono la tua terminologia interna, quindi la ricerca dovrebbe tollerare match parziali e sinonimi.

Affianca la ricerca a filtri per restringere rapidamente i risultati:

• Tag (es., “pricing”, “API”, “privacy”)
• Status (proposed, accepted, reversed, deprecated)
• Intervallo di date (quarter, year, custom)
• Area/owner (team, superficie prodotto, regione)

Rendi i filtri visibili su desktop e facili da aprire/chiudere su mobile. Mostra i filtri attivi come “chip” rimovibili e includi sempre un “Clear all” con un click.

Cross-linking per contesto, non confusione

Molti lettori arrivano da un changelog, un ticket di supporto o un thread social. Aiutali a costruire contesto collegando le decisioni a:

• Decisioni correlate (dipendenze, alternative, “supersedes/superseded by”)
• Esiti (metriche, learnings, azioni di follow-up)
• Documenti di supporto (release notes, pagine di policy, FAQ)

Mantieni i link mirati: uno o due elementi “Related” sono meglio di una lista lunga. Se le tue voci includono un ID univoco, permetti la ricerca per quell'ID e mostrala vicino al titolo per il riferimento.

“Cosa è cambiato dalla mia ultima visita”

Aggiungi una vista Recent che evidenzia decisioni nuove o aggiornate. Due opzioni pratiche:

• Una pagina /decisions/recent ordinata per data di aggiornamento
• Un feed RSS/Atom per aggiornamenti (utile per giornalisti e partner)

Se supporti account utente, puoi anche mostrare “since last visit” basato su timestamp, ma una semplice lista recenti offre già gran parte del valore.

Accessibilità e leggibilità

Usa una struttura di heading chiara (H2/H3), contrasto colori elevato e font/sizes leggibili. Assicurati che la navigazione da tastiera funzioni per ricerca, filtri e paginazione, e fornisci stati di focus visibili. Mantieni i sommari brevi, usa sezioni scansionabili ed evita muri di testo così i lettori possono afferrare la decisione in meno di un minuto.

Workflow di pubblicazione e governance

Una public decision history resta utile solo se i lettori si fidano: che le voci siano complete, coerenti e scritte con cura. Non ti serve una burocrazia pesante, ma serve proprietà chiara e un percorso ripetibile da “bozza” a “pubblicato”.

Definisci i ruoli (anche se una persona ne copre due)

Stabilisci chi fa cosa per ogni voce:

• Author: scrive la decisione, spiega il contesto, collega il materiale di supporto e propone la formulazione finale.
• Reviewer: verifica chiarezza e completezza, mette in discussione assunzioni e conferma link e riferimenti.
• Approver: valida che la decisione sia reale, attuale e allineata con le approvazioni interne (es., product leadership, security, legal).
• Publisher: assicura che la voce rispetti lo standard di pubblicazione, applica tag/stato e pubblica il sito.

Mantieni questi ruoli visibili in ogni voce (es., “Author / Reviewer / Approver”) così il processo è trasparente.

Usa una checklist leggera pre-publish

Una breve checklist previene la maggior parte dei problemi di qualità senza rallentare:

• Chiarezza: un non esperto può riassumere la decisione dopo una lettura?
• Link: ci sono link a documenti, ticket, ricerche o release rilevanti?
• Info sensibili: rivela dati cliente, dettagli di sicurezza, termini contrattuali o piani interni?
• Tono: è neutro e fattuale (niente colpe o sarcasmo), e spiega i trade-off in modo equo?

Se crei template, incorpora questa checklist direttamente nella bozza.

Regole per le modifiche: correggi senza riscrivere la storia

Le decisioni sono registri storici. Quando qualcosa va corretto, preferisci cambiamenti additivi:

• Fix di typo/formato possono essere silenti.
• Per correzioni fattuali, aggiungi una breve nota “Update” con la data e cosa è cambiato.
• Se la decisione cambia, pubblica una nuova voce che collega la precedente (“Supersedes …”) invece di modificare la vecchia conclusione.

Pubblica gli standard di scrittura

Aggiungi una breve pagina guida come /docs/decision-writing che spiega:

• cosa qualifica come decisione pubblicabile,
• struttura e vocabolario attesi,
• come trattare incertezza e trade-off,
• la policy di modifica sopra.

Questo mantiene la voce e il tono coerenti man mano che più persone contribuiscono e riduce il carico dei revisori.

Privacy, sicurezza e considerazioni legali

Pubblicare le motivazioni delle decisioni costruisce fiducia, ma aumenta anche il rischio di condividere qualcosa che non dovresti. Tratta la public decision history come un artefatto curato—not un'estrazione grezza di note interne.

Redazione: decidi cosa non va mai pubblicato

Inizia con un set di regole di redazione e applicale in modo coerente. Elementi comuni da rimuovere sempre includono dati personali (nomi, email, trascrizioni di chiamate), dettagli privati dei clienti (specifiche account, termini di contratto, date di rinnovo) e tutto ciò che potrebbe facilitare abusi (risultati di sicurezza, diagrammi di sistema con componenti sensibili, URL di admin interni).

Quando una decisione è stata informata da input sensibili, puoi comunque essere trasparente sulla forma del ragionamento:

• Riassumi le evidenze (“Supporto ha segnalato fallimenti ripetuti nei pagamenti con carte EU”) invece di citare ticket.
• Sostituisci identificatori con categorie ampie (“cliente enterprise” vs. nome azienda).
• Deferisci dettagli (“raccomandazione del team di sicurezza—dettagli trattenuti”) piuttosto che omettere la voce.

Revisione legale/compliance: un gate leggero

Non tutte le decisioni richiedono revisione legale, ma alcune sì. Definisci un flag “review required” per argomenti come cambi di prezzo, settori regolamentati, claim di accessibilità, implicazioni di policy sulla privacy o accordi con partner.

Mantieni il passaggio semplice: una checklist più un revisore designato, con tempi di turnaround previsti. L'obiettivo è prevenire rischi evitabili senza bloccare la pubblicazione.

Sii esplicito su ciò che viene volontariamente omesso

Aggiungi una breve policy (spesso nella pagina About o nel footer) che spiega cosa non pubblichi e perché: proteggere utenti, rispettare contratti e ridurre esposizione alla sicurezza. Questo regola le aspettative e riduce speculazioni quando i lettori notano lacune.

Crea una via per correzioni e segnalazioni

Dai ai lettori un modo chiaro per segnalare problemi, chiedere correzioni o sollevare preoccupazioni sulla privacy. Indica un canale dedicato come /contact e impegnati a una finestra di risposta. Documenta anche come gestite richieste di rimozione e come vengono annotate le revisioni (es., “Aggiornato il 2026-01-10 per rimuovere identificatori cliente”).

Collegare decisioni a release, doc e risultati

Una pagina di decisione è più utile quando è collegata a ciò che le persone possono vedere e verificare: cosa è stato rilasciato, cosa è cambiato e cosa è successo dopo. Tratta ogni decisione come un hub che punta a release, documentazione e risultati reali.

Collega decisioni a release e changelog

Aggiungi un piccolo blocco “Shipped in” su ogni voce con uno o più riferimenti alle note di rilascio pertinenti, per esempio a /changelog. Includi la data di release e la versione (o il nome dello sprint) così i lettori possano collegare la motivazione al momento in cui è diventata reale.

Se una decisione copre più release (comune per rollout phased), elencale in ordine e chiarisci cosa è cambiato in ciascuna fase.

Mantieni link a “documentazione correlata”

Le decisioni spesso rispondono al “perché”, mentre la doc risponde al “come”. Includi una sezione “Related docs” che collega alle pagine specifiche in /docs create o aggiornate a seguito della decisione (guide di setup, FAQ, riferimenti API).

Per evitare link rotti:

• Rendi il controllo dei link nei documenti parte del workflow di pubblicazione (anche una revisione trimestrale aiuta).
• Preferisci URL doc stabili (evita slug basati sulla data).

Mostra gli esiti, non solo le intenzioni

Aggiungi una sezione “Outcomes” che aggiorni dopo il rilascio. Mantienila fattuale:

• Metriche monitorate (es., ticket di supporto, tasso di attivazione, tempo per completare)
• Feedback ricevuto (temi riassunti, non citazioni private)
• Task di follow-up (link a issue pubbliche se presenti, o una lista breve con stati)

Anche “Outcome: misto” costruisce fiducia se spieghi cosa hai imparato e cosa hai cambiato dopo.

Crea un indice delle “Decisioni più citate”

Per l'onboarding, aggiungi una pagina indice leggera (o un modulo nella sidebar) con le “Decisioni più citate”. Ordinale per link interni, visualizzazioni di pagina o conteggio di citazioni da docs e /changelog. Questo dà ai nuovi lettori un percorso veloce verso le decisioni che hanno maggiormente plasmato il prodotto.

Misurare l'impatto e iterare

Una public decision history è utile solo se le persone trovano risposte e si fidano di ciò che trovano. Tratta il sito come un prodotto: misura l'uso, scopri dove fallisce e migliora in piccoli cicli regolari.

Traccia cosa le persone realmente usano

Inizia con analytics leggeri focalizzati sul comportamento, non su metriche di vanità. Cerca:

• Pagine top: quali decisioni vengono lette di più (candidati per migliori cross-link e sommari più chiari).
• Ricerche senza risultati: il modo più rapido per scoprire tag mancanti, titoli poco chiari o decisioni assenti.
• Tempo sulla pagina e uscite: una lettura lunga può indicare interesse elevato—o confusione. Abbina a prompt di feedback per capire quale.

Se hai una /search, registra le query (anche anonimamente) per vedere cosa la gente cerca.

Raccogli feedback dove conta

Rendi facile rispondere su ogni pagina di decisione, mentre il contesto è fresco. Un semplice prompt “È stato utile?” più un campo di testo è spesso sufficiente. In alternativa, aggiungi un link “Domanda su questa decisione?” che precompila l'URL della decisione.

Instrada il feedback in una inbox o tracker condiviso così non scompare nella posta di una singola persona.

Definisci segnali di successo

Scegli pochi risultati osservabili:

• Meno domande ripetute da clienti/partner/support sullo stesso tema.
• Allineamento stakeholder più rapido (es., meno cicli di meeting per riesaminare scelte passate).
• Discussioni di qualità superiore: feedback che cita ragionamenti e trade-off, non solo la conclusione.

Stabilisci una cadenza pratica

Pianifica una revisione mensile per:

• eliminare o unire duplicati,
• aggiungere tag e cross-link mancanti,
• riscrivere sommari poco chiari,
• migliorare i titoli per far funzionare meglio la ricerca.

Mantieni le modifiche visibili (es., campo “Last updated”) così i lettori vedono che il sito è mantenuto, non abbandonato.