Sito ecosistema plugin

Una directory plugin è dove la fiducia si guadagna o si perde. I visitatori non cercano aggettivi: vogliono sapere cosa fa un plugin, chi lo mantiene, se è pronto per la produzione, come si installa e come si comporta in uno stack EmDash reale. Un sito pubblico strutturato trasforma queste risposte in pagine coerenti invece di frammenti README sparsi.

Cosa deve dimostrare ogni pagina plugin

Parti dai risultati: problema risolto, ambienti supportati e impronta operativa (Workers, D1, API esterne). Prosegui con compatibilità, versioning e licenza. Metti in evidenza link a sorgente, download e documentazione approfondita. Se qualcosa è beta, dichiaralo chiaramente e spiega cosa significa “beta” per dati e uptime.

Passi concreti di rollout

1. Definisci un template pagina unico. I campi standard possono includere stato, categoria, versione, modello di prezzo, compatibilità, link repository e changelog. La coerenza aiuta gli utenti a confrontare opzioni rapidamente.

2. Pubblica istruzioni d’installazione aderenti alla realtà. Preferisci comandi e snippet di configurazione che funzionano con il layout attuale del repo, ad esempio facendo riferimento a packages/plugins/<name> nel monorepo EmDash quando quella è la source of truth.

3. Pubblica note di rilascio a ogni modifica rilevante. Anche una breve lista puntata è meglio del silenzio. Collega, quando possibile, viste compare su GitHub o release taggate.

4. Aggiungi segnali di fiducia. Nome maintainer, canale di supporto e aspettative di sicurezza devono stare nella pagina, non solo in chat. Per plugin che chiamano API di terze parti, documenta i secret richiesti e i rate limit.

5. Collega i casi d’uso. Connetti i plugin agli scenari che sbloccano: Forms per lead capture, Webhook Notifier per automazione, Audit Log per team con più editor.

Esempio: valutare un nuovo plugin per la directory

Prima che la pagina vada online, passa questa checklist: la descrizione in una riga corrisponde a ciò che il codice esporta davvero? Screenshot o diagrammi sono accurati? La licenza è corretta? Un nuovo utente può installarlo senza conoscenze interne? Se una risposta è “no”, chiudi il gap prima di promuovere il plugin.

Cadenza operativa

Mensile: rivedi issue aperte e aggiorna i campi stato. Trimestrale: depreca listing abbandonati o segnali come “unmaintained” con note di migrazione. Dopo release maggiori EmDash: ritesta i plugin principali e aggiorna le stringhe di compatibilità.

Risultato

I builder scoprono i plugin più velocemente, li adottano con meno sorprese e trattano l’ecosistema come infrastruttura seria, non come una brochure.