Ich schätze es, dass das Discourse-Team offen für die Vorschläge neuer Leute ist, hier und auch anderswo.
Ich habe dieses Problem im Laufe der Jahre oft auf Meta beobachtet, aber dies hat mich dazu bewogen, auch allgemein meine Gedanken zu äußern. Es war mir auch frustrierend, dies zu sehen, aber ich wusste nicht wirklich, wie ich das Problem ansprechen sollte. Also werde ich versuchen, jetzt darüber zu schreiben:
Kontext
Manchmal habe ich auf Meta einen Trend beobachtet, dass neue Vorschläge für Discourse-Funktionen oder -Änderungen von neuen Leuten überhäuft werden. Anstatt die Erfahrungen von Leuten, die mit der Software noch nicht so vertraut sind, anzuhören und zu verstehen – deren Einblicke auch für uns, die Discourse seit über 10 Jahren nutzen, hilfreich sein können –, schlagen manchmal Leute aus der Community die Idee im Voraus nieder.
Oft geschieht dies, wenn eine Idee vom Discourse-Team bereits abgelehnt wurde oder wenn eine bestimmte Standardeinstellung vom Discourse-Team gegenüber anderen Konfigurationen gewählt wurde und so weiter.
Auch wenn dies der Fall ist, möchte ich meine Gedanken dazu äußern, warum wir Ideen oder Beschwerden über die Software nicht vorschnell abtun sollten, auch wenn sie in der Vergangenheit bereits diskutiert wurden.
Das Discourse-Team hat das letzte Wort. Vieles hat sich geändert. Dinge von damals gelten jetzt vielleicht nicht mehr.
Erstens sind wir als Community-Mitglieder nicht die Produktmanager für Discourse. Wenn wir jemandem voreilig sagen, dass seine Idee in der Vergangenheit abgelehnt wurde und warum, spiegelt dies möglicherweise nicht die aktuellen Entscheidungen des Discourse-Produktteams wider.
Manchmal kann sogar das Discourse-Team selbst entscheiden, an einer Funktion zu arbeiten, die in der Vergangenheit ausgeschlossen wurde. Lange Zeit war Chat eine solche Funktion.
Es besteht kein Zweifel, dass wir Fast-Lane- (Chat) und Slow-Lane- (Thema) Unterstützung nebeneinander benötigen. Es ist meine Schuld, dass wir es nicht früher getan haben, aber seien Sie versichert, dies wird ein völlig anderes Niveau an super glänzendem Finish mit voller Integration sein.
Es gibt also nie eine 100%ige Garantie, dass vergangene Entscheidungen die gleichen sein werden wie gegenwärtige Entscheidungen.
Selbst Leute im Discourse-Team können unterschiedliche Ansichten voneinander haben, was für Discourse Priorität haben sollte.
Zum Beispiel habe ich oft den Blog von @erlend_sh verfolgt und er diskutiert, wie er eine andere Ansicht als der Rest des Teams hatte, wie Chat in Discourse sein sollte – fette Hervorhebung ist mein.
Die meisten Open-Source-Projekte haben kein dediziertes Forum, aber die, die eines haben, haben fast sicher auch einen Gruppenchat. Mein letzter Aufenthalt bei Discourse war der Versuch, die beiden Modi zu verschmelzen, mit der Einführung von Discourse Chat.
Ich bin wirklich stolz auf dieses MVP (das inzwischen in den Kern aufgestiegen ist), aber die Richtung, in die ich von dort aus gehen wollte, war verständlicherweise unvereinbar mit der DNA des Discourse-Projekts als traditionelles Forum: Ich schlug vor, Chat zum führenden Element unserer Community-Erfahrung zu machen. Die Community beginnt in den Chaträumen, dachte ich. Discourse dachte nicht so, also trennten wir uns im Guten.
Jahre später bleibt meine Position unverändert. „Gruppenchat“ und „Forum“ sollten ungefähr dasselbe bedeuten. Das ist in der Tat die Richtung, in die wir uns zu bewegen scheinen, da Discord, der Herr über unsere Community-Lande, jetzt eine Vielzahl von Thread- und Board-Funktionen unterstützt, die gut in das Forum-Paradigma passen.
Es liegt also nicht wirklich an uns, vorschnell zu entscheiden, was nicht in Discourse gehören sollte, da sich dies auch im Laufe der Zeit ändern kann.
Diejenigen von uns aus den frühen Tagen von Discourse werden sich erinnern, als CDCK weniger als 10 Leute hatte und das Produktmanagement oft sehr stark von den Gründern von Discourse getrieben wurde. Aber heutzutage ist CDCK 100 Leute stark und CDCK hat ein ganzes Produktteam!
Discourse selbst hat eine viel, viel größere Nutzerbasis, deren Bedürfnisse und Nutzung der Software über die ursprünglichen frühen Anwender von Discourse hinausgewachsen sind. Im weiteren Sinne hat sich die Landschaft der sozialen Plattformen verändert (die Dynamik hat sich von Facebook zu Discord und mehr verlagert usw.), und die allgemeinen Erwartungen der Menschen haben sich geändert.
Da das Team viel größer ist als in den frühen Tagen von Discourse, hat es mehr Kapazitäten, an anderen Funktionen zu arbeiten, die in den frühen Tagen der Produktentwicklung in der Vergangenheit möglicherweise eine viel geringere Priorität hatten.
Wie sie Funktionsanfragen jetzt prüfen, wird sich wahrscheinlich stark von den Anfängen unterscheiden. Das Produktteam wird seinen eigenen Prozess für Entscheidungen haben und entscheiden, was letztendlich wann bearbeitet wird.
Mehr Datenpunkte sind besser
Zweitens ist es für das Discourse-Team normalerweise hilfreich, mehr Datenpunkte zu hören als weniger.
Es gab etwas, das auf Meta lose als „Regel der 3“ popularisiert wurde (mindestens 3 Personen beschweren sich über etwas, bevor diese Funktionsanfrage berücksichtigt wird). Selbst damit muss man die Leute ihre Erfahrungen teilen und sich beschweren lassen, um 3 verschiedene Leute zu hören, die ein Problem mit etwas finden.
Abgesehen davon war eine weitere popularisierte Idee „Complaint Driven Development“. Und damit muss man auch die Meinungen der Leute hören:
Das Einzige, was ich jemals funktionieren gesehen habe, ist, tief und schmutzig mit Ihren Benutzern in den Gräben zu arbeiten, mit ihnen zu kommunizieren und Beziehungen zu pflegen.
Nachdem ich das noch einmal gelesen habe, bin ich auch sehr stark der Meinung, dass die ursprüngliche Prämisse hinter dieser „Regel der 3“ NICHT ist, dass Ihre Meinung nicht zählt, wenn sich niemand anderes darüber beschwert.
Der Kernpunkt war, dass (besonders wenn Sie ein Team mit geringen Ressourcen sind) das Finden der Dinge, über die sich die Leute am meisten beschweren, eine effiziente Möglichkeit ist, die Probleme zu finden, die Ihre Benutzer am meisten stören – damit Sie diese zuerst beheben können.
Wie Steve Krug in Don’t Make Me Think sagt:
Sie werden immer mehr Probleme finden, als Sie Ressourcen zur Behebung haben, daher ist es sehr wichtig, dass Sie sich darauf konzentrieren, die schwerwiegendsten Probleme zuerst zu beheben. Und drei Benutzer werden mit großer Wahrscheinlichkeit viele der wichtigsten Probleme im Zusammenhang mit den von Ihnen getesteten Aufgaben feststellen.
Nur weil sich nicht viele andere Leute über dasselbe beschwert haben, heißt das nicht, dass es keine Rolle spielt. Mehr Datenpunkte sind für das Discourse-Team immer noch hilfreich, wenn es darum geht, die aktuellen großen/kleinen Schmerzpunkte für Benutzer zu berücksichtigen.
Es ist möglich, das Feedback von Leuten wertzuschätzen, auch wenn Sie es nicht umsetzen werden
Drittens ist es immer noch möglich, sich für das Feedback von Leuten zu bedanken, auch wenn Sie nicht alle ihre Vorschläge umsetzen können oder wenn Sie sich dagegen entschieden haben.
Ich habe mehr Übung darin bekommen, Feedback auf diese Weise zu handhaben, nachdem ich Spieldesign studiert habe, wo Geben und Empfangen von Feedback ein wichtiger Teil des Prozesses war. Bei Iterationen jedes Spiellevels, jedes Design-Dokuments oder von allem gaben wir Feedback zu der Arbeit von mindestens 3 anderen Personen und erhielten Feedback von mindestens 3 anderen. Ich habe versucht, Feedback für 4 oder 5 Personen zu geben, um andere Leute auszugleichen, die abwesend waren / ihre Aufgaben spät eingereicht haben usw.
Oft ist das Feedback von Leuten sehr aufschlussreich und hilfreich, aber es gibt mehr als 10 wichtige Punkte und im Moment haben Sie nur Zeit, 1-3 Dinge umzusetzen.
Dies war auch der Fall, als ich professionell als Softwareentwickler arbeitete und oft mit der Community interagierte, als Teil eines kleinen Startups. Es kann 10+ wichtige Fehlerberichte geben, aber im nächsten Update haben Sie Zeit, 1-3 davon zu beheben.
Auf jeden Fall fühle ich mich immer noch sehr verpflichtet, mich bei den Leuten für ihre Beobachtungen zu bedanken, ihnen dafür zu danken, dass sie ihre Gedanken geteilt haben, ihnen dafür zu danken, dass sie sich die Zeit genommen haben, die Schritte zur Reproduktion eines Fehlers aufzuschreiben, und mich für die Unannehmlichkeiten zu entschuldigen.
Die meiste Zeit sagen Benutzer/Spieler nichts, es sei denn, sie sind wirklich verärgert. Also kommt fast jedes schriftliche Feedback/Funktionswunsch/Fehlerbericht von jemandem, der sich die Zeit genommen hat, seine Gedanken zu etwas zu teilen – Dinge, über die viele andere vielleicht nachgedacht haben, aber noch nicht identifiziert oder gesagt haben, Dinge, die Sie wahrscheinlich übersehen haben und so weiter.
Selbst wenn Sie nicht alles umsetzen können, was jeder sagt – was vielleicht 90% der Zeit der Fall ist –, bedeutet das nicht, dass Sie sich auf dieses Feedback stürzen und es unterdrücken müssen. Das Feedback ist immer noch wichtig, auch wenn Sie im Moment nicht die Ressourcen haben, darauf zu reagieren, oder auch wenn Sie sich entschieden haben, nicht darauf zu reagieren.
Auf jeden Fall denke ich, dass es sich für uns als Community-Mitglieder lohnt, anderen neueren Leuten zu erlauben, ihre Gedanken zu teilen und nicht sofort auf ihre Vorschläge für Discourse einzugehen und sie abzutun. Dies liegt daran, dass sich die Haltung des Discourse-Teams zu Funktionen im Laufe der Zeit ändern kann und das Feedback für das Discourse-Team immer noch als Datenpunkte hilfreich ist, auch wenn sie es im Moment vielleicht nicht umsetzen.