Ich möchte etwa 20.000 Gruppen in meiner Discourse-Instanz haben. Ist das überhaupt möglich und würde sich das auf die Leistung der Website auswirken?
2 „Gefällt mir“
Wie viele Nutzer werden Sie haben?
Welches Problem lösen 20.000 Gruppen?
2 „Gefällt mir“
Hier ist das Szenario. Ich benutze Discourse, um eine Diskussionsplattform für Forschungsarbeiten zu realisieren. Jede Arbeit wird mit einem Tag mit der Paper-ID dargestellt. Alle Themen, die unter diesem Tag erstellt werden, erscheinen auf der Tag-Seite für diese Arbeit.
Das Problem ist, dass mir die folgende Funktionalität fehlt:
Ich habe einen manuellen Genehmigungsprozess für Paper-Autoren für die in das System hochgeladenen Arbeiten. Ich möchte ihnen die Möglichkeit geben, Beiträge zu bearbeiten, die mit ihrer Arbeit getaggt sind. Aber ich habe erfahren, dass es nicht möglich ist, Berechtigungen basierend auf Tags zu vergeben.
Dann kam mir die Idee, eine Gruppe pro Arbeit zu haben und die Autoren einer Arbeit derselben Gruppe zuzuordnen. Aber ich bin mir nicht einmal sicher, ob dies mein Problem löst, da ich nicht sicher bin, wie ich die Möglichkeit geben kann, bestimmte Beiträge zu bearbeiten.
Ich würde mich freuen, wenn es eine elegante Möglichkeit gibt, diese Funktionalität zu realisieren. Danke.
3 „Gefällt mir“
Möchten Sie, dass der Autor die Beiträge anderer Personen bearbeiten kann, wenn es sich um eine Antwort auf seine Arbeit handelt?
Und meinen Sie Beiträge und nicht Themen?
Ja, ob ein Beitrag eine Antwort ist oder sich auf ihre Arbeit bezieht, wird derzeit durch das Tag bestimmt.
Aber ich kann auch eine Gruppe pro Arbeit erstellen, wenn das hilfreich ist.
Und idealerweise sollten sowohl Beiträge als auch Themen bearbeitbar sein.
Gruppen sind sehr schlank, Sie können problemlos viele Tausende davon erstellen.
Auf der anderen Seite werden 20.000 Kategorien ein Leistungsproblem darstellen.
10 „Gefällt mir“
Beiträge haben keine Tags, Themen schon.
Ich verstehe nicht, warum Sie möchten, dass Leute die Beiträge anderer bearbeiten können. Sie können sie zu Wikis machen, aber dann kann jeder sie bearbeiten.
Oder vielleicht möchten Sie, dass das Benutzerthema ein Wiki ist, damit jeder es bearbeiten kann.
Ich verstehe einfach nicht, was das Modell ist, in dem es Sinn macht, die Worte eines anderen zu ändern.
2 „Gefällt mir“
Ich begann auch, die Vorteile der Bearbeitung zu hinterfragen, nachdem ich mehrere Szenarien in Betracht gezogen hatte. Es wäre jedoch schön, einen Mechanismus zu haben, um zu sehen, ob eine antwortende Person der Autor des Papiers ist, auf das sich das Thema bezieht, und ich denke, das ist mit Gruppen immer noch nicht möglich.
Genauer gesagt: Nehmen wir an, ein Benutzer hat einen Beitrag erstellt, der das Papier mit der ID 5 markiert. Wenn der Autor des Papiers 5 eine Antwort auf dieses Thema postet: Die ideale Funktionalität wäre, irgendwie anzuzeigen (kann ein Flair, ein Titel, ein kleiner Standardtext oben im Beitrag sein), dass der antwortende Benutzer der Autor des diskutierten Papiers ist.
Wenn jedes Paper ein Thema ist und Sie den OP des Themas dem Autor zuweisen, ist es trivial, eine CSS-Regel zu erstellen, um Antworten des OP auf seine weiteren Antworten visuell zu unterscheiden.
1 „Gefällt mir“
Warum nicht einfach ein Thema pro Artikel? Dann gibt es keine Verwirrung. Sie bräuchten keine Tags oder Gruppen.
Außerdem scheinen Sie den Discourse-Begriff Thema (eine Sammlung von Beiträgen) und einen Beitrag (eine einzelne Nachricht einer einzelnen Person, die sich in einem Thema befindet) zu vermischen.
Aber jetzt war @falco schneller als ich…
1 „Gefällt mir“
@pfaffman @falco Technisch gesehen ist jede Arbeit ein Tag. Der Grund dafür ist, dass ein Thema nicht ausreicht, um alle Diskussionen oder Fragen zu einer Arbeit zu haben. Es gibt viele verschiedene Aspekte zu diskutieren, und die Hauptmotivation dieses Forums ist es, eine einzige Quelle für alle Diskussionen zu haben, die rund um eine Arbeit stattgefunden haben. Daher ist jede Arbeit ein Tag und alle unter dem Tag einer Arbeit erstellten Themen können von der Seite /tag/:paper_id aus eingesehen werden.
Ist es möglich, den CSS-Trick in diesem Szenario durchzuführen? Ich kann eine externe Datenbank erstellen, die die Beziehung zwischen den Tags und ihren jeweiligen „Autorbenutzern“ definiert, falls erforderlich.
1 „Gefällt mir“
Ja, Sie könnten eine CSS-Datei haben, die automatisch aus dem Parsen der genannten Datenbank generiert wird.
Sie könnten dies auch alles in Discourse tun, indem Sie ein benutzerdefiniertes Plugin verwenden. Es würde ein zusätzliches Feld im Topic-Serializer für Beiträge bringen, bei denen der Autor des Beitrags übereinstimmt, was dann von der Frontend-Anwendung genutzt werden kann.
1 „Gefällt mir“
Ich verstehe, ich bin ziemlich neu bei Plugins, aber ich werde versuchen zu sehen, was getan werden kann. Vielen Dank für den Rat!
2 „Gefällt mir“
Fühlen Sie sich frei, Themen auf Dev zu eröffnen, wenn Sie nicht weiterkommen.
1 „Gefällt mir“
Sie verstehen also, dass Topics Tags haben, nicht Beiträge. Ich glaube, Sie verwenden das Wort „Beitrag“, wenn Sie „Topic“ meinen.
Ich glaube nicht, dass Sie das beantwortet haben. Wenn Sie nicht möchten, dass Leute die Beiträge anderer bearbeiten, haben Sie wahrscheinlich kein Problem. Ich kann mir nicht vorstellen, warum Sie möchten, dass Leute die Beiträge anderer bearbeiten, aber wenn Sie das tun, könnte die Umwandlung in ein Wiki die Lösung sein.
Das Markieren von Topics, die sich auf ein bestimmtes Paper beziehen, mit einem Tag des Papers (wie einer DOI, aber vielleicht gibt es zu diesem Zeitpunkt im Leben des Papers noch keine DOI) ist eine großartige Idee und Sie können dies jetzt mit der API tun. Außerdem können Benutzer, die das Topic bearbeiten können (trust_level 3 und der Besitzer des Topics), den Tag hinzufügen; andere können es melden und darum bitten, dass es getaggt wird (aber weiß nicht derjenige, der das Topic gestartet hat, dass es sich um das Paper handelt?).
Ich bin mir nicht sicher, wofür Sie an dieser Stelle ein Plugin benötigen.
Könnten Sie etwas darüber sagen, wo die Leistungsprobleme auftreten würden? D.h. sind es bestimmte Seiten oder ein allgemeines Problem? Wenn jede Kategorie mit ein oder zwei Gruppen verknüpft ist und der durchschnittliche Benutzer nur Zugriff auf insgesamt 10-20 Kategorien hat, ist es dann immer noch ein Problem, 20.000 Kategorien zu haben?
Für meinen (hypothetischen) Anwendungsfall geht es darum, öffentliche Themen über Gruppen-PMs zu diskutieren. Dieser Ansatz könnte auf verschiedene Weise genutzt werden, um produktive öffentliche Diskussionen über polarisierende Themen zu generieren. Im Wesentlichen könnten Diskussionen gamifiziert werden, indem die Leute gebeten werden, Teams (Gruppen) zu einem bestimmten Thema beizutreten und dann eine Reihe von Regeln zu befolgen, um als Team auf das öffentliche Thema zu antworten.
Ich bin bereit, mich mit den UI-Problemen auseinanderzusetzen, die Tausende von Gruppen für das Personal der Website verursachen könnten. Mir ist bewusst, dass dies ein unerwarteter Anwendungsfall für Discourse-Gruppen ist, daher poste ich dies hier, falls es offensichtliche Leistungsprobleme gibt, die ich übersehe.
1 „Gefällt mir“
Das ergibt mehr Sinn, als ich erwartet hatte. 
Ich glaube, es gibt eine Funktion für benutzerdefinierte Gruppen in der Pipeline, aber ich vermute, sie ist noch weit entfernt.
1 „Gefällt mir“
Das wäre großartig, aber im Moment kann es mit der API gemacht werden.
1 „Gefällt mir“
Oooh. Ich schweife hier ab, aber Sie könnten eine dieser API-Sachen verwenden, die einen Webhook für jedes neue Thema empfangen und dann eine Gruppe dafür erstellen. Kein Plugin erforderlich. Ich weiß nicht, warum ich nicht daran gedacht hatte, Discourse auf beiden Seiten eines dieser Dienste zu haben.
Und GitHub - triggerdotdev/trigger.dev: Trigger.dev – build and deploy fully‑managed AI agents and workflows ist mir heute über den Weg gelaufen. Es scheint, dass Sie es die Arbeit machen lassen könnten, anstatt einen dieser Dienste zu bezahlen. Ich bezweifle, dass es Discourse out-of-the-box unterstützt, aber es sollte einfach genug sein, um es zum Laufen zu bringen.
1 „Gefällt mir“