2024 suchte ich nach Arbeit. Ich beschloss, meine Dienstleistungen als Community-Berater anzubieten. Meistens waren die Leute jedoch an technischer Hilfe interessiert, um ihre Discourse-Sites zu reparieren oder zu aktualisieren. Ein potenzieller Kunde fragte, ob ich ein Kontaktformular für Personen ohne Konto hinzufügen könnte, um Feedback zu senden. Ich recherchierte und kam zu dem Schluss, dass dies nicht möglich war. Doch ich hatte viel Freizeit und folgte dem Plugin-Entwickler-Tutorial, um zu sehen, was ich tun konnte. Schließlich entwickelte ich ein Kontaktformular-Plugin und unterzeichnete den Vertrag mit dem Kunden.[1]
Nur damit alle Bescheid wissen: Ich bin kein Frontend-Programmierer! Es sind 13 Jahre her, seit ich als Programmierer irgendeiner Art professionell tätig war. Ich weiß, wie man ein HTML-Formular erstellt, und das ist in etwa der Umfang meines Wissens. Also habe ich mich durch den Ember- und Handlebars-Abschnitt des Tutorials gekämpft und einen Hack zusammengeschustert, der gut genug funktionierte. Zum Glück war ich mit Template-Systemen vertraut, da ich sie in einem früheren Job verwendet hatte.
Ich fand eine Stelle bei der OpenSSL Foundation[2] und gab meine Kunden größtenteils auf. Doch der Kunde, für den ich das Plugin entwickelt hatte, behielt mich im Rahmen eines Retainer-Vertrags, weil er meine Arbeit sehr schätzte. (Ich habe für ihn mehrere unrelated Projekte durchgeführt.) Um mein Retainer zu verdienen, beschloss ich, seinen Discourse-Server zu aktualisieren. Das war es, was ich sah:
Nur das war auf der Website meines Kunden, weil ich dumm war und das Kontaktplugin auf meiner Staging-Site installiert, aber nicht aktiviert hatte. Also aktivierte ich schnell den Sicherheitsmodus und deaktiviert das Plugin. Letztes Wochenende verbrachte ich einige Zeit damit, herauszufinden, was schiefgelaufen war und wie ich es für meinen Kunden beheben könnte.
In der neuesten Version von Discourse ist die Verwendung von .hbs-Dateien in Themes und Plugins veraltet. Die Unterstützung für dieses Dateiformat wird nach dem nächsten ESR-Release entfernt.
Das war im März, und das bedeutet, ich hätte bis praktisch Ende September Zeit gehabt, es zu beheben, wenn ich beim ESR-Release gewesen wäre. Aber meine Discourse-Konfiguration verwendet „tests-passed
Ich habe bei vielen von mir geschriebenen Plugins dasselbe durchgemacht. Ich hatte nicht die Kapazitäten, sie auf den aktuellen Discourse-Standard zu modernisieren. Ich habe einen Job im Bereich Data Science, und obwohl ich Software-Engineering-Konzepte kenne, halte ich mich nicht mit den Details der Webentwicklung auf dem Laufenden. Am Ende habe ich meine Website acht Monate lang nicht aktualisiert, da sie von diesen veralteten Plugins abhing.
Ich möchte deinen Kampf nicht herunterspielen, aber grundsätzlich denke ich, dass sich mit dem Aufkommen von agentic coding diese Entwicklungsgeschwindigkeit zu einem Nicht-Problem entwickelt hat. Was früher eine oder zwei Wochen gekostet hätte, um den Code zu schreiben und fehlerfrei zu bekommen, benötigte jetzt ein 20-Dollar-Abonnement für Claude Code und ein paar Minuten pro Plugin. Darüber hinaus konnte ich sie auch hinsichtlich der Leistung optimieren. Nachdem ich agentic coding für einige Arbeits- und Hobbyprojekte genutzt habe, glaube ich nicht, dass ich jemals wieder etwas von Grund auf neu programmieren werde. Es ist wie der technologische Unterschied zwischen dem handschriftlichen Verfassen und dem manuellen Zustellen eines Briefes im Vergleich zum Senden einer E-Mail. Es ist ein bisschen traurig, aber gleichzeitig fühlt es sich an, als hättest du göttliche Kräfte erhalten.
Das scheint wahrscheinlich. Auf den neuesten ESR zu wechseln (und beim Testen etwas wachsamer zu sein) scheint von jetzt an ein guter Plan zu sein.
Ich denke nicht, dass das Entwicklungstempo an sich ein Problem ist. Es ist das Tempo von allem. Warum wurde beispielsweise das Plugin-Tutorial nicht aktualisiert? Es ist eine Mine, die darauf wartet, einem armen Schlucker in die Fresse zu gehen, der ein Plugin bauen will. Es wird im Moment funktionieren, aber irgendwann werden sie auf dasselbe Problem stoßen, mit dem ich konfrontiert bin. Die Lösung besteht nicht darin, KI zu verwenden, um das Plugin später zu reparieren, sondern die Anweisungen zur Erstellung eines Plugins jetzt zu korrigieren. Ich meine, es gibt doch keinen Grund, immer noch die alte Methode zu lehren, oder?
we wir ein relativ kleines Team sind, das eine riesige Codebasis wartet und gleichzeitig neue Funktionen für zahlende Kunden implementieren muss, während wir Unterstützung bieten und sicherstellen, dass alles für unsere Open-Source-Community funktioniert.
Es gibt nur so viel, was wir an einem Tag schaffen können, und die Dokumentation hinkt oft hinterher.
Ich verstehe deine Frustration sehr gut, aber ich finde, dieser Punkt sollte auch erwähnt werden.
Danke für die ausführlichen Informationen @jericson. Wie du sagst, befindet sich Discourse sowohl in Bezug auf die Nutzung als auch auf die Position im Stack in einer ganz anderen Lage als OpenSSL. Es ist ein ständiger Balanceakt zwischen Fortschritt, Anpassbarkeit und Stabilität. Es gibt keine perfekte Lösung, die alle zufriedenstellt, aber wir berücksichtigen stets das Feedback unserer Kunden und der Open-Source-Community. Der von dir geteilte Zitat gefällt mir sehr:
Wie @moin erwähnt hat, war die Erfahrung, die du mit der .hbs-Deprecation gemacht hast, etwa eine Woche lang ein Fehler in latest. Entschuldige bitte vielmals! Obwohl die Verwendung von .hbs deprecated ist, wird sie weiterhin unterstützt. Dein .hbs-Code sollte jetzt wieder funktionsfähig sein.
Danke, dass du das angesprochen hast. Ich habe die verbleibenden .hbs-Erwähnungen in der Dokumentation bereinigt:
Das kann ich absolut nachvollziehen.[1] Ich mag Discourse wirklich und habe diesen Beitrag geschrieben, weil ich möchte, dass Discourse weiterhin erfolgreich ist.
Etwas, das ich gelernt habe, ist, dass Communities Veränderungen nicht mögen, aber viel offener dafür sind, wenn sie das Gefühl haben, selbst Einfluss nehmen zu können. Es gibt unzählige Möglichkeiten, den Menschen Handlungsspielraum zu geben. Zum Beispiel könnte das Tutorial in Wiki-Beiträge umgewandelt werden, damit Leute wie ich sie aktualisieren können. Die Umsetzung des ESR-Plans hilft ebenfalls, da es den Leuten die Möglichkeit gibt, Änderungen nicht sofort vorzunehmen.[2] Es hilft auch, wenn ich meine Erfahrungen niederschreiben und von Personen gesehen werden kann, die das Open-Source-Projekt verwalten. Besonders, da die Dinge, über die ich mich beschwert habe, über Nacht behoben wurden.
In „Listening to users considered harmful?
OpenSSL hat eine ähnliche Dynamik. Wir haben eine Firma (ca. 15 Personen), die Supportverträge verkauft, und eine Stiftung (10 Personen, einschließlich mir), die sich um nicht-kommerzielle Interessen kümmert. Auch unsere Dokumentation hinkt hinterher. Während ich den ursprünglichen Beitrag schrieb, fiel mir auf, dass wir immer noch Referenzen zu Funktionen haben, die letzten Monat entfernt wurden. Ich arbeite an einem PR dafür. Außerdem haben wir einige Änderungen vorgenommen, die nachgelagerteProjekte stark kritisiert haben. ↩︎
Weniger hilfreich für Plugin-Autoren, die Communities unterstützen wollen, die an der Spitze der Entwicklung bleiben möchten. Aber es wird großartig für mich sein, da ich glaube, dass ich der Einzige bin, der mein Plugin nutzt. ↩︎
Warum muss das dafür ein Wiki sein? Die Entwicklerdokumentation wird über GitHub verwaltet. Mir gefällt der Prozess, bei dem Änderungen überprüft werden, sogar besser als ein Wiki.
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.
Nur zur Klarstellung zu diesem Punkt: Der Abklingzeitplan für hbs hat erst vor kurzem begonnen. Wir werden die Unterstützung frühestens nach dem nächsten ESR (Ende Juli) einstellen. Ja, wir hätten die Dokumentation früher aktualisieren sollen, aber dies ist kein Fall von „Unterstützung ohne ausreichende Warnung abzubrechen“. .hbs wird weiterhin unterstützt, und es gibt genügend Zeit, um die notwendigen Änderungen vorzunehmen.
Wir pflegen über 600 Themes und Plugins, daher kann ich Ihnen versichern, dass wir den „Schmerz“ dieser Migrationen ebenfalls spüren. Wir geben unser Bestes, um die Änderungen für alle so reibungslos wie möglich zu gestalten, und werden weiterhin aus jeder Änderung lernen, die wir vornehmen.
Genau.
Das haben wir noch nicht ganz. Aber wir beginnen damit, im Kern-Repository ein Verzeichnis mit Fähigkeiten aufzubauen. Außerdem wurde die gesamte Entwicklerdokumentation im Markdown-Format in das Kern-Repository verschoben, unter anderem damit es für KI-Agenten einfacher ist, darauf Bezug zu nehmen.
Ich vermenge vielleicht Dinge in meinem Kopf, da ich meine Plugins sowohl für das Ember-6-Upgrade (die große Update-Blockade für mich) angepasst und gleichzeitig von hbs migriert habe. Entschuldigung, wenn ich zu selbstbewusst war!
Aber ich denke, wenn Discourse das von Nutzern erstellte Plugin-Ökosystem erweitern möchte, wäre ein modernes „Vibecoding“-Tutorial hilfreich. Aber ist es wünschenswert, die Schleusen für eine Welle von vibecoded Plugins zu öffnen? Schwer zu sagen
Ich bin ein Fan davon, Dokumentation auf GitHub zu veröffentlichen. Es ist zwar etwas aufwendiger, Änderungen einzureichen, als einen Wiki-Beitrag zu bearbeiten, aber der Prüfungsschritt ist hilfreich. (Und für die Dokumentation von Plugin-Autoren ist die Voraussetzung, Git zu beherrschen, keine besonders hohe Hürde.)
Genau.