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 Bug arbeiten wir stattdessen nur mit dem Tag fixed. Ein Beitrag, der besagt, dass etwas ein Duplikat ist, löst nichts wirklich, obwohl er nützlich ist, daher glaube ich nicht, dass er dort auch gut eingesetzt worden wäre.
Warum wir in einigen Kategorien fixed und in anderen das solved-plugin verwenden, denke ich, liegt wahrscheinlich daran, was Moin bereits gesagt hat. Tags sind in der Anwendung etwas strenger, daher kann nur das Team entscheiden, wann etwas behoben ist.
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? Automatisierung, die den #fixed-Tag sofort hinzufügt, wenn er geschlossen wird, und das Thema schließt (oder zur Schließung plant), wenn es den #fixed-Tag hat? Wir könnten dasselbe in UX mit den Tags fixed und completed tun.
Gibt es jemals Fälle, in denen wir #bug-Themen schließen, ohne den #fixed-Tag hinzufügen zu wollen? Ich sehe, dass viele Bug-Themen geschlossen sind, aber den Tag nicht haben. Ich werde heute etwas Zeit damit verbringen, das zu untersuchen.
Eine Sache, die mir am Verhalten des “solved”-Plugins gefallen hat, ist, dass, wenn eine Lösung ausgewählt wird, das Thema so geplant wird, dass es 30 Tage nach der letzten Antwort automatisch geschlossen wird. Das ist praktisch, weil es abrupt ist und es den Leuten immer noch erlaubt, nachzufassen, falls sie es immer noch für notwendig halten. Es spart uns wahrscheinlich auch Arbeit, weil die Leute das Thema nicht melden werden, um es wiedereröffnet zu bitten.
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 etwas Zeit damit verbracht und sehe, dass @chapoi die richtige Idee hat. Ich denke, was wir hier tun wollen, ist, uns anzugewöhnen, Elemente mit fixed zu markieren, die behoben wurden, und dann eine Automatisierung zu erstellen, die einen Timer setzt, um sie automatisch zu schließen, ähnlich dem “solved”-Plugin. Wir können das Thema immer noch sofort schließen, wenn es angebracht ist, aber in einigen Fällen denke ich, dass es gut ist, es etwas länger offen zu lassen, um den Leuten die Möglichkeit zu geben, es zu testen und zurückzumelden, ob sie immer noch ein Problem haben.
Es gibt Themen wie Rendering 'TypeError' with theme components after update, die meiner Meinung nach nicht den Tag fixed erhalten sollten, da der im OP gemeldete Fehler nicht behoben wurde. In diesem Beispiel gab es keine Reproduktion von dem Ingenieur, der versucht hat, es zu beheben.
Es gibt auch After deleting a topic, the delete button shows up instead of the restore button, das als Duplikat geschlossen wurde. Ich schätze, wenn Deleting a topic cannot be undone behoben ist, können beide als fixed markiert und geschlossen werden? Aber wie stellen wir sicher, dass das passiert?
Es gibt viele Themen in Bug, die geschlossen sind, aber nicht den Tag fixed haben. Wir werden diese rückwirkend durchgehen und uns ansehen wollen.
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 über die Benutzerfreundlichkeit nachgedacht, als ich oben „Ja, und“ vorgeschlagen habe. Derzeit haben wir die Gewohnheit, #bug-Themen einfach zu schließen, wenn sie behoben sind. Dies entspricht auch der Art und Weise, wie wir intern mit Todos umgehen.
Ich mag die Idee eines „Behoben“-Buttons mit einem Klick.
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.
