Sono d’accordo sul fatto che la documentazione dei plugin debba essere aggiornata in questo momento. L’obiettivo del periodo di “deprecazione”, durante il quale i plugin continuano a funzionare ma il sito mostra un avviso sul fatto che smetteranno di farlo a breve, è quello di dare agli autori dei plugin abbastanza tempo per correggerli. Eppure, in quel lasso di tempo, un team di sviluppatori retribuiti a tempo pieno non è riuscito ad aggiornare la documentazione principale per lo sviluppo dei plugin. È un’aspettativa strana da avere dagli sviluppatori individuali quando un team non riesce a gestirla completamente nello stesso periodo.
Per me, questo indica che la velocità di sviluppo è troppo elevata e/o che gli autori dei plugin non sono una priorità significativa per Discourse. Personalmente, credo che sia più quest’ultimo caso. Capisco che qualcosa debba passare in secondo piano, quindi questa è un’osservazione da parte mia e non una critica. Discourse rimane completamente personalizzabile tramite plugin e apprezzo i continui miglioramenti.
Detto questo, penso che siamo arrivati al punto in cui una guida documentale passo dopo passo per creare un plugin boilerplate sia un’idea obsoleta. Oggi, per un autore di plugin alle prime armi, è sufficiente un unico documento contestuale da far leggere a un agente per generare la struttura di base di un plugin. Anzi, per una codebase open source come Discourse, la documentazione non è affatto necessaria, poiché gli agenti ottengono il contesto direttamente dalla codebase stessa. Quando stavo lavorando ai miei plugin, ho visto Claude leggere i plugin esistenti per apprendere i modelli di progettazione. Sono stato persino in grado di individuare un bug nel codice principale: Chat Pitchfork timeouts: replies silently create threads and auto-tracking bloats over time
In sintesi, per chiunque legga questo e aspiri a diventare un autore di plugin alle prime armi, la documentazione potrebbe essere obsoleta, ma creare un plugin è ora 1000 volte più facile rispetto al passato.