Wie im unten genannten Beispiel gezeigt, wäre es dort nützlich:
Ich bin mir nicht sicher, ob das eine gute Idee ist. Letztendlich können wir als Benutzer keine Fehler beheben. Das kann nur durch eine Änderung des Discourse-Codes geschehen, und dazu muss ein Teammitglied hinzugezogen werden. Wenn das nicht notwendig ist, ist “Bug” wahrscheinlich nicht die richtige Kategorie.
Ich befürchte, dass Benutzer Workarounds als Lösung markieren werden. Aber dann wäre der Fehler immer noch nicht behoben. Das wäre also verwirrender als hilfreich. In Ihrem Beispiel ist das Problem auch nicht gelöst, da bereits ein Fehlerbericht vorliegt. Ich denke, es ist in diesem Fall am besten, die Themen zusammenzuführen. Auf diese Weise werden alle Benutzer benachrichtigt, wenn es eine Korrektur gibt, unabhängig davon, welchem Thema sie ursprünglich gefolgt sind. Manchmal ist es sinnvoll, ein Thema mit Verweis auf das andere zu schließen, aber dann gehen die Likes, die das geschlossene Thema unterstützt haben, verloren, was traurig ist, wenn betroffene Benutzer durch Likes bestimmt werden.
In der Kategorie Contribute > Bug verwenden wir stattdessen einfach das Tag fixed. Ein Beitrag, der besagt, dass etwas ein Duplikat ist, löst eigentlich nichts, auch wenn er nützlich sein kann, daher denke ich, dass es auch dort keine gute Verwendung gewesen wäre.
Warum wir fixed in einigen Kategorien und solved-plugin in anderen verwenden, liegt meiner Meinung nach wahrscheinlich an dem, was Moin bereits gesagt hat. Tags werden etwas strenger eingesetzt, sodass nur das Team entscheiden kann, wann etwas als behoben gilt.
Vielen Dank für den Vorschlag! Es ist immer gut, die Einrichtung von Kategorien zu überprüfen, daher schätze ich es, dass Sie darüber nachgedacht und dieses Thema eröffnet haben.
Wie Moin und Charlie bereits erwähnt haben, verlässt sich unser Team auf fixed und das Schließen von Themen (Aktionen, die nur uns zur Verfügung stehen), um der Community mitzuteilen, dass ein Fehler behoben wurde! Dies scheint ziemlich gut zu funktionieren und ist eine Möglichkeit für uns, einen ziemlich offensichtlichen Rückstand an zu behebenden Fehlern zu führen.
Es stimmt, dass die Person, die eine Lösung anbieten kann, in der Bug-Kategorie nicht die gleiche Anerkennung erhält, wie sie in Kategorien mit aktiviertem “Solved”-Plugin erhalten würde, was bedauerlich ist. In der Bug-Kategorie erhält die Person, die den Fehler meldet, eine Auszeichnung, wenn sie von einem Mitglied des Discourse-Teams geliked wird. Aber andere, die auf dem Weg helfen, indem sie Reproduktionsschritte angeben, Duplikate aufzeigen, Lösungen vorschlagen usw., erhalten keine Anerkennung. Etwas zum Nachdenken.
In diesem Fall wäre es schön gewesen, wenn Sie Moin dafür hätten anerkennen können, dass er darauf hingewiesen hat, dass der Bericht ein Duplikat ist. Das Beibehalten des Themas erzeugt jedoch auch zusätzlichen Lärm, der das Durchsuchen aller offenen Fehlerberichte für das Team etwas erschwert. Daher hoffe ich, dass es Ihnen nichts ausmacht, aber ich habe einen Timer eingestellt, um es zu löschen.
Das Beibehalten des Themas erzeugt auch zusätzlichen Rausch, der das Parsen aller offenen Fehlerberichte für das Team etwas erschwert. Ich hoffe, es ist Ihnen nichts ausmacht, aber ich habe einen Timer eingestellt, um es zu löschen.
@tobiaseigen, ist dafür nicht die Sperrfunktion da? Das Löschen führt dazu, dass einige externe URIs, die darauf verweisen, 404 ergeben, was nicht ideal ist.
Wir behalten nicht alles!
Machen Sie sich keine allzu großen Sorgen wegen der 404.
Wir arbeiten einfach stattdessen mit dem Tag fixed.
Wir praktizieren das aber überhaupt nicht konsequent, da es zusätzliche Arbeit bedeutet. Ich denke, es hat Vorteile, beim Schließen automatisch mit „fixed“ zu taggen, und für Ausnahmefälle, in denen wir nicht beheben, können wir mit einem speziellen Tag bearbeiten.
Erfordert jedoch einige neue Automatisierungen.
Wenn es gelöscht wird, werden einige externe URIs, die darauf verweisen, zu 404, was nicht ideal ist.
Ich habe mehrmals nach Informationen gesucht, einen Link gesehen, der interessant aussah, aber beim Klicken zu einem 404 führte, was ziemlich enttäuschend war.
In diesem Fall würde ich den Beitrag markieren, der von einem Moderator bearbeitet/entfernt würde.
Um dies zu verhindern, sollten Sie vor dem Löschen eines Themas einen Blick auf den Abschnitt „Links im ersten Beitrag“ werfen:
Und dann präventiv Maßnahmen ergreifen, indem Sie diese Linkreferenzen entfernen, wäre das Beste, aber es würde auch mehr Arbeit erfordern.
Ich denke, es hat Vorteile, beim Schließen automatisch mit „fixed“ zu kennzeichnen, und für Ausnahmefälle, in denen wir nicht reparieren, können wir mit einem speziellen Tag bearbeiten.
Ich habe @tobiaseigen das Gegenteil vorgeschlagen: Beim Hinzufügen des fixed-Tags auch automatisch schließen; genauso wie bei „solved“.
Vielleicht ist die Antwort ein Ja, und? Eine Automatisierung, die sofort das Tag fixed hinzufügt, wenn das Thema geschlossen wird, und das Thema schließt (oder für die Schließung plant), wenn es das Tag fixed trägt? Wir könnten das Gleiche bei Contribute > UX mit den Tags fixed und completed tun.
Gibt es jemals Fälle, in denen wir Themen im Bereich Contribute > Bug schließen, ohne das Tag fixed hinzufügen zu wollen? Mir ist aufgefallen, dass es viele geschlossene Bug-Themen gibt, die dieses Tag nicht haben. Ich werde heute etwas Zeit damit verbringen, das zu erkunden.
Eines, das mir an der Funktionsweise des Solved-Plugins gefallen hat, ist, dass das Thema automatisch 30 Tage nach der letzten Antwort geschlossen wird, sobald eine Lösung ausgewählt ist. Das ist praktisch, weil es nicht abrupt ist und es den Leuten ermöglicht, weiterhin nachzuhaken, falls sie das weiterhin für notwendig halten. Es spart uns wahrscheinlich auch Arbeit, weil die Leute das Thema nicht mehr markieren, um eine Wiedereröffnung zu verlangen.
Automatisierung, die den Tag #fixed:: automatisch hinzufügt, wenn er geschlossen wird, und das Thema schließt (oder für die Schließung plant), wenn es den Tag #fixed:: hat?
Der Grund, warum ich es nicht mag, wenn „geschlossen“ =\u003e automatisch einen Tag hinzufügt, sind die Anwendungsfälle, in denen es nicht behoben wurde oder es sich um ein „wird-nie-behoben“-Problem handelt. Ich denke, eine Aktion („Tag hinzufügen“), die dann automatisch den Timer des Themas auf Schließung nach 30 Tagen setzt, ist der optimale Weg.
Ich habe mich etwas damit beschäftigt und sehe, dass @chapoi die richtige Idee hat. Ich denke, was wir hier tun wollen, ist, es zur Gewohnheit zu machen, behobene Themen mit fixed zu kennzeichnen, und dann eine Automatisierung einzurichten, die einen Timer setzt, um sie automatisch zu schließen – ähnlich wie das Solved-Plugin. Wir können das Thema weiterhin sofort schließen, wenn es angebracht ist, aber in einigen Fällen finde ich es gut, es etwas länger offen zu lassen, um den Leuten die Chance zu geben, zu testen und zurückzumelden, falls sie immer noch Probleme haben.
Es gibt Themen wie Rendering 'TypeError' with theme components after update, die meiner Meinung nach nicht mit fixed gekennzeichnet werden sollten, da der im Eröffnungspost (OP) gemeldete Fehler nicht behoben wurde. In diesem Beispiel gab es keine Reproduktion durch den Ingenieur, der versucht hatte, den Fehler zu beheben.
Dann gibt es noch After deleting a topic, the delete button shows up instead of the restore button, das als Duplikat geschlossen wurde. Ich vermute, wenn Deleting a topic cannot be undone behoben ist, können beide mit fixed gekennzeichnet und geschlossen werden? Aber wie stellen wir sicher, dass das passiert?
Es gibt viele Themen in Contribute > Bug, die geschlossen sind, aber nicht das #fixed-Tag tragen. Wir werden diese rückwirkend durchgehen und prüfen müssen.
Mein Problem ist die Benutzerfreundlichkeit hier. Ich möchte, dass Ingenieure hier eine Ein-Klick-Lösung haben.
- Klicken Sie auf „Behoben“ in den Themenaktionen oder den Admin-Themenaktionen.
- Magie geschieht:
- Ein Thema-Timer wird erstellt, um in 1 Geschäftstag zu schließen
- Das Thema wird mit „behoben“ getaggt.
Ich bin kein Fan der Benutzererfahrung für das reine „Thema taggen“, da dies sehr umständlich ist.
- Navigieren Sie zum Anfang des Themas
- Klicken Sie auf den Titel
- Klicken Sie auf das Tag-Feld
- Suchen Sie nach „behoben“
- Fügen Sie „behoben“ hinzu
- Klicken Sie auf das Kontrollkästchen
Das ist sehr umständlich.
Gerne können wir diesen Ablauf hinzufügen, aber wir benötigen dafür eine Theme-Komponente oder eine Art Automatisierung, die diese Benutzeroberfläche einführt (was auch praktisch sein kann).
Ich bin bei dir! Ich habe auch an die Benutzerfreundlichkeit gedacht, als ich oben „Ja, und“ vorgeschlagen habe. Derzeit haben wir die Gewohnheit, #contribute:bug-Themen einfach zu schließen, sobald sie behoben sind. Das entspricht auch unserer internen Handhabung von Aufgaben.
Ich mag die Idee eines One-Click-„Behoben“-Buttons.
Ich möchte, dass Ingenieure hier eine Ein-Klick-Lösung haben.
Und die Community hat geliefert ![]()
Summary Add tags to a topic with a click of a button
Repository GitHub - NateDhaliwal/quick-add-tags
Install Guide How to install a theme or theme component
New to Discourse Themes? Beginner’s guide to using Discourse Themes Install this theme component This is a component that adds tags to a topic with a button in the topic footer. It also provides the option to auto-close the topic after x days (minimum 0). …
Cool! Ich habe Nate’s Theme-Komponente auf meiner persönlichen Website ausprobiert, und sie tut, was sie verspricht. Sehr gute Arbeit und auch schnell umgesetzt! ![]()
Um sie hier nutzen zu können, müssten wir sie auf eine Kategorie beschränken können. Wenn wir entscheiden, dass dieser Ansatz gut funktioniert, möchten wir auch mehr als einen Button erstellen können.
FYI, Sam arbeitet auch an einer experimentellen Implementierung, die anders und viel flexibler ist und Automatisierung nutzt.
Ich denke, diese Änderung würde uns hier auf Meta ziemlich helfen. Ich habe intern nachgehakt, um zu sehen, ob sie entweder mit Sams experimenteller Implementierung unter Verwendung von Automatisierung oder durch Forken von Nates Theme-Komponente und deren Verwendung hier implementiert werden kann.
Nates Komponente macht im Wesentlichen dasselbe und ist ziemlich gut, aber wir müssten sie forken, da wir keine Drittanbieter-Komponenten oder Plugins auf Meta installieren. ![]()
Nates Komponente macht im Grunde dasselbe und ist ziemlich gut, aber wir müssten sie forken, da wir keine Drittanbieterkomponenten oder Plugins auf Meta installieren.
Wenn Sie das tun, wäre das Ehrenhafte, Nate eine finanzielle Anerkennung anzubieten – so wie Sie es für identifizierte Cybersicherheitsrisiken über HackerOne tun.
Lassen Sie uns dieses Thema darauf konzentrieren, ob die Community von der Verwendung einer Themekomponente wie der von Nate profitieren würde. Wenn ja, werden wir die Mechanik mit Nate klären.
Gerne können wir ein weiteres Thema darüber eröffnen, wie Open-Source-Mitarbeiter für ihre Arbeit im Allgemeinen belohnt werden, wenn Sie möchten.
