Ich stimme zu, dass die Plugin-Dokumentation jetzt aktualisiert werden sollte. Das Ziel des „Deprecation“-Zeitraums, in dem die Plugins noch funktionieren, aber die Website eine Warnung anzeigt, dass sie bald nicht mehr funktionieren werden, besteht darin, den Plugin-Autoren genügend Zeit zu geben, um sie zu reparieren. Doch in diesem Zeitraum konnte ein Team aus Vollzeit-Entwicklern die Dokumentation zur Kern-Plugin-Entwicklung nicht aktualisieren. Es ist eine seltsame Erwartung, die an einzelne Entwickler gestellt wird, wenn ein Team es im selben Zeitraum nicht vollständig bewältigen kann.
Was mir das signalisiert, ist, dass die Entwicklungsgeschwindigkeit zu hoch ist und/oder Plugin-Autoren für Discourse keine hohe Priorität haben. Persönlich bin ich der Meinung, dass es eher das Letztere ist. Ich verstehe, dass etwas zurückgestellt werden muss, daher ist dies eher eine Beobachtung als eine Kritik. Discourse bleibt über Plugins vollständig anpassbar, und ich schätze die kontinuierlichen Verbesserungen.
Trotzdem denke ich, dass wir an einem Punkt angelangt sind, an dem eine schrittweise Dokumentationsanleitung zum Erstellen eines Boilerplate-Plugins eine überholte Idee ist. Ein einzelnes Kontextdokument für einen Agenten, der es liest und ein Plugin-Gerüst erstellt, ist heute alles, was ein Amateur-Plugin-Autor benötigt. Tatsächlich ist für eine Open-Source-Codebasis wie Discourse überhaupt keine Dokumentation erforderlich, da die Agenten den Kontext direkt aus der Codebasis selbst erhalten. Als ich an meinen Plugins arbeitete, sah ich, wie Claude existierende Plugins las, um die Entwurfsmuster zu erlernen. Ich konnte sogar einen Fehler im Kerncode aufspüren: Chat Pitchfork timeouts: replies silently create threads and auto-tracking bloats over time
Grundsätzlich gilt für alle, die dies lesen und sich als Amateur-Plugin-Autoren versuchen möchten: Die Dokumentation mag veraltet sein, aber es ist 1000-mal einfacher, ein Plugin zu erstellen als je zuvor.