Schnelle Frage dazu. Was ist mit automatisch geschlossenen Themen mit einer Lösung? Logischerweise möchte man, dass diese angezeigt werden, da sie eine Lösung haben, aber wenn ich es richtig verstanden habe, sind diese derzeit automatisch weniger prominent.
Können wir das mit einer Website-Einstellung umschalten? In einigen Fällen kann ein Thema geschlossen und gelöst sein. Umgekehrt erwarten einige Benutzer möglicherweise sogar, dass dies höher in den Ergebnissen erscheint.
Ich bin sehr froh, dass die Suche Aufmerksamkeit erhält. Die Möglichkeit, speziell nach Kategorie zu suchen, ist für unseren Anwendungsfall bereits ein großer Vorteil.
Das Einzige, bei dem ich mir eine Verbesserung wünschen würde, sind häufige Rechtschreibfehler. Einige Suchmaschinen haben mich so verwöhnt, dass ich faul auf die Tasten schlage, bis eine Buchstabenkombination, die dem ursprünglichen Wort nur vage ähnelt, in der Suchleiste erscheint . Ich erwarte nicht, dass dies übereinstimmt, aber Verbesserungen in diesem Bereich wären ein großer Schritt nach vorne.
Heißer Take! Ich denke, es wäre besser, dies konsistent zu halten (d. h. keine Option pro Site) und:
Die Priorität von geschlossenen Beiträgen, die gelöst sind, zu erhöhen (auf größer als offene Beiträge).
Die Option eines Timers (idealerweise pro Kategorie und/oder pro Tag) hinzuzufügen, um geschlossene Beiträge automatisch zu archivieren.
Innerhalb archivierter Beiträge diejenigen mit Lösungen zu priorisieren – aber nicht so sehr, dass sie über nicht archivierten Beiträgen angezeigt werden.
Haftungsausschluss: Ja, ich möchte diese automatische Archivierungsfunktion für meine eigene Website! Aber ich denke, sie ist allgemein sinnvoll. Alles, was beantwortet, aber wahrscheinlich irrelevant ist, sollte weggeräumt werden. Und wenn Sie das nicht möchten (Ihre gelösten Fragen sind zeitlos), aktivieren Sie den Archivar nicht.
Warum, weil es die Entwicklerseite einfacher macht? Oder weil es das Leben der Benutzer erleichtert, wenn sie zwischen Discourses wechseln? Etwas anderes?
Der erste Grund ist gar kein Grund – solange die Arbeitslast überschaubar und eine Aufgabe in dieser Realität möglich ist. Der zweite ist ein guter Grund für MS oder Apple, die nicht zu sehr mit Kunden kämpfen wollen, aber ansonsten – als Administrator und Content Creator möchte ich meinen Benutzern dienen, nicht die Dinge ähnlich halten wie hier, dort oder anderswo
Beides. Und weil es die Admin-Komplexität reduziert. Anstatt einer ganzen Reihe von Optionen (und der Möglichkeit, nicht einmal zu erkennen, dass es eine Einstellung gibt, um das zu tun, was Sie wollen), treten Sie einen Schritt zurück und finden Sie ein allgemeines Muster, damit das gewünschte Muster in den meisten Fällen einfach funktioniert.
Aber. Könnten wir eine weitere und dennoch vertraute Lösung verwenden: versteckte Einstellungen?
Ich sehe hier jetzt zwei verschiedene Strategien:
Sollen Administratoren freie Hand haben, wichtige Teile wie Suchergebnisse anzupassen, da die Bedürfnisse der Community unterschiedlich sind und nicht von der Plattform abhängen (das ist eine Coding-/Entwicklungsfrage)?
Sollen Administratoren wie andere Benutzer behandelt werden und die Dinge übersichtlich und benutzerfreundlich halten, und CDCK entscheiden lassen, was, wo und warum?
Wenn man sich Support ansieht, haben beide Wege Vor- und Nachteile Aber trotzdem – die erste Richtung gehört eher zur Open-Source-Welt, während die letztere der Weg von Apple ist.
Mehr Optionen erzeugen mehr Fragen und Probleme, die von nicht so erfahrenen Administratoren wie mir verursacht werden. Mehr Optionen können bessere Ergebnisse für Benutzer und Besucher liefern. Also?
Für mich ist die Frage sehr einfach: Ich möchte eine möglichst leistungsfähige Suche haben, und wenn das Schließen eines Themas sein Ranking in den Suchergebnissen verringert, schließe ich Themen nicht mehr oder nur sehr selten. Eine einfache Wahl, aber dann muss ich aufgrund von Softwarebeschränkungen handeln, nicht aufgrund der Bedürfnisse der Community.
Wir haben hier viele Präzedenzfälle für Regler, wir haben eine Suchpriorität pro Kategorie, die jeder Administrator konfigurieren kann.
Ich bin sicherlich nicht gegen einige weitere Regler, wie “archiviert/geschlossen/gelöst” im Suchergebnis nach oben (oder unten) geboostet wird.
Es ist ein bisschen eine Nebenquest, empfehlen wir, sie in einem anderen Thema abzuspalten mit einem klaren Vorschlag, welche Einstellung(en) sinnvoll wären?
Ich würde gerne herausfinden, welche nächsten Schritte für eine Änderung hier in Betracht gezogen werden könnten, angesichts des bisher geäußerten Interesses.
Auf Meta… angesichts des Rauschens in Support neigen wir dazu, es zu de-priorisieren… sobald es de-priorisiert ist, greift der Bonus für die Rangfolge nicht mehr…
Es ist also noch etwas anderes zu bedenken, wie sich dies auf die Kategoriegewichte auswirkt.
Ich denke, ein iterativer Ansatz hier könnte wie folgt aussehen:
Fügen Sie einfach einen Fall für gelöste Themen hinzu: WHEN topics.solved then 1.1
Ändern Sie die Gewichte für archivierte, geschlossene und gelöste Themen so, dass sie Multiplikatoren für das Kategoriegewicht und untereinander sind.
Machen Sie die Multiplikatoren für archivierte, geschlossene und gelöste Themen über die Website-Einstellungen konfigurierbar.
Vielleicht ist es sinnvoll, all diese Punkte auf einmal zu erledigen. Oder vielleicht erledigen wir (1) und (2) zuerst und warten, bevor wir sie konfigurierbar machen. Was meinst du, @sam?
Die Verwendung von Multiplikatoren scheint ein generell guter Ansatz zu sein, aber ich denke, es ist schwer auszudrücken, was ich oben vorgeschlagen habe.
geschlossen nicht gelöst < offen nicht gelöst < offen gelöst < geschlossen gelöst
Geschlossen sollte eine Prioritätserhöhung für gelöste Beiträge sein, aber eine Verringerung für ungelöste.
Geschlossene Beiträge ohne Lösung sind fast wertlos – jemand anderes hatte dieses Problem, aber es gibt keine Antwort darauf, und Sie können keine geben. Geschlossene Beiträge mit Lösungen sind hingegen Gold wert. Sie sind nicht nur gelöst, sondern eindeutig gelöst.
Ja, im Grunde schon, obwohl die Reihenfolge der archivierten Beiträge wahrscheinlich keine Rolle spielt:
Archivierte Beiträge mit Lösungen sind wahrscheinlich irrelevant, können aber historisch interessant sein. Archivierte Beiträge ohne Lösungen sind im Grunde dasselbe – wenn Sie im Archiv suchen, dann wahrscheinlich aus historischen Gründen, daher ist der gelöste Zustand eine Information, aber wenn es darauf ankommt, welcher es ist, sollten Sie das in Ihrer Abfrage explizit angeben.
Verwenden Sie selbst überhaupt Kategoriegewichtungen? Wenn ja, haben Sie Gefühle dafür, ob diese Gewichtung die aktuellen zustandsbasierten Gewichte überschreiben oder multiplikativ sein sollte?
Ich denke, der Schalter zum Nachschlagen in einer bestimmten Kategorie ist ausreichend und könnte gut sein, dieses Gewicht bei der Suche zu verwerfen (weil die Leute nach Lösungen suchen, nicht nach Kategorien oder vorgeschlagenen Themen/Kategorien).
Meine zwei Cents, ich stimme voll und ganz zu, was Sie hier tun
Ja, wir verwenden sie definitiv. Wir haben einige „Workflow“-Kategorien, die grundsätzlich nie auftauchen sollten, es sei denn, sie werden danach gefragt, und andere, die Ankündigungen und Nachrichten sind, die wichtiger sind.
Ich erfinde das gerade jetzt, daher behalte ich mir das Recht vor, meine Meinung in Zukunft zu ändern, aber ich denke, ich möchte, dass die Kategoriegewichte alle Topic-Status-Gewichte überschreiben, außer archiviert. Ich denke hier an den Nachrichtenfall. Diese sollten hoch in den Ergebnissen erscheinen, solange sie aktuell sind, aber nach einiger Zeit überhaupt nicht mehr. Und das Archivieren von Beiträgen könnte für jede Website eine Möglichkeit sein, anzugeben, was „einige Zeit“ bedeutet.[1]
Alternativ und vielleicht einfacher: Kategoriegewichte einfach überschreiben und dann eine Option pro Kategorie einführen, um frische Beiträge zu bevorzugen, und wenn diese aktiviert ist, einen Multiplikator einführen, der im Laufe der Zeit sinkt (z. B. von 2x auf 0,5x).
Und dann gibt es immer noch die automatische Archivierung nach einem Timer RFE, aber Details, Details! ↩︎
OK, ich höre, dass die Gewichtungen der Kategorien Vorrang haben sollten.
Ich denke, wir sollten die Gewichtungen für „gelöst/geschlossen/archiviert“ immer noch innerhalb einer Kategorie anwenden.
Ich höre Sie auch bezüglich des automatischen Archivierungs-Timers … er ist ergänzend, aber ich denke, wir können hier zuerst etwas erreichen, ohne ihn.
Ich würde dem hier widersprechen. Ein Thema könnte eine gute Antwort haben, aber der OP hat sich nicht die Mühe gemacht, es als Lösung zu markieren/Lösungen waren nicht verfügbar, wenn es sich um ein älteres Thema handelt usw.
Ein offenes Thema hat den Vorteil, dass man es hochschieben kann, aber darauf würde ich nicht zu viel Gewicht legen. Ich würde es eher bevorzugen, die relevantesten Inhalte basierend auf Schlüsselwörtern zu sehen.
Bezüglich archiviert stimme ich zu – für mich sind das Inhalte, die nicht mehr relevant sind und weniger Gewicht haben können.
Warum sollte ein solches Thema geschlossen werden? (Und vorausschauend: „Weil die Website so eingestellt ist, dass Themen nach N Tagen geschlossen werden“ ist eine Antwort darauf, wie das Thema geschlossen wurde, nicht warum.)
Ich denke, um diese Änderung überschaubar zu halten, ist Phase Null trivial:
Füge die Site-Einstellung prioritize_solved_topics mit dem Standardwert true hinzu.
Wenn auf true gesetzt, gib gelösten Themen bedingungslos 1,1.
Das löst nicht alle Eigenheiten hier, aber es würde uns schnell einen angemessenen Fortschritt ermöglichen.
Das Problem ist, dass dies aus Sicht der Erweiterbarkeit keine einfache Änderung ist.
Es gibt keine “solved”-Spalte in der Topics-Tabelle. Was wir hier tun müssen, ist, eine Art Join von “solved” in die Topic-Benutzerdefinierten Felder einzufügen… das bedeutet, dass diese SQL auf eine ziemlich ausgefeilte Weise transformiert werden muss:
Entweder
Wir müssen einen LEFT JOIN in das “solved”-Plugin einfügen LEFT JOIN topic_custom_fields ts where name = 'accepted_answer_id' and value IS NOT NULL AND and topic_id = topics.id
Wir müssen diese Bedingung CASE umwandeln, was wahrscheinlich bedeutet, die gesamte CASE-Anweisung mithilfe eines Plugins komponierbar zu machen.
Alternativ könnten wir mit etwas wie CASE EXISTS(...) THEN 1.1 davonkommen, was die Notwendigkeit eines Left Joins beseitigt, aber eigene Risiken birgt.
Ich werde über dieses Problem nachdenken. Die riesige Herausforderung besteht darin, herauszufinden, wie man durch die Hinzufügung dieser Unterstützung keinen riesigen Durcheinander verursacht, da “core” nichts über gelöste Themen weiß.
Das gilt fast für alle für mich! Ich kann die Spezifikation fast nie herausfinden, bis ich den Code geschrieben habe, von dem ich ziemlich sicher bin, dass er funktioniert. Das liegt (teilweise) daran, dass ich normalerweise Code für eine Spezifikation schreibe, die ich nicht verstehe. Ein paar Mal konnte ich die Spezifikationen zuerst schreiben, wie ein Erwachsener, aber das ist ziemlich selten.
Es ist gut zu hören, dass es dir zumindest manchmal auch passiert.