Es fühlt sich etwas seltsam an, eine Kategorie basierend darauf zu wählen, „wer am ehesten die Behebung vornehmen wird“. Würdest du auch sagen, dass ein leeres Forum aufgrund eines globalen display: none kein Bug ist, weil ein Designer es behebt?
Natürlich kann man sagen: „Es ist egal, wähle einfach eine Kategorie, wir können sie später verschieben.“ Aber das hilft nur beim Posten. Wenn ich nach früheren Berichten suche, würde ich nach beiden dieser Probleme in Contribute > 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 klar, in welche Kategorie man posten soll, und diejenigen, die sich für UX interessieren, können dieses Tag beobachten. Ein weiterer Vorteil ist, dass wir eine Kategorie eliminieren können!
Ich bin mir nicht sicher, wie ich die Themen in Contribute > UX aufschlüsseln soll, die wahrscheinlich in Contribute > Bug oder Contribute > Feature gehören würden. Es könnte eine gute Übung sein, sich 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 bringst einige gute Punkte ein. Ich habe mir auch die Gesamtzahl der Themen in Contribute > UX angesehen, und das ist wirklich eine ganze Menge! 
Vielleicht liegt das Problem darin, dass die Kategorie Contribute > UX unzureichend beschrieben ist, sodass Leute dort Dinge posten, die eigentlich in Contribute > Bug oder Contribute > Feature gehören. So beschreiben wir sie in unserer internen Dokumentation.
Die Kategorie #ux::category ist sozusagen eine Art Zwischenlösung zwischen #feature::category und #bug::category. Im Allgemeinen gehören kleinere Anzeigeprobleme hierher statt in #bug::category, und sie ist die Heimat für kleinere Änderungen an bestehenden Funktionen. Es geht eher um Themen zur „Lebensqualität“ als um große Veränderungen.
Im Allgemeinen sollte die Bearbeitung dieser Themen dem Muster der Kategorie #feature::category folgen – Ü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 beiden Communities.
Manchmal kann ein Tag übersehen werden oder die Kategorie Contribute > UX ist für bestimmte Nutzer möglicherweise nicht so klar, aber eine Kategorie Vorschläge macht ihren Zweck ziemlich deutlich.
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.
3 „Gefällt mir“
Wenn ich tiefer grabe, bin ich mir nicht sicher, @moin 
Ich denke, der Kern des Problems hier ist:
- Sam kategorisiert etwas von Contribute > UX nach Contribute > Bug um
- Sam weiß, wie sehr das Berühren von irgendetwas an den Beiträgen anderer Personen diese schlecht fühlen lassen oder das Gefühl geben kann, einen Fehler gemacht zu haben
- Sam entschuldigt sich
- Dann sind die Nutzer verwirrt, wollen sich selbst korrigieren, und es entsteht ein schmerzhafter Kreislauf.
Vielleicht ist das Wurzel-problem hier?
Sam sollte frei sein, die Kategorisierung nach eigenem Ermessen vorzunehmen, um unseren geschäftlichen Bedürfnissen besser gerecht zu werden, und sollte sich nicht jedes Mal dafür entschuldigen, wenn er das tut?
2 „Gefällt mir“
Ich habe in den letzten Wochen über dieses Thema nachgedacht, während ich an Diskussionen teilgenommen, Themen in den Kategorien Contribute > UX, Contribute > Bug und Contribute > Feature behandelt und eigene Themen erstellt habe.
Ich bin der Meinung, dass dies definitiv zutrifft. Sam und die Teammitglieder sind frei, Themen zu kategorisieren und zu taggen, wie sie es für angebracht halten, um auf die Themen zu reagieren und zu einer Lösung zu gelangen. Falls Mitglieder über diese Entscheidungen verwirrt sind, können sie sich an @moderators wenden.
Dies ist ein hervorragendes Beispiel für ein Thema, das in Contribute > UX gehört. Es ist klein und dreht sich speziell um eine Verbesserung der Benutzeroberfläche. Es ist auch ein großartiges Beispiel für die Art der Zusammenarbeit zwischen Community-Mitgliedern und dem Team, die wir gerne sehen und die zu sehr schönen Verbesserungen der Lebensqualität führt. 
Fortsetzung des von Charlie zitierten Beispiels: Ein Bereich, an dem unser Team arbeiten muss, ist die Verfolgung solcher Themen bis zum Ende, damit sie geschlossen werden können. Selbst diese hervorragende Zusammenarbeit wurde mit einigen offenen Enden zurückgelassen. Dies ist im Fluss der Diskussion und Zusammenarbeit hier natürlich, und unsere Entwickler und Designer sind beschäftigt. Daher rutschen UX-Verbesserungen manchmal durchs Raster, egal wie gut der Vorschlag ist oder wie klein die Anfrage wirkt. Nach einiger Zeit können @moderators dabei helfen, diese zu identifizieren und sie ins Ziel zu führen.
Ich habe die Beschreibung der Kategorie Contribute > UX aktualisiert, um unseren internen Ansatz für diese Kategorie öffentlich zu machen. Ich hoffe, dies wird allen helfen, besser zu verstehen, was in Contribute > UX im Vergleich zu anderen Kategorien wie Contribute > Feature und Contribute > Bug gehört.
Diskussion über kleine Darstellungsprobleme und kleine Änderungen in der Discourse-Benutzeroberfläche sowie darüber, wie Features präsentiert werden (einschließlich Sprache und UI-Elemente). Eher Themen zur „Lebensqualität“ als große Änderungen.
Die Tags completed oder fixed werden je nach Art des Themas auf Themen in dieser Kategorie angewendet.
Lassen Sie mich wissen, wenn dies nicht klar genug ist oder wenn Sie weitere Verbesserungen vorschlagen können. Ich möchte Contribute > Bug und Contribute > Feature ebenfalls so behandeln, werde dies aber vorerst zurückstellen.
Ich finde, wir sollten das „ux“-Tag auch häufiger verwenden. Das wäre meiner Meinung nach hilfreich, um Themen zu priorisieren. Etwas kann zwar ein Support- oder Bug-Thema sein, betrifft aber die UX. Damit ließe sich auch die Unsicherheit klären: „Das ist ein Bug, aber er ist visueller Natur – sollte er in Contribute > Bug oder in Contribute > UX landen?“
=> Als Bug markieren, aber mit dem #ux::Tag versehen.
Meiner Ansicht nach sollte die Kategorie Contribute > UX hauptsächlich Vorschläge für Verbesserungen und Unklarheiten enthalten, nicht aber Dinge, die kaputt sind.
Zumindest ergibt diese Unterscheidung für mich Sinn.
3 „Gefällt mir“
Ich stimme zu, dass wir das Tag ux häufiger verwenden sollten, in allen drei Kategorien! Leute, die sich sehr für UX interessieren, können dieses Tag dann abonnieren.
Allerdings scheinen wir uns noch nicht ganz einig zu sein – meiner Meinung nach kann Contribute > UX sowohl Bugs als auch Feature-Anfragen enthalten, aber es müssen kleine „Quality-of-Life“-Verbesserungen sein und nichts Großes. Wenn etwas in der Benutzeroberfläche wirklich kaputt ist, gehört es in Contribute > Bug. Wenn es sich um ein größeres Projekt handelt (z. B. das Bearbeiten der Meta-Beschreibung eines Tags), dann gehört es in Contribute > Feature.
Wie würdest du die Beschreibung der Kategorie Contribute > UX verbessern, um dein 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 mit dieser Beschreibung für Contribute > UX? Sie wirkt etwas steif, ist aber kompakter. Ich denke, sie passt? (Ich habe ein eigenes Thema unter Contribute > UX erstellt, um zu melden, dass Tags in Kategorien-Bannern nicht korrekt angezeigt werden.)
Original:
Diskussion über die Benutzeroberfläche von Discourse und die Darstellung von Funktionen (einschließlich Sprache und UI-Elementen).
Aktuell:
Diskussion über kleinere Anzeigeprobleme und kleine Änderungen an bestehenden Funktionen in der Discourse-Benutzeroberfläche sowie über die Darstellung von Funktionen (einschließlich Sprache und UI-Elementen). Mehr Themen zur „Lebensqualität“ als große Neuerungen.
Tags wie completed oder fixed werden je nach Art des Themas auf Themen in dieser Kategorie angewendet.
Vorgeschlagene neue Version:
UX-Themen werden verwendet, wenn Discourse technisch wie beabsichtigt funktioniert, das Design, die Interaktion oder der Ablauf jedoch unnötige Reibung, Verwirrung oder Ineffizienz für die Nutzer verursacht. Auch für kleine Verbesserungen der „Lebensqualität“. Tags wie 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“