It feels a little weird to choose a category based on “who is most likely to fix it”. Would you also say a blank forum because of a global display: none isn’t a bug because a designer will fix it?
And of course you can say “it doesn’t matter, simply select one, we can move it” but this only helps for posting. When I try to find prior reports I would search for both of these issues in UX. Would it be possible to track responsibility for fixing independently from categories?
10 לייקים
אני איתך, זה מבלבל במיוחד, קשה מאוד למפעילים לדעת מה לעשות כאן.
@tobiaseigen / @jordan.vidrine יש לכם מחשבות על הבעיה הזו?
@Moin יש הצעות כיצד זה יכול לעבוד טוב יותר?
אני מניח שחלופה אחת היא פשוט להשאיר דברים ב-feature/bug ללא תנאי ולהשתמש בתגיות כדי לציין חווית משתמש.
זה בהחלט נושא קשה.
4 לייקים
This seems like a good solution to me. It is obvious which category to post to, and those who care about UX can watch that tag. Another bonus is that we are able to eliminate a category!
Not sure how to pick apart the topics currently in UX which likely would want to go into Bug or Feature. Might be a good exercise to go through and clean that all up.
4 לייקים
Some thoughts from my side:
- I believe that dividing over 3000 topics into just 2 categories is a lot of work, and I wonder who will have the time to take on this task.
- Furthermore, I do not believe that all topics in UX can be easily divided into Feature and Bug. For me, a report about a text that cannot be translated is not really a bug report[1]. Likewise, pointing out an incomprehensible or outdated text is neither a feature request nor a bug report[2]. Similarly, descriptions of user experiences that contain neither an error nor a concrete improvement suggestion do not fit into Feature or Bug[3].
- I do not know how you have handled this so far, but I had the impression that developers, when necessary, also worked on UX topics, and vice versa. I wonder whether it might be possible to keep things as they were, with the group monitoring the category simply informing the other group if needed, without moving the post. However, I cannot fully evaluate this, as I do not know the processes before or now.
5 לייקים
Thanks Moin! You make some good points. I was looking at the total number of UX topics too and it is alot! 
Maybe the issue we’re having is that the UX category is inadequately described and so people are posting things there that should be in Bug or Feature. Here’s how we describe it in our internal documentation.
The UX category is a bit of a halfway house between Feature and Bug. Generally minor display issues would go here rather than Bug, and it would be the home for small changes to existing features. More ‘quality of life’ topics than anything big.
Generally, handling these topics would follow the pattern of the Feature category - About the feature category
Tagging
hmmm this one I would classify as bug… from a pure practical point, but is triaged much more frequently by myself cause UX attracts more vague things.
In this case that badge problem looks like a translation bug to me.
Actually also feels like a bug to me, nothing is open to interpretation here, our text is plainly wrong and needs updating.
This though is very much in the theme of UX to me, it is an open discussion about a pain point without any concrete recommendations yet. It is giving us a story, and place to extract particular bug/feature topics from in future.
Maybe all we need here is to better clarify the rules, leave UX for open unstructured discussion and user stories and keep “clear flaws” in bug … and “clear wish lists” in feature.
I get that everything is very grey in this world though, it is hard to pull a magic wand and fix everything.
Being clearer about our expectations though will help for sure.
7 לייקים
אתם עוקפים משתמשים כעת. אנחנו לא יכולים (ולא נסכים) לדעת כיצד חברה מקצה או מסווגת דברים. זה עניין פנימי לחלוטין. כל מה שאנחנו יכולים לעשות זה לנחש אם משהו הוא באג, בעיית חווית משתמש או משהו שונה לחלוטין. ומנהלים וצוות עושים את הקסם שלהם לאחר מכן, כפי שמתוכנן בליבת ה-Discourse.\n\nאז האם הנושא הזה באמת מיועד לצוות ולמשתמשים בעלי הרשאות, ואנחנו, בני התמותה האחרים, יכולים להפסיק לעקוב אחריו, או שמישהו באמת חושב שאני, למשל, שלא יכול לדעת את ההבדל בין תמונה לתמונה בהתאם למשהו שקורה ברמת הקובץ או המיכל, יש יכולת לתהות איזו עמדה בתוך CDCK תטפל בבעיה?\n\nברמה כללית יותר יש כאן שני היבטים, לפחות (כפי שכולם יודעים):\n* קטגוריות אינן תיבות לוגיות עם גבולות קפדניים\n* עבור אילו משתמשים הקטגוריות נוצרו, ציבורי או פנימי\n\nאני לא יודע… עקבתי אחר מדיניות שבה אני משתמש\n* תמיכה אם אני לא יודע אם הבעיה היא אצלי,\n* חווית משתמש אם יש לי תחושה שמשהו מתוכנן לעבוד כך\n* באג אם משהו הפסיק לעבוד או שובר מקומות לחלוטין\n\nאבל אני לעולם לא אבחר קטגוריה בהתאם למי באיזו עמדה ינסה לטפל בה. זו שאלה ניהולית בלבד.
2 לייקים
I like the idea of ux as a tag (and maybe have dev as a tag too?) , but I agree that there could be UX cases that feel like they don’t really belong in a different category either.
And some topics may be technically a feature, but are so small, that they would feel out of place in the feature category to vote on, for example: Clickable components instead of just the Edit button
But maybe we shouldn’t care? And any issue that asks to change something does belong in the feature category, no matter how small?
Or maybe we should have a category “Suggestions” – for things that aren’t broken, aren’t a full-blown feature request, and aren’t about how to do things. And then we can tag it dev or ux internally.
Edit: realised we already have a ux-tag, it’s just under utilised atm
4 לייקים
קטגוריית הצעות נראית חשובה. יש לי אותה בשתי הקהילות שלי.
לפעמים תגית יכולה להתפספס או שהקטגוריה UX לא תהיה ברורה למשתמשים מסוימים, אבל קטגוריית הצעות די ברורה לגבי מטרתה.
לייק 1
אני באמת לא חושב שאנחנו צריכים לשנות הרבה בקטגוריות כאן, הן עבדו בסדר כבר זמן מה וקטגוריזציה שגויה קורית, אבל לא בקצב מכביד ממה שאני יכול לראות. אם אזכורים, תגיות והקצאות לא עושים את העבודה עבור מיון פנימי, זה מרגיש שמשהו משתבש… כי יש לנו הרבה אפשרויות שם.
2 לייקים
Digging deep, I am not sure @moin 
I think the core of the problem here is:
- Sam recategorizes something from UX → Bug
- Sam knows how touching anything about anyone’s post can make them feel bad, or feel like they made a mistake
- Sam apologizes
- Then users get confused, want to self-correct, and there is a painful cycle.
Maybe the root problem here is?
Sam should feel free to recategorize as he sees fit, to better meet our business needs, and should not be apologizing about stuff every time he does that?
2 לייקים
I’ve been thinking about this topic for the last several weeks as I participate in discussions, address topics in the UX Bug Feature categories, and create topics of my own.
I think this is definitely the case. Sam and members of the team are free to categorize and tag topics as they see fit, in the interest of responding to the topic and getting to a resolution. If members are confused about these decisions, they can reach out to @moderators.
This is a great example of a topic that belongs in UX. It is small and is specifically about making an improvement to the interface. It’s also a great example of the kind of collaboration between community members and the team that we like to see, that leads to very nice quality of life improvements. 
Continuing on with the example Charlie cited, an area our team team needs to work on is pursuing topics like this to the end so they can be closed. Even this quite excellent collaboration was left with some loose ends. This is natural in the ebb and flow of discussion and collaboration here, and our engineer and designers are busy. As a result UX enhancements sometimes fall between the cracks, no matter how good the suggestion or how small the request feels. After a while @moderators can help identify these and shephard them home.
I updated the description for the UX category to make public what has been our internal approach to this category. This I hope will help everyone understand better what goes in UX vs other categories Feature and Bug.
Discussion about minor display issues and small changes in the Discourse user interface, and how features are presented (including language and UI elements). More ‘quality of life’ topics than anything big.
completed or fixed tags are applied to topics in this category depending on the nature of the topic.
Let me know if this is not clear enough or if you can think of further refinements. I’d like to give Bug and Feature the same treatment but will hold off on that for the minute.
אני חושב שעלינו להשתמש גם בתגית ‘ux’ יותר. זה יעזור במיון לדעתי, משהו יכול להיות נושא תמיכה או באג אך נוגע ל-UX. זה גם יפתור את הספק של “זהו באג אבל זה משהו ויזואלי, האם זה צריך להיות ב-Bug או ב-UX”.
=> להפוך את זה לבאג אבל לשים תגית ux
אני חושב שקטגוריית UX צריכה להיות בעיקר הצעות לשיפורים, דברים שאינם ברורים. לא דברים שבורים.
לפחות ההבחנה הזו הגיונית לי.
3 לייקים
מסכים לגבי שימוש רב יותר בתג ux, בכל שלוש הקטגוריות! אנשים שאכפת להם מאוד מ-ux יוכלו לעקוב אחר התג הזה.
נראה שעדיין לא הגענו להסכמה מלאה - לדעתי UX יכול להכיל גם באגים וגם בקשות לתכונות חדשות, אך הן חייבות להיות שיפורים קטנים של “איכות חיים” ולא משהו גדול. אם משהו שבור באמת בממשק המשתמש, הוא נכנס ל-Bug. אם מדובר בפרויקט גדול (למשל, לאפשר עריכה של תיאור מטא של תג), הוא נכנס ל-Feature.
כיצד היית משפר את תיאור קטגוריית ה-UX כדי להתאים להבנתך את הדברים?
Good question. I would say something like…
A UX topic is used for when the product technically works as intended, but the design, interaction, or flow creates unnecessary friction, confusion, or inefficiency for users.
I’m also good with it containing:
But I think anything that’s actually broken, even if small, should just be a bug with a ux tag.
3 לייקים
How about this for a new UX description? Feels a little stilted but tighter. I think it works? (I posted a UX topic of my own to report that tags don’t display properly in category banners)
Original:
Discussion about the user interface of Discourse and how features are presented (including language and UI elements).
Current:
Discussion about minor display issues and small changes to existing features in the Discourse user interface, and how features are presented (including language and UI elements). More ‘quality of life’ topics than anything big.
completed or fixed tags are applied to topics in this category depending on the nature of the topic.
Suggested new:
UX topics are used for when Discourse technically works as intended, but the design, interaction, or flow creates unnecessary friction, confusion, or inefficiency for users. Also for small “quality of life” improvements. completed or fixed tags are applied depending on the nature of the topic.
לייק 1
Thanks, sounds good to me 
מעולה! ביצעתי את השינוי.
(בסוגריים: זה כל כך מוזר ששינויים בתיאור לוקחים כמה דקות להופיע בכותרת הקטגוריה. אפילו רענון מלא לא עושה את זה.)
2 לייקים