Es fühlt sich ein wenig seltsam an, eine Kategorie danach auszuwählen, „wer es am wahrscheinlichsten repariert“. Würden Sie auch sagen, dass ein leeres Forum aufgrund eines globalen display: none kein Fehler ist, weil ein Designer es reparieren wird?
Und natürlich können Sie sagen: „Es spielt keine Rolle, wählen Sie einfach eine aus, wir können sie verschieben“, aber das hilft nur beim Posten. Wenn ich versuche, frühere Berichte zu finden, würde ich nach beiden Problemen in UX suchen. Wäre es möglich, die Verantwortung für die Behebung unabhängig von den Kategorien zu verfolgen?
10 „Gefällt mir“
Ich bin bei Ihnen, das ist extra verwirrend, es ist sehr schwer für die Bediener zu wissen, was sie hier tun sollen.
@tobiaseigen / @jordan.vidrine Haben Sie Gedanken zu diesem Problem?
@Moin Haben Sie Vorschläge, wie das besser funktionieren könnte?
Ich schätze, eine Alternative ist, einfach Dinge bedingungslos in Feature/Bug zu legen und Tags zu verwenden, um UX zu bezeichnen.
Es ist sicherlich eine schwierige Sache.
4 „Gefällt mir“
Das scheint mir eine gute Lösung zu sein. Es ist offensichtlich, in welche Kategorie man posten soll, und diejenigen, denen UX wichtig ist, können dieses Tag beobachten. Ein weiterer Vorteil ist, dass wir eine Kategorie eliminieren können!
Ich bin mir nicht sicher, wie man die Themen, die derzeit unter UX aufgeführt sind und wahrscheinlich unter Bug oder Feature fallen würden, auseinandernehmen soll. Es könnte eine gute Übung sein, das alles durchzugehen und aufzuräumen.
4 „Gefällt mir“
Einige Gedanken von meiner Seite:
- Ich glaube, dass die Aufteilung von über 3000 Themen in nur 2 Kategorien sehr viel Arbeit ist, und ich frage mich, wer die Zeit haben wird, diese Aufgabe zu übernehmen.
- Darüber hinaus glaube ich nicht, dass alle Themen in UX leicht in Feature und Bug unterteilt werden können. Für mich ist ein Bericht über einen Text, der nicht übersetzt werden kann, kein wirklicher Bug-Report[1]. Ebenso ist das Aufzeigen eines unverständlichen oder veralteten Textes weder eine Feature-Anfrage noch ein Bug-Report[2]. Ebenso passen Beschreibungen von Benutzererfahrungen, die weder einen Fehler noch einen konkreten Verbesserungsvorschlag enthalten, weder in Feature noch in Bug[3].
- Ich weiß nicht, wie Sie das bisher gehandhabt haben, aber ich hatte den Eindruck, dass Entwickler bei Bedarf auch an UX-Themen gearbeitet haben und umgekehrt. Ich frage mich, ob es möglich wäre, die Dinge so zu belassen, wie sie waren, wobei die Gruppe, die die Kategorie überwacht, die andere Gruppe bei Bedarf einfach informiert, ohne den Beitrag zu verschieben. Dies kann ich jedoch nicht vollständig beurteilen, da ich die Prozesse vorher oder jetzt nicht kenne.
5 „Gefällt mir“
Danke Moin! Du hast einige gute Punkte. Ich habe mir auch die Gesamtzahl der #ux-Themen angesehen und es sind viele! 
Vielleicht liegt das Problem, das wir haben, darin, dass die #ux-Kategorie unzureichend beschrieben ist und die Leute dort Dinge posten, die in Bug oder Feature gehören. Hier ist, wie wir sie in unserer internen Dokumentation beschreiben.
Die Kategorie UX ist eine Art Zwischenstation zwischen Feature und Bug. Im Allgemeinen würden kleinere Anzeigeprobleme hierher gehören und nicht in Bug, und es wäre die Anlaufstelle für kleine Änderungen an bestehenden Funktionen. Eher „Quality of Life“-Themen als etwas Großes.
Im Allgemeinen folgt die Behandlung dieser Themen dem Muster der Kategorie Feature - Über die Feature-Kategorie
Tagging
hmmm, diesen würde ich als Fehler einstufen… rein praktisch gesehen, aber er wird von mir viel häufiger getriagt, da UX mehr vage Dinge anzieht.
In diesem Fall sieht das Badge-Problem für mich wie ein Übersetzungsfehler aus.
Eigentlich fühlt sich das auch wie ein Fehler an, nichts ist hier der Interpretation überlassen, unser Text ist schlichtweg falsch und muss aktualisiert werden.
Das ist aber sehr im Thema UX für mich, es ist eine offene Diskussion über einen Pain Point ohne konkrete Empfehlungen. Es gibt uns eine Geschichte und einen Ort, um daraus in Zukunft bestimmte Fehler-/Feature-Themen zu extrahieren.
Vielleicht brauchen wir hier nur die Regeln besser zu klären, UX für offene, unstrukturierte Diskussionen und User Stories zu überlassen und “klare Mängel” im Bug-Bereich zu belassen … und “klare Wunschlisten” im Feature-Bereich.
Ich verstehe, dass alles in dieser Welt sehr grau ist, es ist schwer, mit einem Zauberstab alles zu reparieren.
Klarere Erwartungen zu formulieren, wird aber sicher helfen.
7 „Gefällt mir“
Ihr umgeht jetzt die Benutzer. Wir können nicht (und werden nicht) wissen, wie ein Unternehmen Dinge zuweist oder klassifiziert. Das ist eine rein interne Angelegenheit. Alles, was wir tun können, ist zu raten, ob etwas ein Fehler, ein UX-Problem oder etwas völlig anderes ist. Und Moderatoren und Mitarbeiter machen danach ihre Magie, wie es im Kern von Discourse geplant ist.
Ist dieses Thema also tatsächlich für Mitarbeiter und Power-User, und wir anderen Sterblichen können aufhören, es zu verfolgen, oder denkt wirklich jemand, dass ich, der den Unterschied zwischen einem Bild und einem Bild nicht kennt, je nachdem, ob etwas auf Dateiebene oder Containerebene passiert, die Fähigkeit hat, sich zu fragen, welche Position innerhalb von CDCK sich um ein Problem kümmern wird?
Auf einer allgemeineren Ebene gibt es hier mindestens zwei Aspekte (wie jeder weiß):
- Kategorien sind keine logischen Boxen mit strengen Grenzen
- Für welche Benutzer sind die Kategorien gemacht, öffentlich oder intern
Ich weiß nicht… Ich habe die Richtlinie befolgt, wo ich verwende
- Support, wenn ich nicht weiß, ob das Problem bei mir liegt,
- UX, wenn ich das Gefühl habe, dass etwas so geplant ist
- Bug, wenn etwas aufhört zu funktionieren oder Orte komplett kaputt macht
Aber ich werde niemals eine Kategorie wählen, je nachdem, wer in welcher Position versucht, sich darum zu kümmern. Das ist rein eine Managementfrage.
2 „Gefällt mir“
Ich mag die Idee von UX als Tag (und vielleicht auch Dev als Tag?), aber ich stimme zu, dass es UX-Fälle geben könnte, die sich anfühlen, als ob sie nicht wirklich in eine andere Kategorie passen würden.
Und einige Themen können technisch gesehen ein Feature sein, aber so klein, dass sie in der Kategorie “Feature” zur Abstimmung fehl am Platz wären, zum Beispiel: Clickable components instead of just the Edit button
Aber vielleicht sollten wir uns darum nicht kümmern? Und jedes Problem, das eine Änderung verlangt, gehört in die Kategorie “Feature”, egal wie klein?
Oder vielleicht sollten wir eine Kategorie “Vorschläge” haben – für Dinge, die nicht kaputt sind, keine vollwertige Feature-Anfrage sind und nicht darum gehen, wie man Dinge tut. Und dann können wir es intern als Dev oder UX taggen.
Edit: Mir ist bewusst, dass wir bereits einen UX-Tag haben, er wird nur im Moment wenig genutzt.
4 „Gefällt mir“
Eine Kategorie Vorschläge scheint wichtig zu sein. Ich habe sie in meinen 2 Communities.
Manchmal kann ein Tag übersehen werden oder die #ux-Kategorie ist für bestimmte Benutzer möglicherweise nicht so klar, aber eine Kategorie Vorschläge ist ziemlich klar, wofür sie gedacht ist.
1 „Gefällt mir“
Ich glaube wirklich nicht, dass wir hier viel an den Kategorien ändern müssen, sie funktionieren schon seit einer Weile gut und Fehlkategorisierungen passieren, aber nicht in einem belastenden Ausmaß, soweit ich das beurteilen kann. Wenn Erwähnungen, Tags und Zuweisungen für die interne Triage nicht ausreichen, fühlt es sich an, als ob etwas schief läuft … denn wir haben dort viele Optionen.
2 „Gefällt mir“
Wenn ich tief grabe, bin ich mir nicht sicher, @moin 
Ich denke, der Kern des Problems hier ist:
- Sam ordnet etwas von UX → Bug neu zu
- Sam weiß, wie sich jede Berührung von Beiträgen anderer auf sie auswirken kann, dass sie sich schlecht fühlen oder das Gefühl haben, einen Fehler gemacht zu haben
- Sam entschuldigt sich
- Dann werden Benutzer verwirrt, wollen sich selbst korrigieren, und es gibt einen schmerzhaften Kreislauf.
Vielleicht ist das eigentliche Problem hier?
Sam sollte sich frei fühlen, neu zu kategorisieren, wie er es für richtig hält, um unsere Geschäftsanforderungen besser zu erfüllen, und sollte sich nicht jedes Mal entschuldigen, wenn er das tut?
2 „Gefällt mir“
Ich denke seit mehreren Wochen über dieses Thema nach, während ich an Diskussionen teilnehme, Themen in den Kategorien UX, Bug und Feature anspreche und eigene Themen erstelle.
Ich denke, das ist definitiv der Fall. Sam und Mitglieder des Teams können Themen nach eigenem Ermessen kategorisieren und taggen, um auf das Thema zu reagieren und eine Lösung zu finden. Wenn Mitglieder über diese Entscheidungen verwirrt sind, können sie sich an @moderators wenden.
Dies ist ein großartiges Beispiel für ein Thema, das zu UX gehört. Es ist klein und es geht speziell darum, die Benutzeroberfläche zu verbessern. Es ist auch ein großartiges Beispiel für die Art von Zusammenarbeit zwischen Community-Mitgliedern und dem Team, die wir uns wünschen und die zu sehr schönen Verbesserungen der Lebensqualität führt. 
Um auf das von Charlie genannte Beispiel zurückzukommen: Ein Bereich, in dem unser Team arbeiten muss, ist die Verfolgung solcher Themen bis zum Ende, damit sie geschlossen werden können. Selbst diese recht exzellente Zusammenarbeit hatte einige lose Enden. Dies ist natürlich im Auf und Ab der Diskussion und Zusammenarbeit hier, und unsere Ingenieure und Designer sind beschäftigt. Infolgedessen fallen UX-Verbesserungen manchmal durchs Raster, egal wie gut der Vorschlag ist oder wie klein die Anfrage erscheint. Nach einer Weile können @moderators helfen, diese zu identifizieren und nach Hause zu bringen.
Ich habe die Beschreibung für die Kategorie UX aktualisiert, um öffentlich zu machen, was unser interner Ansatz für diese Kategorie war. Ich hoffe, dies wird allen helfen, besser zu verstehen, was in UX im Gegensatz zu anderen Kategorien Feature und Bug hineingehört.
Diskussion über kleine Anzeigeprobleme und kleine Änderungen an der Discourse-Benutzeroberfläche und wie Features präsentiert werden (einschließlich Sprache und UI-Elemente). Eher „Quality of Life“-Themen als alles Große.
Die Tags completed oder fixed werden je nach Art des Themas auf Themen in dieser Kategorie angewendet.
Lassen Sie mich wissen, ob dies nicht klar genug ist oder ob Sie weitere Verfeinerungen vorschlagen können. Ich möchte Bug und Feature die gleiche Behandlung zukommen lassen, werde dies aber vorerst zurückstellen.
Ich denke, wir sollten auch den Tag „ux“ häufiger verwenden. Das wäre meiner Meinung nach hilfreich für die Triage. Etwas kann ein Support- oder Bug-Thema sein, aber sich auf UX beziehen. Dies würde auch den Zweifel lösen: „Das ist ein Bug, aber es ist etwas Visuelles, sollte es unter Bug oder UX stehen?“
=> Machen Sie es zu einem Bug, aber versehen Sie es mit einem #ux::tag-Tag
Ich denke, die Kategorie UX sollte hauptsächlich Vorschläge für Verbesserungen und Dinge enthalten, die unklar sind. Nicht Dinge, die kaputt sind.
Zumindest diese Unterscheidung macht für mich Sinn.
3 „Gefällt mir“
Ich stimme zu, dass wir den #ux::tag-Tag in allen drei Kategorien häufiger verwenden sollten! Leute, denen UX sehr am Herzen liegt, können diesen Tag dann verfolgen.
Es scheint, dass wir uns noch nicht ganz einig sind – meiner Meinung nach kann UX sowohl Fehler als auch Funktionsanfragen enthalten, aber es muss sich um kleine „Quality-of-Life“-Verbesserungen handeln und nichts Großes. Wenn etwas in der Benutzeroberfläche wirklich kaputt ist, gehört es in Bug. Wenn es sich um ein großes Projekt handelt (z. B. das Bearbeiten der Meta-Beschreibung eines Tags), gehört es in Feature.
Wie würden Sie die Beschreibung der #ux-Kategorie verbessern, um Ihr Verständnis der Dinge widerzuspiegeln?
Gute Frage. Ich würde sagen, so etwas wie…
Ein UX-Thema wird verwendet, wenn das Produkt technisch wie vorgesehen funktioniert, aber das Design, die Interaktion oder der Ablauf unnötige Reibung, Verwirrung oder Ineffizienz für die Benutzer verursachen.
Ich bin auch damit einverstanden, dass es Folgendes enthält:
Aber ich denke, alles, was tatsächlich kaputt ist, selbst wenn es klein ist, sollte einfach ein Fehler mit einem UX-Tag sein.
3 „Gefällt mir“
Wie wäre es damit für eine neue #ux-Beschreibung? Fühlt sich etwas steif an, aber straffer. Ich denke, es funktioniert? (Ich habe ein eigenes #ux-Thema Thema gepostet, um zu melden, dass Tags in Kategoriebannern nicht richtig angezeigt werden)
Original:
Diskussion über die Benutzeroberfläche von Discourse und wie Funktionen präsentiert werden (einschließlich Sprache und UI-Elemente).
Aktuell:
Diskussion über kleinere Anzeigeprobleme und kleine Änderungen an bestehenden Funktionen der Discourse-Benutzeroberfläche und wie Funktionen präsentiert werden (einschließlich Sprache und UI-Elemente). Mehr „Quality of Life“-Themen als alles andere.
completed oder fixed werden je nach Art des Themas auf Themen in dieser Kategorie angewendet.
Vorschlag neu:
UX-Themen werden verwendet, wenn Discourse technisch wie vorgesehen funktioniert, aber das Design, die Interaktion oder der Ablauf unnötige Reibung, Verwirrung oder Ineffizienz für Benutzer verursachen. Auch für kleine „Quality of Life“-Verbesserungen. completed oder fixed werden je nach Art des Themas angewendet.
1 „Gefällt mir“
Danke, klingt gut für mich 
Cool! Ich habe die Änderung vorgenommen.
(Nebenbemerkung: Es ist so seltsam, dass Änderungen an der Beschreibung ein paar Minuten brauchen, um im Kategoriebanner angezeigt zu werden. Selbst ein Hard Refresh hilft da nicht.)
2 „Gefällt mir“