Das ist genau das Problem mit der Discourse-Dokumentation.
So sehr es für manche „in Ordnung“ sein mag, nach Themen zu jagen, ist es keine Dokumentation. Es sind die Benutzer, und schlimmer noch, die Administratoren/Moderatoren, die nach Informationen jagen müssen.
Nein, das ist es nicht. Und das war und ist nach wie vor der größte Mangel von Discourse. Ich weiß nicht, ob ich jetzt zu unhöflich bin oder so, aber die Tendenz, hier zu agieren, ist zu entwicklerzentriert – wenn man es nicht weiß, kann man immer die Quelle auf GitHub lesen. CDCK hat nicht viel Motivation, eine gute Dokumentation für Benutzer – einschließlich Administratoren natürlich – zu erstellen, da ihr Ziel große Unternehmen sind. Daher reichte für sie das Mindestmaß plus Community-Hilfe für Trittbrettfahrer (die einen großen Teil der Fehlerbehebung und UX-Vorschläge machen 
). Außer dann bräuchten wir mehr freie Nutzung von Tags…
Reichte war keine Tippfehler oder geringe Englischkenntnisse. CDCK/Team hat begonnen, eine bessere Dokumentation aufzubauen, und ich bin mir absolut sicher, dass nach einiger Zeit nebensächliche Themen wie dieses nur noch Echos aus der Vergangenheit sein werden.
Was die Entwickler-/Benutzergemeinschaften angeht, so liegt Discourse weit über dem Durchschnitt. Fehler scheinen schnell behoben zu werden, Funktionsanfragen werden nicht einfach ignoriert, besonders wenn es dafür einen vernünftigen Anwendungsfall gibt, und die Online-Mitarbeiter (bezahlt oder Freiwillige, ich bin mir nicht sicher, wie man das feststellt) sind ziemlich gut und geduldig darin, uns Neulinge anzuleiten.
Ja, die Dokumentation muss überarbeitet werden, aber gute Dokumentation zu schreiben ist teuer und zeitaufwendig. Außerdem schreiben Entwickler oft keine gute Dokumentation, weil sie dem Produkt zu nahe stehen und es nicht so sehen, wie es die Benutzer sehen. Zu nah am Code zu sein, ist auch ein Problem beim Produkttesten, obwohl in vielen Open-Source-Projekten die Benutzergemeinschaft gute Arbeit beim Testen leistet.
Sicher ist sie das. Genauso wie das Schreiben von gutem Code. Gute menschliche Arbeit ist oft teuer. Aber Code und Dokumentation sind miteinander verbunden, und die Dokumentation wird zu diesem Zeitpunkt teuer, wenn niemand sie erstellt. Andernfalls ist sie ein entscheidender Teil eines Produkts, genauso wie das Codieren, einschließlich Testen, Design, UX/UI usw. Aber Entwickler hassen Dokumentation oft, weil sie es einfach nicht tun wollen, es nichts Attraktives daran gibt, und sie sind oft wirklich schlecht darin Aber da die Eigentümer von Unternehmen und andere Vorgesetzte ähnliche Entwickler sind, kümmern sie sich einfach nicht darum, dass die Leute auswählen, was sie tun und was nicht.
Aber jetzt schweife ich zu allgemeinen Dingen ab, die viel zu sehr vom Thema abweichen. Also höre ich auf und verweise auf Documentation, da es gerade weiterentwickelt wird.
Ich stimme dem absolut zu. Ich bin Entwickler mit über 20 Jahren Erfahrung, auch wenn ich mich in den letzten Jahren auf Plattform-Engineering spezialisiert habe.
Das wird hier sehr deutlich, wenn man nach einem Vorschlag fragt und Entwickler (ich nehme es an? Ich sehe nur, dass sie durch ihren Titel Teil von Discourse sind) kommen und einem sagen, dass es nicht so ist und auch nicht sein wird, weil sie es so beschlossen haben.
OT von hier
Ich habe das schon gesagt: Es gibt einen Unterschied zwischen einer Meinungsvielfalt im Tech-Stack und einer Meinungsvielfalt im Produkt. Ihr Produkt sollte auf die Anwendungsfälle der Benutzer zugeschnitten sein, im Rahmen des Zumutbaren, und nicht “mein Ball und wenn es anderen nicht gefällt, können sie woanders hingehen”.
Ich habe bereits 5 neue Projekte gestartet und Gott sei Dank hatten wir jemanden in unserer Community, der sich ein wenig mit Ruby auskennt und uns in den nächsten Tagen einige Grundlagen des Discourse-Flows erklären wird, damit wir einige Plugins schreiben können, die die benötigten Funktionen bieten. Vor allem, um die Kategorie-Mods nicht zu einem Witz zu machen.
Der Support-Thread Users are receiving emails even when everything is set up to not send email notifications hat sich ein wenig weiterentwickelt, daher habe ich ihn in ein paar neue Threads in anderen Kategorien aufgeteilt, um jedem von ihnen etwas Raum zum Atmen zu geben. 
Ich kann an ein Open-Source-Projekt denken, bei dem die Entwickler dazu neigen, an Dingen zu arbeiten, an denen sie interessiert sind, und nicht an Dingen, die das Leben der Benutzer dieses Produkts einfacher machen könnten. Anwendungsfälle sind immer eine Frage der Perspektive, Benutzer von Produkten haben eine andere Sicht auf Anwendungsfälle als Entwickler. Entwickler neigen dazu, Dinge, die Benutzer tun, als „nur mehr Daten“ zu betrachten und sehen oft nicht, wie eine kleine Änderung einen RIESIGEN Unterschied in der Benutzerfreundlichkeit machen könnte. (Ich habe meinen Anteil an der Systementwicklung geleistet und bin sicher, dass ich diese Einstellung manchmal hatte.)
Bisher kann ich nicht sagen, dass ich diese Art von Einstellung bei der Discourse-Entwicklung gesehen habe, aber ich bin erst seit einem Monat hier.
Was die zu enge Bindung an das Produkt betrifft, so durchlaufe ich derzeit die Übungen in einem Buch über Ruby-Entwicklung. Eine einfache „Hallo Welt“-App hat mich gestern 3 Stunden gekostet, bis sie funktionierte, hauptsächlich weil das Buch mit einer AWS-IDE (cloud9)-Umgebung vertraut sein musste, die ich noch nicht hatte, sodass ich auf etwas klickte und es die Änderungen rückgängig machte, die ich gerade 10 Minuten lang getippt hatte.
Und dann gab es ein Problem mit der Anzeige einer Vorschau der funktionierenden App in meinem Browser, was anscheinend auf Sicherheitseinschränkungen zurückzuführen ist, die sowohl Firefox als auch Chrome seit der letzten Aktualisierung des Buches in ihren Browsern eingeführt haben. Nach etwa einer Stunde Websuche nach Lösungen funktionierte das Whitelisting der IP-Adresse meines Laptops und Desktops, obwohl ich immer noch einen zusätzlichen Schritt durchlaufen muss, um die Vorschau anzuzeigen.